Hálózati címfordítás

A hálózati címfordítás (angolul Network Address Translation, röviden NAT) a csomagszűrő tűzfalak, illetve a címfordításra képes hálózati eszközök (pl. router) kiegészítő szolgáltatása, mely lehetővé teszi a belső hálózatra kötött gépek közvetlen kommunikációját tetszőleges protokollokon keresztül külső gépekkel anélkül, hogy azoknak saját nyilvános IP-címmel kellene rendelkezniük. Címfordításra akár egyetlen számítógép is képes, így valósítható meg például az internet-kapcsolat megosztás is, amikor a megosztó gép a saját publikus címébe fordítja bele a megosztást kihasználó kliens gép forgalmát.

Az egész címfordítás témaköre abból az igényből nőtte ki magát, hogy az IPv4 tartománya viszonylag kevés, $2^{32}=256^{4}$ azaz 4 294 967 296 db egyedi IP címet tesz ki. Ebben persze benne van az összes broadcast cím és a külső hálózatra nem route-olható belső címtartományok is, tehát az interneten globálisan használható címek összessége így még kevesebb. A gépek hálózati kártyái egynél több címet is felvehetnek egyszerre ha kell, illetve nemcsak a számítógépeknek, hanem szinte az összes fontosabb hálózati eszköznek is szüksége van legalább egy címre. Belátható, hogy így a soknak tűnő 4 milliárd cím világviszonylatban már sajnos kevés.

Működése

A hálózati címfordító a belső gépekről érkező csomagokat az internetre továbbítás előtt úgy módosítja, hogy azok feladójaként saját magát tünteti fel, így az azokra érkező válaszcsomagok is hozzá kerülnek majd továbbításra, amiket – a célállomás címének módosítása után – a belső hálózaton elhelyezkedő eredeti feladó részére ad át. Ebből kifolyólag ez minden esetben egy aktív hálózati eszközt igényel, amely folyamatosan figyeli az érkező csomagokat és azok feladói és címzettjei alapján elvégzi a szükséges módosításokat. Ez többnyire (de nem szükségszerűen) egy tűzfal, amely megfelelően szétválasztja a külső internetet a belső hálózattól. Innen származik a terminológia is: a külső, illetve belső hálózat fogalma. A belső hálózatnak olyan címtartományt kell adni, amelyet minden hálózati eszköz a nemzetközi szabványoknak megfelelően belsőnek ismer el, és így azokat nem irányítja közvetlenül a külső hálózat felé. A belső címeket az alábbi táblázat mutatja be:

RFC1918	IP címtartomány	egyedi címek száma
24-bit block	10.0.0.0 – 10.255.255.255	16 777 216
20-bit block	172.16.0.0 – 172.31.255.255	1 048 576
16-bit block	192.168.0.0 – 192.168.255.255	65 536

A címfordítás segítségével megoldható, hogy akár egy egész cég teljes belső hálózati forgalma egyetlen külső IP cím mögött legyen, azaz gyakorlatilag egyetlen külső címet használ el egy több száz gépes hálózat. A belső forgalomban természetesen szükség van az egyedi belső címekre, de erről csak a címfordítást végző hálózati eszközöknek kell tudnia, kifelé ennek részletei már nem látható információk. Így létrejöhet olyan gazdaságos konfiguráció is, hogy egy viszonylag nagy cég teljes külső címfoglalása 10-20 db cím, míg a belső forgalmukban akár több ezer belső cím is lehet. Nagy előnye ennek a technikának, hogy ugyanazt a belső tartományt nyugodtan használhatja bárki más is, amíg mindegyik egyedi külső cím mögé van fordítva, ez nem okoz zavart. Akár az összes NAT-ot használó cég belső hálózatában lehet minden gép a 10.0.0.0 tartományban, ha kifelé valóban egyedi címmel látszanak. Éppen a címfordítás technológiája miatt nem került gyorsabban bevezetésre az IPv6 szabvány, amely kifejlesztésének egyik oka az IPv4 fogyatkozó címtartományának kiváltása volt.

Problémák

NAT Traversal

A címfordítás miatt természetesen folyamatos üzemű és nagy teljesítményű hálózati eszközökre van szükség, hogy a megnövekedett igényekkel járó egyre nagyobb sávszélességet valós időben tudják átengedni magukon. Ez hatalmas számítási kapacitást köt le, és koncentrált mivolta miatt az egyik legkritikusabb pontja egy hálózatnak. Ha kiesik a címfordítást végző eszköz, a hálózat működése azonnal kárát látja. Fürtözéssel és alternatív útválasztók beállításával ugyan csökkenthető ez a veszély, de ettől függetlenül is a fő tűzfal jelenti az egyik legérzékenyebb pontot. Sok hálózati protokoll csak szerteágazó és bonyolult beállítások után viseli el a címfordítást. Az egyik ilyen például az L2TP (Layer Two Tunneling Protocol) amely tanusítvány-alapú vagy előre megbeszélt kulcs (angolul: pre shared key) alapján titkosított IPsec csomagokat küld az alagút (tunnel) két végpontja között. Ha ezt még bele szeretnénk fordítani NAT-olt csomagokba, esetleg úgy, hogy egynél több címfordítás is történik útközben máris egy sor problémába ütközünk. A tunnel kiépítésekor használt IKE (Internet Key Exchange) protokoll pont a biztonsági tényezők integritásának védelme érdekében igényli a pontos konfigurációt, hiszen a biztonság és a használhatóság gyakran egymással ellentétes fogalmak a számítástechnikában. Az IP csomag hasznos mérete ugyanis egyre csökken, ahogy egyre több járulékos információ foglalja el a hasznos helyet a fejlécben. A titkosítás, a címfordítások, az ellenőrző információk mind-mind a ténylegesen hasznos adat elől foglalják a helyet, miközben egy sor plusz lehetséges hibaforrást is jelentenek. Könnyen belátható, hogy minél bonyolultabb a címzés, annál nehezebb feladat, hogy a csomag megfelelő sorrendben és megfelelő időben, sértetlenül és hiánytalanul eljusson a címzetthez. Mivel a kapcsolat kétirányú, minden esetben biztosítani kell a szembeforgalom megfelelő kezelését is. Szükség volt tehát egy úgynevezett „NAT Traversal” (közelítő fordításban: címfordítási átjárhatóság) szemléletmód kidolgozására, aminek az a célja, hogy szabványos keretbe foglalja azt az elvárást, amely szerint az egyes hálózati eszközöket fel kell készíteni a címfordítással együtt járó sajátosságok kezelésére egy adott feladatkörön belül. Amennyiben az adatcsomag a hálózaton megtett útja során csak ilyen eszközökön halad keresztül, biztosítható, hogy a csomagok megfelelő kezelése végig garantáltan hibamentes marad a címfordítástól függetlenül is.

VoIP & NAT

A NAT technika megjelenése egy sor megoldandó problémát jelentett a VoIP (Voice over IP), azaz ahogyan itthon elterjedt: „internetes telefonálás” használatában is. A SIP (Session Initiation Protocol) amely a VoIP kezeléséért felelős, az L2TP-nél említett okok miatt szintén nehezen viseli a címfordítással járó többletmunkát és az esetleges időkiesést. Ez fokozottabban jelent problémát az élő beszéd átvitelénél, ahol minden egyes csomagtovábbítási hiba, azonnal érzékelhető (hallható) problémát okoz. A VoIP esetében használatos SIP, SDP és RTP protokollok a számítógépek esetében jól működő címfordítási módszerekkel ellentétben egy sor megkötést hordoznak magukban, amelyek miatt az egyszerűbb tűzfalak illetve címfordításra képes egyéb eszközök nem képesek a VoIP forgalmat megfelelően kezelni. Ilyen esetben az szükséges, hogy a címfordítást végző eszköz konkrétan fel legyen készítve erre a feladatra. A VoIP audio-csatorna adatkapcsolati portja véletlenszerű, míg a SIP portja meghatározott (5060 illetve 5061 ha titkosított). Tehát a címfordítást végző eszköznek tudnia kell, hogy a SIP protokollal kapcsolatot kezdő készülékhez kell majd a véletlenszerűen kiválasztott porton folyó kapcsolatot is továbbítania, ráadásul figyelve arra, hogy a hálózatban lévő más készülékek hasonló módon kezdeményezett adatfolyamait ne keverje össze egymással. Belátható, hogy ez csak a forgalmat értő és a protokollok szabványait ismerő, azaz VoIP Applikáció-szintű címfordítóval lehetséges. A technológia bonyolultsága miatt nem létezik olyan eljárásmód, amelyik minden esetben követhető és minden esetben eredményre vezet, hanem a helyi sajátosságok ismeretében kell a megfelelő konfigurációs beállításokat elvégezni.

IP-szűrés

Ha egyszerre sok felhasználó fér hozzá a hálózathoz látszólag ugyanarról a címről, problémát jelenthet az egyes címek tiltásával, feloldásával végzett hozzáférési szabályozás elve. Konkrét példával illusztrálva: ha egy szerkesztő és egy vandál is ugyanannál a cégnél dolgozik ahol címfordítást használnak kifelé, mindkettejük tevékenysége ugyanarról az IP címről látszik. Ez hirtelen felindulásból zoknibáb gyanúját is keltheti, hiszen a cím ugyanaz, ahonnan a szerkesztések és a vandálkodások is jönnek, pedig két (vagy akár több) különböző embert takar a valóságban. A címtartományok tulajdonosi köre nyilvános, tehát egy hozzáértő ellenőr ki tudja deríteni, hogy az adott cím a szolgáltatók által dinamikusan kiosztott tartományokból való, vagy esetleg egy cég tulajdona, aki befordítja az adott cím mögé a teljes hálózati forgalmát. Ilyenkor a cím blokkolása gátolná az amúgy rendes szerkesztő(k) hozzáférését is, így ilyen esetben a károkozót magát (felhasználónevét) kell korlátozni az IP cím helyett. Az internetes forgalmi kimutatásokat készítő programok eredményeit is befolyásolja az egyetlen címről érkező óriási mennyiségű lekérés, amit akár több száz dolgozó is generálhat, akik egyetlen külső cím mögött ülve végzik a munkájukat.

Típusai

A címfordítás többféle séma szerint kerülhet megvalósításra, amelyekben a fordítás jellege, illetve a portok és protokollok kezelése tér el egymástól. A különbségeket az alábbi táblázat szemlélteti. A címek és a portok előtt álló vastagbetűs b- és k- előtagok a belső és külső fogalmakat rövidítik a magyarázatok egyszerűbb átláthatóságának érdekében.

Full cone NAT, azaz egy-az-egyben címfordítás. Amikor egy belső cím (b-Cím:b-Port) egy külső címre fordul (k-Cím:k-Port), bármilyen csomag a belső címről (b-Cím:b-Port) a külső címen (k-Cím:k-Port) keresztül kerül kiküldésre. Bármelyik külső gép tud csomagokat küldeni a belső gépnek úgy, hogy a csomagokat a külső címre küldi, amin keresztül fordítás után eljut a belső géphez.
(Address) Restricted cone NAT, azaz címhez kötött címfordítás Amikor egy belső cím (b-Cím:b-Port) egy külső címre fordul (k-Cím:k-Port), bármilyen csomag a belső címről (b-Cím:b-Port) a külső címen (k-Cím:k-Port) keresztül kerül kiküldésre. Bármelyik külső gép tud csomagokat küldeni a belső gépnek úgy, hogy a csomagokat a külső címre küldi amin keresztül fordítás után jut el a belső géphez, de csak akkor, ha előzőleg a belső gép küldött csomagot a külső gépnek. A Port-ra nézve itt nincs megkötés.
Port-Restricted cone NAT , azaz porthoz (és címhez) kötött címfordítás Hasonló mint az előző (Address) Restricted cone NAT, de a megkötés a portszámra is vonatkozik. Amikor egy belső cím (b-Cím:b-Port) egy külső címre fordul (k-Cím:k-Port), bármilyen csomag a belső címről (b-Cím:b-Port) a külső címen (k-Cím:k-Port) keresztül kerül kiküldésre. Bármelyik külső gép tud csomagokat küldeni a belső gépnek úgy, hogy a csomagokat a külső címre küldi amin keresztül fordítás után jut el a belső géphez, de csak akkor, ha előzőleg a belső gép küldött csomagot a külső gép előzőekben használt címére és portjára.
Szimmetrikus NAT, azaz szimmetrikus címfordítás Bármilyen kérés egy adott belső (b-Cím:b-Port) gépről, amely egy külső (k-Cím:k-Port)-ra irányul egy egyedi külső címre és portra fordul, amit a külső gép forrásnak tekint (ahová majd válaszolnia kell, ha el akarja érni a belső gépet). Ha ugyanaz a belső gép (akár ugyanazzal a belső címmel és porttal) egy másik külső gépnek küld csomagot, az már egy másik, szintén egyedi külső címet kap (ahová majd a másik megcímzett külső gép válaszol, ha el akarja érni a belső gépet) Gyakorlatilag minden külső gép egy egyedi címen látja (akár ugyanazt) a belső gépet. Csak az a külső gép tud visszaküldeni választ, amelyik előzőleg kapott a belső géptől csomagot.

A legtöbb címfordítási megoldás kombinálja egymással az egyes típusokat, ezért jobb az adott esetben jellemző címfordítási viselkedésről, mint a konkrét típusról beszélni. Előfordulhat például olyan eset, amikor két belső gép is ugyanazzal a külső géppel akar kommunikálni ugyanazon a porton. Ilyenkor legtöbbször a második gép számára a külső port véletlenszerűen kerül kiválasztásra az ütközést elkerülendő, tehát ebben az esetben hol „címhez és porthoz kötött”, hol pedig „szimmetrikus fordítással” jut el a csomag egyik géptől a másikhoz, az igényeknek és a pillanatnyi lehetőségeknek megfelelően. Egyes protokollok ezt nehezen, vagy egyáltalán nem viselik el, így ennek kezelése megköveteli a megfelelő (a forgalmat értő) címfordító használatát.

Az általános, mindennapos internetböngészés (weboldalnézegetés) során a belső gép minden esetben a 80-as porton szólítja meg a külső gépet, de az egy teljesen véletlenszerűen választott porton küldi vissza a választ. Ezáltal megvalósítható, hogy egyetlen belső gép több külső gépről szolgáltatott weboldalhoz is egyszerre, egyidőben hozzáférjen, mindegyiket a 80-as szabványos porton szólítva meg a kívánt webtartalom eléréséhez. Ha eközben egy másik belső gép valamelyik ugyanazon külső gép weboldalát kívánja szintén megnézni, az ő számára egy másik véletlenszerű porton érkezik majd a válasz, de ő is ugyanúgy a 80-as porton kezdeményezi ezt a kapcsolatot. Látható, hogy ebben az esetben a fordításhoz használt külső cím és port nem változott, de a visszirányú kapcsolat(ok)ban a port minden esetben más volt. Összességében elmondható tehát, hogy a választott címfordítási metódust mindig az elvégzendő feladat határozza meg.

Források

• RFC 4008 – Standards Track – Definitions of Managed Objects for Network Address Translators (NAT)
• RFC 3022 – Traditional IP Network Address Translator (Traditional NAT)
• Cisco - A Look Inside Network Address Translators (Geoff Huston) Archiválva 2009. január 31-i dátummal a Wayback Machine-ben