Department of Software Engineering

Ősz 2017 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED Department of Software Engineering Számítógép-hálózatok 8. gyakorlat IP, NAT Bagóczki Zsolt Szegedi Tudományegyetem

Tartalomjegyzék Bevezetés... 3 Elméleti háttér... 3 Network Address Translation... 3 A hálózati címfordítás működése... 4 Előnyök, hátrányok... 5 IP NAT alapfogalmak... 5 NAT fajtái... 6 Statikus NAT... 6 Dinamikus NAT... 6 Gyakorlati háttér... 7 Alapötlet NAT vizsgálatához Wiresharkban... 7 Kliens oldal vizsgálata... 7 Szerver oldal vizsgálata... 9 Linkek... 12 Bagóczki Zsolt 2017 2

Bevezetés A hatodik heti anyagban részletesen megismerkedtünk az IP címekkel. és megtanultuk egy egyszerű hálózati modell IP címkiosztásának a megtervezését. Az eddigi modelljeinkben egy hálózaton belül elhelyezkedő eszközökkel találkoztunk, melyek egy vagy néhány routeren keresztül közvetlen kapcsolatban álltak egymással, köztük az adatáramlás folytonos volt. A valóságban azonban a helyi hálózatok sokszor kényszerülnek a külvilággal kapcsolatot létesíteni, a külvilág felé küldeni, vagy onnan fogadni csomagot. Ebben az esetben viszont a világon minden számítógépnek egyedi IP címmel kellene rendelkeznie a forgalom lebonyolítása érdekében, melynek kivitelezése IPv4-es címekkel lehetetlen. Az IPv6 protokoll hivatott kiváltani és megoldani ezt a problémát, de ameddig az IPv4 is használatban van, szükségesek átmeneti megoldások. Az egyik ilyen módszer a hálózati címfordítás (Network Address Translation, röv. NAT), mely az OSI modell 3. rétegében működik. Elméleti háttér Használjunk tehát minden helyi hálózatban egymástól független, privát IP címkiosztást. Ebben az esetben a világ bármely hálózata használhat bármilyen címkiosztást, melyek akár egymással megegyezőek is lehetnek. Ezen privát címek a külvilág számára rejtettek lesznek, vagyis ezek az IP címek nem hagyják el a belső hálózatot. Ekkor viszont, amint a külvilággal szeretnénk kommunikálni, szükség lesz egy (vagy több) olyan, úgynevezett nyilvános címre, mely(ek) segítségével a belső hálózatbeli gépek a külvilággal kommunikálni képesek. Ezek a nyilvános címek minden belső hálózatban elhelyezkedő gép számára elérhetőek, használhatóak. A belső címek a külső hálózatba lépéskor erre a nyilvános címre fognak fordulni, tehát a külvilág számára a nyilvános cím lesz látható. Emiatt a hálózat felé érkező csomagok is ezeket a nyilvános címeket fogják használni. A privát és nyilvános címek fordítása a routerek feladata. Network Address Translation Az a folyamat, mely során a privát címek Interneten irányítható, nyilvános címekké alakulnak, a hálózati címfordítás (NAT). A belső, privát címeket helyi, míg a külső, nyilvános címeket globális címeknek nevezzük. A hálózati forgalom során ekkor elkülönül a hálózaton belüli, és az azon kívüli kommunikáció. A belső hostok között, egymásnak küldött csomagok ez után is privát címeket fognak használni, a más hálózatokra küldött csomagok esetén szükséges a címfordítás. Mikor a belső hálózatból a külvilág felé történik a csomagküldés, akkor a helyi címek fordulnak globális címekre, mikor pedig a külső hálózat felől érkezik a csomag, akkor a globális címek fordulnak helyi címekre a forgalomirányító segítségével. Az átjáró (default gateway) elérésekor a belülről küldött csomagokban a forgalomirányító a saját nyilvános IP címére cseréli a csomag forrásában található privát IP címet. Ezt a nyilvános címet (adott esetben többet) a forgalomirányító az internetszolgáltatótól kapja. Bagóczki Zsolt 2017 3

A hálózati címfordítás működése A címfordítás hasonlít a vállalati telefonrendszer működéséhez. Ahogy a cég folyamatosan veszi fel az embereket, egy ponton túl nem vezetnek minden dolgozó asztalához külön külső telefonvonalat. Ehelyett olyan rendszert használnak, amely lehetővé teszi, hogy a vállalat minden dolgozójához egy melléket rendeljen. A dolgozók egymást hívhatják csak a mellék tárcsázásával, kívülről pedig egy központi számot hívnak, ahol kapcsolják a kívánt melléket. A cég ezt gond nélkül megteheti, mert az összes dolgozó egyidejűleg nem akar telefonálni. A belső hívószámok használatával a cégnek kevesebb külső vonalat kell vásárolnia a telefontársaságtól. A NAT is hasonlóképpen működik. 1. ábra A NAT alapelemei A fenti példában a forgalomirányító nyilvános címe tölti be a központi szám szerepét, melyet a külső hálózatok elérnek. Erre az IP címre érkezik minden, a hálózatba érkező csomag, és ezt az IP címet adja a forgalomirányító minden, a hálózatból távozó csomag fejlécébe, mint forrás. Ettől függetlenül a hálózaton belüli eszközök a saját mellékjeiken vagyis a privát IP címeiken változatlanul elérik egymást, és általában kevés lesz az olyan eszköz, mely egyszerre szeretne a külvilág felé kommunikálni. Az RFC 1918 referencia által meghatározott privát IPv4 címtartományok a következők: A osztály: 10.0.0.0-10.255.255.255 B osztály: 172.16.0.0-172.31.255.255 C osztály: 192.168.0.0-192.168.255.255 Az IPv6 privát címtartományokat az RFC 4193 referencia írja le. Bagóczki Zsolt 2017 4

Előnyök, hátrányok A NAT sok esetben hasznos fegyver, például ha a hálózat egy részét az Internet elől szeretnénk elrejteni, vagy ha IPv4 címeket szeretnénk megspórolni, de kisebb hálózatokon egy Internet kapcsolat megosztására is használható a gépeink között, egyetlen nyilvános IP cím elfoglalásával. Bár a NAT használható nyilvános IP címekkel épp úgy, mint a privát (RFC 1918 szerinti) címekkel, a leggyakrabban akkor használjuk, ha egy eszköz címét el szeretnénk rejteni, és helyette inkább a routerét használni a külvilággal történő kommunikáció során. Szükség van a NAT használatára akkor is, ha nincs elegendő elérhető publikus IP cím a belső hálózatunk számára, és egyes eszközöket védetté akarunk tenni az Internet felől érkező kérések ellen (NAT Overload). Az IPv4-es címek száma miatt nincs is lehetőség arra, hogy minden egyes eszköz rendelkezzen saját privát és nyilvános címmel is egyaránt, és ez nem is megfelelő eljárás sok esetben. Néha azonban mégis szükséges lehet, hogy a hálózatbeli hostok rendelkezzenek mind helyi, mind globális címekkel, ekkor használható 1:1 NAT. A NAT előnyei közé sorolható tehát, hogy segít az IPv4-es címek megtakarításában. Plusz megbízhatóságot és skálázhatóságot is vihetünk a hálózatunkba, ha egyszerre többféle globális címtartományt, tartalék címtartományokat, stb. implementálunk. Átláthatóbbá, konzisztensebbé tehetjük a hálózati címkiosztásunkat a NAT használatával. Végül, de nem utolsó sorban pedig egy plusz biztonsági tényező, mivel a belső hálózatbeli hostok teljes mértékben elrejthetővé válnak a külvilág elől. Természetesen a számos előnye mellett hátrányai is akadnak a hálózati címfordításnak. Egyes eszközök, hostok például limitálják az egy forrásból érkező kapcsolatok számát, így problémát okozhat, ha több host akar ugyanarra a külső hostra kapcsolódni. Mivel a belső hálózatbeli hostok külső hálózatok hostjai számára nem elérhetőek, a pont-pont összeköttetéseken alapuló alkalmazások és protokollok nem feltétlen fognak megfelelően működni. Ebből kifolyólag egyes, külső hálózatból indított TCP és UDP kapcsolatok sem lesznek használhatóak. Ugyanígy gondot okozhat az IP trace, a távoli elérés/vezérlés, vagy egyes tunneling protokollok használata is. IP NAT alapfogalmak Belső (helyi) hálózat: bármilyen, a forgalomirányítóhoz csatlakozó hálózat, amely a privát címzést használó helyi hálózat (LAN) része. A belső hálózaton levő állomások IP-címe fordításon megy át, mielőtt külső célpontokhoz továbbítják. Külső (globális) hálózat: minden olyan hálózat, amely a helyi hálózaton kívül van, és nem ismeri fel a helyi hálózat állomásaihoz hozzárendelt privát címeket. Belső helyi cím: a belső hálózat egy állomásán beállított magánhálózati cím, privát IP-cím. A cím csak úgy kerülhet ki a helyi hálózati címzési struktúrából, ha előtte lefordítjuk. Bagóczki Zsolt 2017 5

Belső globális cím: a belső hálózat állomásának címe a külső hálózatok felé. Ez a lefordított cím. Külső helyi cím: a helyi hálózaton tartózkodó adatcsomag célpontjának címe. Ez a cím rendszerint ugyanaz, mint a külső globális cím (mivel mi sem látjuk annak a privát címeit) Külső globális cím: egy külső állomás nyilvános IP-címe. A cím egy globálisan továbbítható címből, vagy hálózati tartományból van származtatva. NAT fajtái Statikus NAT Statikus NAT segítségével mindegy egyes helyi, privát IP cím egy publikus, globális IP címre fordul. Minden egyes privát cím egyetlen egy nyilvános címhez lesz hozzárendelve, és ez a hozzárendelés kölcsönösen egyértelmű (1:1-es hozzárendelés). Mivel tehát minden egyes helyi IP címhez egy külső, globális IP cím lefoglalására lenne szükség, a statikus NAT-ot kevésbé használják. Ezeket a statikus hozzárendeléseket a határroutereken kell felkonfigurálnunk, és ezen forgalomirányítók végzik majd a címfordítást. Dinamikus NAT 2. ábra Statikus NAT A Statikus NAT-tal ellentétben itt a privát címek globális címekhez rendelése dinamikus módon történik. A címfordítást végző határrouterek két IP címlistát kell, hogy ismerjenek: 1) a lefordítandó, privát címek listáját (access-list), valamint 2) a nyilvános címek tartományát (pool). Dinamikus címfordítás esetén egy-egy címfordítás, és cím hozzárendelés csupán egy tranzakció erejéig aktív. A határrouter megkapja a hosttól a kiküldeni kívánt csomagot, majd a meghatározott nyilvános címlistából, a poolból kiválaszt egy éppen, aktuálisan elérhető globális címet. Ezt a címet ideiglenesen hozzárendeli a belső IP címhez, és egészen a hálózati forgalom lebonyolításáig fenn is tartja Bagóczki Zsolt 2017 6

ezt a hozzárendelést. Amint a hálózati forgalom végbe ment, és a címzettől megkaptuk a válaszcsomagot, a forgalomirányító törli a hozzárendelést, és az így felszabadult globális cím visszakerül az elérhető globális címek listájába, a poolba. 3. ábra Dinamikus NAT Láthatjuk, hogy egy globális címre küldött csomagot csak akkor továbbít a belső hálózat felé a router, ha van hozzá érvényes párosítás, egyébként eldobja. Természetesen ez sem tökéletes védelem, de egyfajta biztonságot nyújt a belső eszközök számára. Gyakorlati háttér Alapötlet NAT vizsgálatához Wiresharkban Ezen a gyakorlaton a NAT protokoll működését kell vizsgálnunk. Ehhez azonban egy új módszerre van szükség, nem lesz megfelelő az, hogy egyetlen Wireshark-os szűrés alapján dolgozzunk. Mivel a protokoll vizsgálatához a NAT-olást végző eszköz (határrouter) mindkét oldalán elhelyezkedő eszközök csomagjaira szükségünk van, így két különböző helyen kell a szűrést elvégeznünk. Valamint nehézkes lenne minden hallgató számára egy-egy NAT-ra alkalmas eszköz biztosítása két számítógéppel, így a gyakorlatokra előkészítünk a NAT vizsgálatára alkalmas dump file-okat. Az alábbi példában két külön dump file-t fogunk megvizsgálni, és ezek alapján figyeljük meg a NAT működését. A példában egy egyszerű kliens géppel fogunk hálózati kapcsolatot létesíteni a www.google.com szervereivel. Kliens oldal vizsgálata A kliens oldalán végzett szűrés eredményéből több, számunkra hasznos információt is ki fogunk tudni nyerni. Kezdjük a legalapvetőbb kérdésekkel: mi a kliens IP címe, és mi a szerver IP címe? Bagóczki Zsolt 2017 7

4. ábra Kliens oldali szűrés eredménye Ahhoz, hogy a fenti kérdésekre választ kapjunk, induljunk el a következő gondolatmeneten: a 3. gyakorlaton tanultak alapján tudjuk, hogy ahhoz, hogy egy HTTP kapcsolat létrejöhessen, először a kliens oldaláról egy HTTP kérés fog történni a szerver felé. A HTTP kérés metódusai lehetnek GET, POST, PUT, DELETE, stb., tehát ezek közül kell valamelyiket megkeresnünk. Az első csomagot megvizsgálva azt láthatjuk, hogy az Info oszlop alatt a GET szócska szerepel, így célszerű lesz ezt a csomagot megvizsgálnunk. 5. ábra HTTP GET kérés Valóban, a csomag részleteit megnyitva, a HTTP fül alatti részben láthatjuk, hogy a megvizsgált csomag egy GET kérést tartalmaz, a HTTP/1.1-es verzióját használva. Annak tudatában, hogy ez a GET kérés a kliens géptől indult a szervergép felé, már tudjuk is a választ a két felmerült kérdésre. A kliens IP címe nem más, mint a Source oszlop alatt található IP cím, a szerveré pedig a Destination. 1. táblázat IP címek Kliens Szerver 192.168.1.100 64.233.169.104 A következő feladat kideríteni, hogy mely portok voltak felhasználva a HTTP kapcsolat során. Tudjuk, hogy a HTTP protokoll a 80-as portot fogja használni. Gondoljuk végig, hogy mit is jelent ez: az első GET kérés esetén a kliens gép akar HTTP kapcsolatot létesíteni egy szerver géppel. Ekkor a HTTP kérés mindenképp kifele, a szerver irányába fog menni, tehát biztos, hogy a Destination port kell, hogy a 80-as számú legyen, vagyis ezt a portot fogja a szerver használni. Nincs más dolgunk, mint a Source portszámot előkeresni, nyissuk hát meg ismét az első csomag részleteit, és a TCP mezőből kiolvashatjuk a 4335-ös portszámot. Bagóczki Zsolt 2017 8

6. ábra TCP adatok 2. táblázat Portszámok Kliens Szerver 4335 80 A csomaglistából látható, hogy a HTTP kérésünk a 7.109267 időpillanatban lett elküldve. Keressük hát meg az erre a csomagra kapott választ a szerver felől. A HTTP kérésekre HTTP válaszcsomagokat fogunk kapni, melyek különböző kódokat tartalmazhatnak (200 OK, 400 BAD REQUEST, 404 NOT FOUND, stb.). A csomaglistát vizsgálva a 2. csomag Info oszlopa alatt a HTTP/1.1 200 OK üzenetet láthatjuk, és ha megvizsgáljuk a csomagot, valóban az előbb megtalált szerver címet találjuk a küldő (Source) címnél, és a kliens címét pedig a cél (Destination) címnél. Továbbá, mivel az első csomag volt a legelső HTTP kérés, és a második válaszcsomag és első kérőcsomag között nem volt egyéb kérés, így biztosak lehetünk benne, hogy ez a válaszcsomag valóban az előzőekben vizsgált HTTP GET kérésünkre érkezett. Ezen csomag elkapásának időpillanata: 7.158797. Annak tudatában, hogy a HTTP kéréseket mindenképp egy TCP kézfogás előzi meg (SYN, SYN/ACK, ACK), a teljes csomaglistában további információkra is fényt deríthetünk. Szerver oldal vizsgálata Miután a kliens oldali szűrésnél elkapott csomagokból kinyertük a számunkra hasznos információkat, nézzük most meg a szerver oldali szűrés eredményét. Elöljáróban fontos megjegyezni, hogy a szerver és kliens oldali szűrések indítása nem szükségszerűen összehangolt, így koránt sem biztos, hogy az a csomag, ami a kliens oldali szűrés 7. másodperce környékén lett elküldve, az a szerver oldali szűrés 7. másodperce környékén érkezett meg, hisz a szerver oldali szűrés indulhatott sokkal korábban, de akár jóval később is, mint a kliens oldalon. Több dologra is fel kell készülnünk: nevezetesen, hogy a kliens gép IP címe a hálózati forgalom során NAT-olva lett, ezáltal az előző pontban megtalált privát címre hiába is szűrnénk, nem kapnánk eredményt, továbbá, hogy a kliens az úgynevezett biztonságos böngészés (safe browsing) érdekében előfordulhat, hogy több, a www.google.com szervercsaládhoz tartozó szerverrel is megpróbálhatott kommunikálni. Bagóczki Zsolt 2017 9

Amit biztosan tudunk, hogy az általunk választott HTTP GET kérés milyen IP címre lett elküldve, valamint, hogy ez a kliens gépén milyen időpillanatban történt. Használjuk fel tehát az ismert cél IP címet: 64.233.169.104, és a következő szűrőkifejezéssel keressük meg azon csomagokat, melyek csak az adott IP cím felé érkeztek, vagy afelől indultak: http && ip.addr == 64.233.169.104 7. ábra Szűrő eredménye Látható, hogy az első HTTP GET kérés a szerver oldali szűrés alapján a 6.069168 időpillanatban érkezett be, vagyis ahogy azt előre sejtettük, a szerver és kliens oldali szűrés nem volt szinkronizálva, a szerver oldalán 1 időegységgel később lett elindítva. Azt is láthatjuk, hogy a cél IP cím megegyezik, viszont a forrás (Source) IP cím megváltozott. Azt is észrevesszük, hogy minden, a fent meghatározott szerver IP címre vagy címről történő kommunikáció ugyanazzal a kliens IP címmel párosul, így annak a gondolatát is elvethetjük, hogy talán más kliens is folytatott HTTP kapcsolatot a szerverrel. Ezek fényében beigazolódott az is, hogy a kliens oldaláról valóban történt hálózati címfordítás, a kliens privát címe NAT-olva lett, és új globális címet kapott. 3. táblázat Kliens IP címei Helyi (privát) cím Globális (nyílt) cím 192.168.1.100 71.192.34.104 Vizsgáljuk meg, a csomag esetében történtek-e változások (lásd 8., 9. ábrák), az IP címet leszámítva. A részletes csomag adatokat megnyitva a TCP résznél látható, hogy a port számok nem változtak, az előző pontban meghatározott 4335-ös számú portot használta a küldő, és a csomagot a 80-as HTTP portra küldte ki. A két csomag esetében a TCP szegmens hossza sem változott, 635 maradt mindkét helyen. Nem változott továbbá a Header hossza sem, és a flagek is maradtak érintetlenek. Egy dolog változott csupán, az ellenőrző összeg (checksum). Ennek egyszerű oka van: az ellenőrző összegek tartalmazzák magukban a forrás IP címét. Mivel ez a NAT-os címfordítás során menet közben megváltozott, ezáltal a csomaghoz tartozó ellenőrző összeg értéke is módosult. Bagóczki Zsolt 2017 10

8. ábra Kliens oldali csomag 9. ábra Szerver oldali csomag A teljes szűrést vizsgálva itt is lehetőség adódna a TCP kézfogás részletes vizsgálatára. Ellenőrző kérdések 1. Mi a különbség a statikus és dinamikus NAT között? 2. Mi a belső globális cím? 3. Mi a külső helyi cím? Általában mivel egyezik meg? 4. Mi a forgalomirányító szerepe dinamikus NAT esetén? 5. Mik az RFC 1918 által megszabott privát címtartományok? 6. Miért változott meg az ellenőrző összeg a megoldott példában? 7. Melyik időpillanatban küldi ki a szerver az első HTTP kérésre a válaszát? 8. A kliens oldalát vizsgálva mennyi idő telik el a kliens által kiküldött logo.gif-et tartalmazó HTTP GET kérés, és az erre érkezett válasz közt? Mi a szerver válasza? 9. A szerver oldalát vizsgálva, mely csomagra vonatkozik az utolsó előtti 204 NO CONTENT HTTP válasz? 10. A szerver oldalán nem a kliens oldalon látott IP cím jelent meg, mint küldő cím. Miért? Mi a neve a két különböző IP címnek? Mi a szerepük? Bagóczki Zsolt 2017 11

Linkek https://tools.ietf.org/html/rfc1918 https://www.certificationkits.com/cisco-certification/ccna-articles/cisco-ccnanetwork-address-translation-nat/cisco-ccna-nat-advantages-a-disadvantages/ https://www.cisco.com/c/en/us/support/docs/ip/network-addresstranslation-nat/26704-nat-faq-00.html https://computer.howstuffworks.com/nat.htm Bagóczki Zsolt 2017 12