Miért nem érhető el kívülről a mobilneten lévő kamera vagy NAS?

A beüzemelés simán megy: a kamera felkerül a falra, az 5G router mellé bekapcsol a NAS, otthon minden elérhető. Aztán az első kísérletnél kívülről — munkahelyről, nyaralásból, egy másik hálózatról — nem jön be semmi. A hibakeresés ilyenkor általában a routerbe fut bele: port-továbbítás, UPnP, tűzfalszabályok, DDNS-fiók. Csak éppen a felsoroltak közül egyik sem biztos, hogy a probléma helye.

A kérdés ugyanis nem az, jól van-e beállítva a router, hanem hogy milyen IP-címet ad a szolgáltató. Ez nem egységes: ugyanaz a technológia mögött háromféle helyzet lehet, és mindegyikhez más megoldás tartozik.

Három eset, nem egy

• Állandó, kívülről elérhető cím. A legkényelmesebb eset: a cím nem változik, az eszközök a hagyományos módon publikálhatók. A szolgáltatók ezt jellemzően külön, megrendelhető szolgáltatásként kínálják.
• Kívülről elérhető, de változó cím. A cím valódi, tehát a bejövő kapcsolat célba ér — csak minden újraindításnál, szoftverfrissítésnél vagy áramkimaradásnál más lesz. Erre a helyzetre találták ki a DDNS-t, és a port-továbbítás is működik.
• Több előfizető között megosztott cím. Itt a bejövő kapcsolat nem talál célt. Ennek a technikának a neve CGNAT (Carrier-Grade NAT), vagyis szolgáltatói szintű címfordítás.

Az, hogy melyik eset áll fenn, nem a technológián múlik, hanem a szolgáltatón, a tarifán, és azon az APN-beállításon, amit a telefon vagy a router használ. Az APN az a néhány karakter a hálózati beállításokban, ami megmondja, melyik hálózatra kapcsolódjon az eszköz — és ugyanannál a szolgáltatónál különböző APN mögött más címtípus lehet.

Egy IP-cím, több száz előfizető

A harmadik eset a legelterjedtebb, és érdemes érteni, miért. Az internet régebbi címrendszerében, az IPv4-ben nagyjából 4,3 milliárd cím létezik. Ez az internetre kötött eszközök számához mérve régen kevés, ezért a szolgáltatók megosztják őket: egyetlen nyilvános cím több száz, akár több ezer előfizetőt szolgál ki, a fordítást pedig a szolgáltató hálózatának szélén álló eszköz végzi.

A működését egy társasház írja le a legjobban. Az utcai cím egy van, a lakók sokan vannak. Kimenő levelet bárki feladhat, és a válasz is megtalálja, mert a portás fejben tartja, ki mit küldött. Aki viszont kívülről próbál becsengetni egy konkrét lakásba, csak a kaputelefonig jut: a levélen nem szerepel lakásszám, tehát nincs mit kézbesíteni.

Ilyenkor a router nem nyilvános címet kap, hanem egy belső hálózati címet a 100.64.0.0 – 100.127.255.255 tartományból. Ezt a sávot 2012-ben kifejezetten erre a célra tartották fenn, hogy ne ütközzön sem a lakossági otthoni hálózatok, sem a szolgáltatók belső címeivel. A gerinchálózat ezeket a címeket nem is továbbítja — hivatalosan sem léteznek a nyilvános interneten.

Honnan derül ki két perc alatt?

Mivel a három eset kívülről egyformán néz ki, a hibakeresés első lépése nem a routerben van, hanem ebben az összevetésben:

1. A router adminfelületén a WAN IP-cím (a kifelé néző oldal címe).
2. Ugyanabból a hálózatból megnyitva egy „mi az IP-címem” típusú weboldalon látható cím.

Ha a kettő megegyezik, kívülről elérhető cím van a routeren — ilyenkor a port-továbbítás és a DDNS is értelmes eszköz. Ha eltér, a szolgáltató oldalán is történik fordítás, és a cím megosztott. A gyanút megerősíti, ha a WAN-cím a 100.64 – 100.127 kezdetű sávba esik: az kifejezetten a szolgáltatói címfordítás jelzése.

Érdemes az ellenőrzést néhány nap múlva megismételni. Ha a cím nyilvános, de közben megváltozott, akkor a második eset áll fenn: a cím valódi, csak vándorol.

Mit visz el a megosztott cím?

Ami kifelé indul, az működik: böngészés, streaming, videóhívás, felhőbe mentés, alkalmazásfrissítés. A mobilinternet mindennapi használatának gyakorlatilag az egésze ilyen — ezért nem tűnik fel a dolog évekig. A hiány csak akkor jelentkezik, amikor kívülről kellene kapcsolatot kezdeményezni egy otthoni eszközhöz:

• Kamera, NAS, otthoni tárhely — a böngészőből vagy egy általános alkalmazásból indított kapcsolat nem talál célt
• Saját szerver — weboldal, játékszerver vagy otthoni VPN-végpont nem publikálható
• Játékkonzol — a NAT típus „strict” lesz, ami akadozó társkeresést, hangchatet és közös játékot jelent
• Port-továbbítás és UPnP — beállítható a routerben, de a szolgáltatói címfordításig nem hat el

Egy kevésbé látványos hatás a megosztott cím reputációja. Ha valaki ugyanazon cím mögül visszaélést követ el, a szűrők az egész címet minősítik: emiatt jelenhet meg gyakoribb ellenőrző kérdés vagy blokkolás olyan előfizetőknél is, akik semmit nem tettek. A helymeghatározás is pontatlanabb lesz, mert a cím a szolgáltató eszközének a helyét mutatja, nem a felhasználóét.

Amit a port-továbbítás és a DDNS tud — és amit nem

Ez a két eszköz nem rossz, csak a harmadik esetben tehetetlen. Érdemes szétszedni, melyik mit végez.

A port-továbbítás a saját hálózat határát nyitja meg: megmondja a routernek, hogy a kívülről érkező kérést melyik belső eszközhöz adja tovább. Ez pontosan addig működik, amíg a router kifelé néző oldalán valódi, nyilvános cím van. Megosztott cím mögött a szabály elkészül, a router el is fogadja — de a kérés már a szolgáltató címfordító eszközén elakad, ahhoz pedig senkinek nincs hozzáférése. Ugyanez igaz az automatikus változatra, az UPnP-re is.

A DDNS feladata más: állandó nevet rendel egy változó címhez, hogy ne kelljen minden újraindítás után új számsort keresni. A második esetben ez a helyes és elegendő megoldás. A harmadik esetben viszont a név is csak a szolgáltató központi eszközére mutatna — a beállítás elkészül, a kapcsolat mégsem jön létre. A DDNS tehát nem hatástalan általában, hanem megosztott cím mögött hatástalan.

Az IPv6, ami már itt van

A címhiányra a valódi válasz az új címrendszer, az IPv6. Ebben annyi cím van, hogy minden eszköz kaphat sajátot, tehát a megosztás oka megszűnik. A mobilszolgáltatók ezt hamarabb vezették be, mint a vezetékes hálózatok: a szűkösség őket érintette a legkorábban.

Két fenntartás tartozik ezekhez a számokhoz. Az egyik, hogy hálózati szinten mérik a felhasználókat, tehát a vezetékes és a mobil oldal együtt látszik bennük. A másik, hogy a mérés azt mutatja, mennyi felhasználó képes IPv6-ot használni — nem azt, hogy egy konkrét tarifa vagy APN mögött megjelenik-e. Az irány viszont egyértelmű: mindhárom hálózatban van kiosztott IPv6, a különbség a mértékben van.

Van azonban egy csavar: az IPv6-cím csak akkor használható, ha a másik végpont is IPv6-os. Egy csak IPv4-es munkahelyi hálózatból vagy szállodai wifiről az otthoni IPv6-címre nem lehet rákapcsolódni. Ezért az IPv6 remek megoldás, de nem mindenhonnan.

Mit közölnek a magyar szolgáltatók?

A hivatalos tájékoztatások két dolgot mondanak ki egyértelműen: a nyilvános cím nem alapfelszerelés, és az APN dönt.

A Yettel saját tájékoztatása szerint a hang- és mobilinternet-tarifákon a nyilvános IP-címeket privát címekre cserélte, biztonsági indoklással, egyedi kivételekkel. Ugyanez a leírás rögzíti, hogy nyilvános címmel az eszköz közvetlenül elérhető az interneten, privát címmel viszont csak a gyártó saját alkalmazásán keresztül. A szolgáltató azt is kimondja, hogy a nyilvános címek dinamikusan változnak, és hogy az APN konfigurációja határozza meg, privát vagy nyilvános hálózatra kapcsolódik az eszköz. Az állandó, kívülről elérhető címet külön szolgáltatásként kínálják, elsősorban kisvállalati ügyfeleknek.

A Magyar Telekom IPv6-tájékoztatója szerint a mobilhálózaton párhuzamosan ad IPv4- és IPv6-címet, és 2016 vége óta építi ezt. Ez a gyakorlatban azt jelenti, hogy a régi címrendszerben megosztott, az újban viszont saját cím jut az eszköznek.

A tanulság mindkettőből ugyanaz: a távoli elérésre épülő rendszernél nem feltevésből kell kiindulni. Aki üzleti célra — távfelügyeletre, telephelyek összekötésére — épít, annak érdemes a címtípust előre tisztázni, mielőtt az eszközök felkerülnek a falra. A vállalkozói felhasználásról külön cikk is szól.

A négy megoldás, ami tényleg működik

Ha a cím megosztott, az áttörés egy egyszerű felismerésen alapul: a szolgáltatói címfordítás a bejövő kapcsolatot akadályozza, a kimenőt nem. Tehát nem kívülről kell becsengetni, hanem az otthoni eszköznek kell kimenni a kapu elé. Ha az otthoni gép maga nyit kapcsolatot egy köztes szolgáltatás felé, azon a csatornán a forgalom mindkét irányban folyhat — és port-továbbításra sem lesz szükség.

Az alábbi táblázat három dolgot mond meg minden megoldásról: mibe kerül, mit kell hozzá elvégezni, és mi lesz utána elérhető.

Kimenő alagút

Ebben a modellben egy kis program fut az otthoni gépen, és kifelé nyit titkosított csatornát egy szolgáltatás felé. A kívülről érkező látogató nem az otthoni routert keresi, hanem azt a szolgáltatást, amelyik a csatorna másik végén már tudja, hova irányítsa a kérést. Tűzfalat nyitni nem kell, és a megosztott cím sem akadály — a kapcsolat ugyanis belülről indult.

A legismertebb ilyen megoldás a Cloudflare Tunnel, amely webes felületek publikálására való: kamerakezelő felület, okosotthon-vezérlő, saját dokumentumtár. A Cloudflare eszközeiről a VPN, WARP és Zero Trust összevetésében részletesebb leírás található.

Privát hálózat az eszközök között

Itt nincs publikus weboldal: az eszközök egy zárt hálózatot képeznek egymás között, mintha egy lakásban lennének. Aki nincs benne a hálózatban, semmit nem lát. A Tailscale és a hasonló, WireGuard-alapú megoldások pontosan erre valók, és van bennük egy fontos képesség: ha a két végpont között nem jön létre közvetlen kapcsolat — ami éppen a megosztott cím miatt gyakori —, a forgalom automatikusan egy köztes átjátszó szerveren megy át. Lassabb, de működik, és beállítani nem kell hozzá semmit.

Ez a legrugalmasabb út, mert nem csak webes felületekhez ad hozzáférést: fájlmegosztás, távoli asztal, adatbázis, bármilyen protokoll átvihető rajta. A korlátja, hogy csak a hálózatba felvett eszközökről működik — nem lehet vele bárki számára nyilvános szolgáltatást üzemeltetni.

A gyártó saját felhője

A kamerák és okosotthon-eszközök nagy része eleve így működik: az eszköz maga jelentkezik be a gyártó szolgáltatásába, a telefonos alkalmazás pedig ugyanoda kapcsolódik. Nincs mit beállítani, viszont a hozzáférés a gyártó alkalmazásához és feltételeihez kötött — és ha a szolgáltatás megszűnik, az eszköz távoli elérése is vele megy. Okosotthon mobilinternettel témában erről is szó van.

Mikor nem probléma ez egyáltalán?

A legtöbb felhasználónak soha nem lesz belőle gondja. A böngészés, a videó, a felhő, a játék letöltése, a videóhívás mind kifelé indított kapcsolat — a címtípus ezeket nem érinti, és sebességben sem jelent hátrányt. A korlátlan mobilinternet csomagok ugyanúgy használhatók fő otthoni internetként, mint bármi más.

A kérdés akkor válik fontossá, amikor a mobilinternet nem csak fogyaszt, hanem kiszolgál is: kamera, tárhely, otthoni automatizálás, távoli munkaállomás. Ilyenkor viszont nem a router beállításait kell átfésülni, hanem előbb kiderítni, melyik a három eset közül az érvényes — és ehhez elég a WAN-cím összevetése.

Érdemes ezt a döntést az eszközválasztás előtt meghozni. A távoli elérés módja ugyanis nem a router árán múlik, hanem azon, hogy melyik utat választja az ember — és ezt utólag jóval drágább átépíteni, mint elsőre eltalálni.