/05.07.2004 20:43/

Az elmúlt években az orosz hálózati rendszergazdák körében divatba jött a FireWall ill NAT... Az Eserv-felhasználók a 90-es évek közepe óta ismerik a hozzáállásomat ezekhez a technológiákhoz, de néha ilyen kérdéseket tesznek fel a FireWall / NAT-ról az újoncok, és meg kell ismételnem magam. Ezért körülbelül egy éve írtam egy külön cikket a FireWallról, és ma NAT van.

Felirat

Hozzáadva: 2005.12.28. A Google jól összefoglalta a NAT-problémát: "Az otthonokban és irodákban egyre népszerűbb NAT-eszközök lehetővé teszik, hogy több gép megosszon egy internetcímet. Következésképpen az olyan alkalmazások, mint például a hangcsevegés, egyre nehezebbé válik, amelyekhez a társak számára szükség van közvetlenül szólítsák meg egymást, hogy megbízható peer-to-peer kapcsolatot alakítsanak ki." (A NAT-eszközök, amelyek egyre népszerűbbek az otthonokban és az irodákban, lehetővé teszik több gép megosztását egy internetes címet. Ennek eredményeként olyan alkalmazások, mint pl hangcsevegés a felek közvetlen megszólítását igényli, egyre nehezebb megbízható kapcsolatokat létrehozni pontról pontra.)

Dokumentum tartalomjegyzék

A NAT története

Először néhány szót a proxy / kapuzás / alagút igényének megjelenésének történetéről az Interneten, majd világosabbá válnak a különböző megközelítések lehetőségei és azok "hierarchiája". Mint ismeretes, már a 90-es évek elején megjósolták az IP-címek hiányát egy 4 bájtos címtérben (plusz pénzhiány egyes cégeknél címblokkok bérlésére. Ezért már 1994 márciusában megállapodtunk a címek "szegmentálásában" A közös térből – az IP-címek specifikus tartományainak kiosztása a helyi hálózatok számára és ezen IP-címek kizárása az interneten való használatból (http://www.ietf.org/rfc/rfc1597.txt 1994. március Címkiosztás privát internetekhez; idézet a jelen dokumentum céljára: "A szerzők remélik, hogy e módszerek alkalmazása jelentős megtakarítást eredményez a címek kiosztásában"). Ez a megoldás lehetővé tette a vállalatok számára, hogy kis IP-címblokkokat oszthassanak ki internetes szervereik számára, a LAN-on belül pedig a saját szükségleteikre szánt IP-címeket maguk a vállalatok osztották ki a helyi hálózatok tartományaiból. Ennek eredményeként a cég internetes szerverei (postai és www / ftp) könnyen elérhetőek voltak mind az internetről, mind a LAN-ról, a LAN-on belüli számítógépek pedig probléma nélkül tudtak kommunikálni ugyanazokkal az IP-protokollokkal. Ez a döntés azonban gátat állított a helyi hálózatok és az internet közé. ugyanaz az IP-cím használható különböző LAN-okban, és mivel Emiatt az Internet leállította a csomagok irányítását a LAN-ok számára kiosztott címblokkokhoz. Azok. valójában egy "fizikai akadály" (vezetékek elvágása nélkül, amit az orosz bankokban élveztek az első betörések után, és a FireWall telepítése nélkül, amit most imádnak). A hálózatok elszigetelődtek, mint a feladatok a modern operációs rendszerekben – mindegyiknek megvan a maga címtere. Ez a sorompó nem okozott gondot a postának, hiszen A vállalati levelezőszerverek a hálózatok szélére voltak telepítve, és az internetről és a LAN-ról is láthatóak voltak. De a LAN-ról külső forrásokhoz – az ftp-hez – való hozzáféréssel, és azokban az években még mindig egyre népszerűbbek voltak, a http-szerverekkel problémák kezdődtek. Ha korábban bármilyen számítógépről lehetett közvetlenül kapcsolatba lépni a szerverrel, most ez a lehetőség csak a számítógépekkel maradt valódi internetcímek mivel melyik LAN-on küldjön választ a visszatérési címben helyi címmel rendelkező IP-csomagra – a router nem fogja tudni meghatározni.

A probléma legegyszerűbb megoldása - a visszatérési cím helyettesítése a hálózati határon - a felszínen feküdt, és nem volt lassú a közzététel: 1994 májusában, i.e. két hónappal azután, hogy a "hálózatok szekciója" javasolta a NAT-specifikációt: http://www.ietf.org/rfc/rfc1631.txt The Network Address Translator (NAT) 1994. május A szerzők ezt "rövid távú megoldásként" hirdették meg, azaz. ideiglenes megoldás a megadott probléma egyfajta "hack", amíg a normál megoldások el nem terjednek. De mint tudod, semmi sem olyan állandó, mint az ideiglenes IPv6, a várakozásokkal ellentétben nem vert gyökeret gyorsan, és az elmúlt 10 évben egyre több csatának lehettünk tanúi a LAN és az internet határain. A NAT elterjedt, mert Azokban az években nem volt más elfogadható megoldás erre a problémára: az FTP klienseknek és a HTTP klienseknek (böngészőknek) nem volt idejük alkalmazkodni a megváltozott világképhez, nem tudtak külső erőforrásokkal LAN-ról dolgozni, így a határvonal kihúzása. számukra átlátszó, egyszerűen szoftvereket "becsaptak" NAT segítségével - a LAN-ból kifelé címzett összes IP-csomagot a határon a legegyszerűbb feldolgozásnak vetették alá: a visszatérési IP-címet a "határ" számítógép valódi címére cserélték, és visszafelé csere a bejövő csomagokban. Emellett általában a forrás LAN portszámát is lecserélték. a LAN különböző gépeiről származó csomagok ugyanazzal a portszámmal érkezhetnek. Azok. nem csak az IP-címeket fordítják le, hanem a portszámokat is (a fordítóportokat néha külön PAT rövidítésnek nevezik). A hagyományos osztályozásban a NAT-ot "statikus, dinamikus és maszkoló" csoportokra osztják, de a gyakorlatban elsősorban a harmadik típust használják, amely több ezer kapcsolat kiszolgálását teszi lehetővé LAN-ról egy valós címen keresztül (ideális esetben), ebben mindig portfordítást alkalmaznak. ügy. Egy NAT számítógépen vagy routeren + NAT a fordításhoz használt portok tartománya van lefoglalva, például 60 000-nél nagyobb számokkal (annak érdekében, hogy gyorsan megkülönböztessük ezeket a portokat a számítógép saját szükségleteihez kiosztott portoktól), valamint egy dinamikus aktuális táblázat. munkamenetek / címleképezések. Minden egyes átmenő csomag ellenőrzi ezt a táblázatot és portot, és megtörténik a megfelelő helyettesítések. Annyira egyszerű a technológia, hogy manapság egyre ritkábban találunk routert vagy kábelmodemet beépített NAT (és FireWall, olyan primitív, mint a NAT) nélkül, a NAT pedig már a hubban is megtalálható "ah kezdődő árakkal 40 dollárért. Nem is beszélve" ingyenes " "NAT a Windows számos legújabb verziójával a név alatt" kapcsolat megosztása"és" kapcsolat megosztása"A NAT-ot méltán népszerűvé tette a kliensszoftverek hozzáférhetősége, érthetősége/használata és igénytelensége.

NAT az internetes programok "szemén keresztül".

Ha a gyakorlatban minden ilyen egyszerű lenne, nem lenne érdekes, de természetesen, mint minden más szoftveres trükknél, a NAT-ban is azonnal elkezdtek belopózni a különféle kellemetlen mellékhatások. A NAT megjelenése idején az egyik legnépszerűbb protokoll az FTP volt, és ez a protokoll lett a NAT első emészthetetlen protokollja. Ez feltárt egy problémát, amelyet a NAT ez alatt a 10 év alatt semmilyen módon nem oldott meg sikeresen. A NAT keretein belül pedig általános esetben nem oldható meg, csak adott protokollokhoz lehetnek illesztések, de ezek az illesztések nem tekinthetők megbízható megoldásnak. Ez a probléma az, hogy egyes protokollokban, amelyek közül a legrégebbi az FTP, a kliens gép IP-címét továbbítják, és ezt az IP-címet használja a szerver az adatok átvitelére a kliens felé. Mivel a NAT esetében a LAN-ról futó kliensprogramot a NAT "becsapja", csak a saját helyi IP-címét tudja küldeni a szervernek, amelyhez a külső szerver a helyi hálózatok láthatatlansága miatt nem tud csatlakozni. Internet. ICQ protokollok, MS NetMeeting, RealAudio és sok más protokoll, amelyek fejlesztői láthatóan olyan hálózatokban ültek
NAT A NAT csak egyetlen megoldást tud kínálni erre a problémára – a portszámok alapján találja ki a fordítandó protokollt, és kezdje el figyelni az IP-csomagok tartalmát. Ha tartalmazzák az FTP-parancs PORT-ot, amely jelzi: a helyi kliens portját (szöveges parancs a csomag törzsében, és nem az IP-csomag fejlécében), akkor ne csak a fejléceket cserélje ki, hanem a teljes csomag, az ellenőrző összeg újraszámításával és a lehallgatás megszervezésével.egy bejövő port. Sajnos a NAT esetében a TCP-protokoll, amelyben az FTP-parancsok továbbításra kerülnek, egy streaming-protokoll, amely szerint a PORT parancs, amikor belép az IP-rétegbe, 2 csomagra osztható (vagy akár többre, az FTP-klienstől és a puffereléstől függően). az operációs rendszer). Ezért a NAT-hamisítás helyének megbízható észleléséhez "rekonstruálnia kell az eredeti TCP adatfolyamot, pufferelnie és újra össze kell raknia a csomagokat. Visszatérünk a" protokoll rekonstrukciójához "a NAT-ban, de egyelőre csak a multi- A lehetséges hibák szintje és a megbízhatatlanság ebben a folyamatban, ami a gyakorlatban abból adódik, hogy a NAT feletti PORT parancsot használó szabványos FTP mód általában NEM működik.

Ezért az FTP-protokoll „NAT-problémáját” speciális módon kell megkerülni az FTP-kliensekben vagy egy másik köztes speciális FTP-proxyban. Az FTP kliensben át kell váltani az ún. "passzív mód" - használja a PASV parancsot a PORT parancs helyett. A PASV megkéri az FTP-kiszolgálót, hogy nyisson meg magának egy további portot, és mondja meg a kliensnek a portját. A kliens ezután csatlakozik a megadotthoz (a NAT ismét megtéveszti, sugározza), és a munkamenet sikeres. Amellett, hogy támogatni kell a PASV módot az FTP kliensben (a szabványos ftp.exe nem rendelkezik), ez némi erőfeszítést igényel az FTP-szerver rendszergazdájától - különösen, ha a tűzfalak és a NAT-ok részben blokkolják ( mint FTP fejlesztő -szerverek az Eserv számára, ezeket a problémákat nem hallomásból ismerem). Általában itt a NAT nem segíti a csatlakozást, hanem zavarja.

Most a NAT-on belüli protokoll rekonstrukciójáról a kliens számára átlátható megoldás érdekében. Az a néhány NAT, amely ezt megteheti (bár a gyakorlatban inkább deklarálják, mintsem hogyan tudják, de valójában egy hálózati szinttel feljebb lépnek - a fejlécben címfordítással ellátott csomagok legegyszerűbb továbbítása helyett ugyanazt kezdik el csinálni, mint a TCP stack csinál - TCP áramlást csomagokból összeállítva.Így a túlfejlett routerből alulfejlett TCP-alkalmazás proxyvá alakulnak.Ebben az esetben FTP proxy vagy FTP gate Alulfejlett mert a kliens nem tud erről a proxyról,és NAT viszont továbbra is találgatja a protokollt, és olyan feladattal foglalkozik, amelyet annak szintjén (IP-csomagok szintjén) nem lehet megoldani.

Sokkal könnyebb megoldani ezt a problémát, ha a NAT helyett vagy mellette azonnal speciális proxyt (FTP-kapu) vagy univerzális TCP-proxyt, például Socks-t vagy extrém esetben httpS-t használ (ez az extrém eset azonban jobban működik, mint NAT). Kezdetben TCP szinten dolgoznak, és nem megtévesztik az FTP klienst, hanem együttműködnek vele. A problémák három rétege tűnik el egyszerre: az FTP-kliens bármilyen módot használhat - aktív vagy passzív (httpS-ben csak passzív, mint a NAT-ban), nem kell kitalálni a protokollt és a dupla TCP-összeállítást. Ezenkívül az adminisztrátornak több lehetősége van a folyamat befolyásolására (erről később).

Ha a kliensprogram nem tudja, hogyan kell speciális proxy-n keresztül dolgozni (gyakorlatilag nincs ilyen proxy, de a legrosszabb esetekről beszélünk), akkor Socks proxy használatakor a kliens munkája is átláthatóvá tehető SocksCapture programokkal. vagy hazai FreeCap. A határ átlátszósága mindig megtévesztés, de a SocksCapture vagy a FreeCap nem IP csomagokat, hanem programhívásokat fog el az operációs rendszer felé, így mindig biztosan tudják, és nem a csomagfolyamból számolják ki, hogy a program pontosan milyen műveletet akar végrehajtani, és ennek megfelelően átirányítja. ezeket a műveleteket a Socks -proxy segítségével.

NAT vs Socks

Amíg a Socks témánál tartunk, néhány szót kell ejtenem erről a proxy protokollról. Sőt, történelmileg a Socks volt a NAT után a következő eszköz, amely átlépte a LAN és az internet határát: 1994 októberében jelent meg az első áttekintő cikk, "mi a zokni", hamarosan megjelent a Socks4 specifikáció (a korábbi "verziókat" nem használták egyetlen termékek) http://www.socks.nec.com/protocol/socks4a.protocol, és csak az 1996. márciusi 5. verzió érett meg az ietf-ben RFC-ként való közzétételre: http://www.ietf.org/rfc/rfc1928. txt. Ennek a dokumentumnak van egy orosz változata - a fordítást Alexander Gorlach készítette, aki akkoriban (97. és 98.) a cégünknél dolgozott, és részt vett az Eserv / 2 létrehozásában, lásd a Socks5 oldalt.

A Socks legyőzte a NAT összes korlátját, és legalább három kényelmes eszközt ad hozzá, amelyek nemcsak szinte bármilyen TCP- és UDP-protokoll "proxy"-ját teszik lehetővé, hanem az internet LAN-ról történő használatának javítását is:

1. A Socks nem csak a kimenő kapcsolatokat szolgálja ki, hanem lehetővé teszi, hogy proxy kliens kérésére lehallgató bejövő socketeket hozzon létre egy proxy gépen (BIND metódus) – ez csak az FTP és hasonló, többszörösen összekapcsolt protokollokhoz szükséges.
2. A Socks4a és a Socks5 lehetővé teszi, hogy eltávolítsa az ügyfélről a tartománynevek feloldásának feladatát az ügyfélen, és ezt közvetlenül a proxyban végezze el. Azok. a LAN-on belüli gép feleslegessé válik DNS szerver vagy DNS leképezés (NAT-on vagy speciális UDPMAP-on keresztül), a gondjainak egy "pipa" kikerül az adminisztrátorból, plusz a szerveren lévő DNS cache miatt gyorsabban dolgozik a kliens.
3. A Socks5 számos lehetőséget támogat az explicit ügyfél-hitelesítéshez és -engedélyezéshez. A NAT-ban csak úgy lehetett különbséget tenni barátok és ellenségek között.

De bár a Socks javította a használhatóságot a NAT-hoz képest, továbbra is univerzális "programozható leképezés". A NAT-problémák egy része megoldatlan maradt benne. Ezeket pedig nem lehet alacsony szinten megoldani az adott proxy protokoll részleteinek megértése nélkül. Csakúgy, mint például a telefon képes emberi beszédet továbbítani, de nem képes megérteni és kiszűrni a visszaéléseket, ezért azok a rendszergazdák, akik teljes ellenőrzést szeretnének elérni a hálózatukon zajló események felett, speciális proxyt használnak.

NAT és speciális proxyk a rendszergazda szemével

Újra először kis kirándulás a történelembe. A HTTP protokollt a 90-es évek elején fejlesztették ki (az ún. "0.9-es verzió"), és a 90-es évek közepére az internet "gyilkos alkalmazásává" vált – ezért nem csak a tudósok és a katonaság kezdett kapcsolódni az internetre, de a "közönséges kereskedők és hétköznapi emberek" is. Ennek megfelelően megérett az igény a szabványosításra. 1996 májusában adták ki a HTTP / 1.0 specifikációt a mérföldkőnek számító RFC: 1945 nyertes szám alatt. A specifikáció készítői már figyelembe vették az internet új realitásait, pl. a LAN protokoll proxyjának szükségessége. Emellett a gyakorlatban a HTTP több mint egy éve létezik, és "proxy tapasztalattal" rendelkezik. Ezért a dokumentum megtette a szükséges definíciókat és megjegyzéseket a proxykkal, átjárókkal és alagutakkal kapcsolatban. És valójában nem csak magát a HTTP protokollt (egy rendes webszerver szemszögéből) definiálták ott, hanem a HTTP-proxy és HTTPS-proxy protokollokat is. A "CONNECT" metódus, amelyet kifejezetten a HTTP-protokollba vezettek be, hogy lehetővé tegye a biztonságos HTTP-kiszolgálókhoz proxyn keresztüli csatlakozást, mindazonáltal lehetővé tette, hogy ne korlátozódjon a 443-as portra, hanem bármely port megadását a csatlakozáshoz. Így a HTTPS-proxyval szemben bármely protokollhoz egy másik "programozható TCP-leképezést" kapunk, bár sokkal korlátozottabb képességekkel, mint a Socks5. A natív HTTP-protokollhoz tartozó HTTP-proxy egészen más kérdés. A dolog teljes ismeretében képes kezelni - gyorsítótár, URL és tartalom szerinti szűrés, korlátozás, útvonal, engedélyezés stb. Ezek a műveletek gyakran olyan nem triviális műveleteket igényelnek a TCP és más operációs rendszer-összetevők szintjén, amelyek gyakorlatilag lehetetlenek csomagszintű NAT vagy a Socks vakleképezésével.

Ugyanez vonatkozik minden olyan alkalmazásprotokollra, amelyhez speciális proxyk léteznek – ezek mindig egy nagyságrenddel jobban kezelhetőek, mint az univerzális alacsony szintűek. Például sok POP3-proxy lehetővé teszi a levélszemét szűrését, ilyen például a PopFile (bár sokkal helyesebb a levélszemét szűrése nem a proxy-n, hanem az SMTP-kiszolgálón). A zokni és a NAT speciális készségeket igényelne a továbbított protokoll megértéséhez, pl. Valójában a POP3 proxyk "emulációja" nem túl kényelmes ehhez az eszközhöz.

Ezért a Socks vagy a NAT használata olyan protokollokkal való együttműködésre, amelyekhez speciális proxyk (HTTP, HTTPS, FTP, SMTP, POP3, IMAP) vagy a köztes szerverek általánosan elfogadott architektúrája (SMTP, POP3, IMAP, DNS) rendelkeznek. kényszerű nem optimális megoldásnak tekinthető. Kénytelen - vagy abból ered, hogy szervezeti okokból nem lehet használni a szükséges típusú proxyt (nincs hova tenni a szükséges típusú proxyt, vagy a kapcsolat típusa nem biztosítja egyetlen valós IP-cím jelenlétét, mint az az Internet GPRS-en vagy otthoni hálózati opciókon keresztül - ezekben az esetekben a NAT vagy a "kényszeres HTTP proxy" már a szolgáltató oldalán áll), vagy a felelős személyek, pl. adminok. Nem veszem figyelembe az anyagi korlátokat, mert Számos lehetőség kínálkozik ingyenes vagy nagyon olcsó proxykra ezekhez a protokollokhoz.

Egyes esetekben a Socks5 használata meglehetősen indokolt - például ICQ és más hírnökök esetében. Ezekhez a protokollokhoz egyszerűen nincs kifejlesztve speciális proxy, mivel szinte láthatatlanok a hálózathasználat általános hátterében. Gyógyszer hiányában levelezőszerver vagy pop3 / smtp-proxy Socks5 is lesz a következő jelölt, bár nem minden levelezőkliens támogatja, és némelyikben nyilvánvaló funkciók is vannak (lásd Mozilla ThunderBird).

A NAT opciók közötti iterálásnál ez lesz az "utolsó megoldás" - ha nem találtak jobbat, vagy ha a NAT-ot eredetileg a szolgáltató biztosította - kábelmodemben, routerben, mobilkapcsolatban (ezekbe a vasdarabokba a NAT kerül , nem egy speciális proxy a népszerű protokollokhoz, alapvető megvalósításának rendkívüli egyszerűsége miatt: egy hasonló NAT UDPMAP bővítmény forráskódja az Eproxyban mindössze 4 Kb méretű). A protokollok egy része nem fog működni, nehéz lesz a munka menedzselése. De ilyen szélsőséges esetekben jobb valahogy dolgozni, mint nem dolgozni.

Itt van egy részletes magyarázata az elmúlt 8 év jól ismert álláspontomnak - "soha nem lesz NAT az Eservben" Az esetek túlnyomó többségében vagy nincs szüksége NAT-ra, vagy már meg is van büntetésül. szolgáltató kiválasztása. Windows kapcsolatmegosztásban pontosan úgy működik, mint a NAT.

Lásd még: "mankó" a NAT-hoz a Microsoft webhelyén: NAT bejárás – NAT bejárás alkalmazások adaptálásával, NAT/Tűzfal konfiguráció UPnP-n keresztül. Ha először hallja a NAT-bejárás kifejezést, az azért van, mert a fejlesztők a Socks5-öt részesítik előnyben a mankók helyett a javításoknál, és ez a kezdeményezés nem kapott "kódtámogatást". De a cikk jó a képei miatt (ellentétben az enyémmel és egy másik független NAT-problémák leírásával.

A NAT, ICS már minden új Windows-verzióba be van építve

Mindenben Windows verziók 1999 óta a NAT is benne van. Először ICS (Internet Connection Sharing) néven, később pedig saját NAT néven. Itt található a NAT engedélyezése a Windows 2003 rendszerben (az "Útválasztás és távelérés" system32rrasmgmt.msc segítségével).

Windows XP rendszerben a NAT / ICS engedélyezve van az internetkapcsolat tulajdonságainál.

Ha a "Nem engedélyezhető a megosztás. Hiba: 1722: Az RPC-kiszolgáló nem érhető el" üzenet jelenik meg. ("A megosztott hozzáférés engedélyezése nem lehetséges. Hiba: 1722: Az RPC-kiszolgáló nem elérhető."), Akkor valószínűleg leállította vagy letiltotta a DHCP-kliens szolgáltatást, az ICS engedélyezése előtt el kell indítania.

NAT egy Linux-szolgáltató szemével

(Kiegészítés 2004. július 6. – az első válasz a cikkre. Ahogy a FireWallról szóló cikkben, most is adjuk át a szót az igazi rendszergazdának

Idézet Ha összehasonlítjuk a NAT-on keresztüli munkát az igazival, akkor a NAT-tal eddig csak hang-, kép- és fájlátvitellel volt gondom, például az MSN Messenger-ben. Talán a NAT egyes megvalósításaiban "és az aktív ftp-vel, külső VPN-kiszolgálókhoz való csatlakozással stb. is vannak problémák, de a NAT-on keresztül Linux alatt" (a megfelelő beállításokkal) ezzel nincs probléma. A NAT előnye ebben az esetben az IP-címek és a tűzfalak mentésében rejlik.

Ha összehasonlítjuk a NAT-ot egy proxyval (az internet elérésének módjaként, azaz a kérések továbbítása a gyorsítótárazás, az URL-elemzés stb. funkcióinak figyelembe vétele nélkül), akkor a NAT-on keresztül működik. További alkalmazásokés protokollok (minden); nem szükséges a NAT-hoz speciális beállítások a felhasználó által; A proxy-k hardverigényesebbek. A proxy-k általában nem biztosítanak cél-NAT (DNAT) funkciót, bár az Eservben a DNAT részleges hasonlósága érhető el tcp / udp leképezéssel. Az idézet vége.

Ez az idézet azt mutatja, hogy a szolgáltatók követelményei is nagyon különböznek a vállalatok rendszergazdáitól.

Vissza hivatkozások
Cikkek
Tűzfal
MxServer
NCSI
WhatIsProxyServer

Ma már nem újdonság, hogy az IP hálózati címek nem elegendőek minden internetezni vágyó eszköz számára. Ebből a helyzetből jelenleg az IPv6 protokoll fejlesztése talált kiutat, amelyben a cím hossza 128 bit, míg a jelenlegi IPv4 csak 32 bites. De a 2000-es évek elején egy másik megoldást találtak – a hálózati címfordítást, vagy röviden nat-et. A cikk további részében a nat az útválasztóban lesz konfigurálva.

Belépés a router beállítási menüjébe

Vegyük például a ZyXEL ZyWALL USG és NXC5200 sorozatú routert.

Először is menjen a router beállításaihoz. Ehhez bármelyik webböngészőben írja be a 192.168.1.1 címet a címsorba. (az útválasztó szabványos címe), megjelenik egy ablak, amelyben meg kell adnia felhasználónevét és jelszavát.

A „Felhasználónév” mezőbe írja be az admin, a „Password” mezőbe írja be az 1234-et. Kattintson az „OK” gombra.

A nat konfigurálása egy útválasztóban

A megnyíló menüablakban lépjen a "Konfiguráció" fülre (egy két fogaskerekes ikon), majd a "Hálózat", majd az "Útválasztás" menüpontra. A kiválasztott ablakban lépjen a „Házirend-útválasztás” fülre.

A ZyXEL router beállítási menüje

V ezt a menüt az útválasztási szabályzat konfigurálva van. A "Criteria" területen konfiguráljuk a forgalom mintavételezési feltételeit - melyik forgalmat kell sugározni (valójában konfigurálni kell a nat-t), és melyiket kell egyszerűen irányítani. A forgalom több szempont szerint is kiválasztható:

1. Felhasználó (Felhasználó);
2. Interfész szerint (bejövő);
3. forrás IP-cím szerint (Source Address);
4. A címzett IP-címe (Cél címe) alapján;
5. Cél port szerint (Szolgáltatás).

A "Next-Hop" területen rendeljen hozzá egy objektumot a forgalom átirányításához:

Átirányítási objektum kiválasztása ZyXEL útválasztóhoz

Ahol "Auto" - a forgalom az alapértelmezett globális interfészre lesz átirányítva; Gateway - az átjáró beállításaiban megadott címre; VPN Tunnel – IPSec virtuális magánalagút; Trunk - egy útvonal a "trönkhöz", ahol a "törzs" több interfész, amelyek együtt vagy redundáns módban működnek; Interfész - átirányítás a megadott interfészre:

Fontos, hogy ne felejtse el megnyomni az "OK" gombot, amikor bármilyen módosítást végez az útválasztó beállításain a beállítások mentéséhez, és ne csak bezárja a webböngészőt.

A nat beállítása számítógépen

Mint tudják, a személyi számítógép maga is útválasztóként szolgálhat. Gyakran előfordul olyan helyzet, amikor több számítógépből álló számítógépes hálózat van, amelyek közül az egyik rendelkezik internetkapcsolattal. Ebben a helyzetben egyáltalán nem kell routereket vásárolni, hanem be kell állítani egy internet-hozzáféréssel rendelkező számítógépet routerként, és már konfigurálni rajta a nat-t. Tekintsük ezt az esetet részletesebben.

Győződjön meg róla, hogy 2 telepítve van a fő számítógépen, amely az internetet nézi (nevezzük SZERVERnek) hálózati kártyák- az első csatlakozik a helyi hálózathoz, a második a szolgáltatóhoz. A példa a műveletet fogja használni Windows rendszer Szerver 2012.

A beállításhoz először futtassa a "Kiszolgálókezelőt" (Start -> Felügyeleti eszközök -> Kiszolgálókezelő). Megjelenik a beállítások ablak:

Innentől fogjuk kezelni a szerverünket. A konfiguráció folytatásához kattintson a Szerepkörök és szolgáltatások hozzáadása elemre, amely megnyitja a Szerepkörök hozzáadása varázslót. Első lépés - Telepítés típusa:

A következő ablakban ki kell választanunk a szerepkört, amelyet telepítünk a szerverre. A "Távoli elérés" elé egy jelzőt tettünk.

A következő ablak jelenik meg, amely a működéshez szükséges összetevők listáját jeleníti meg. Kattintson az "Összetevők hozzáadása" gombra, ez az ablak eltűnik. Kattintson a "Tovább" gombra.

A következő ablakban a varázsló felajánlja a szerver összetevők hozzáadását. Semmit nem kell módosítania, kattintson a "Tovább" gombra.

A következő oldal a varázsló egyszerűen tájékoztat bennünket a „Távoli hozzáférés” szerepkör munkájáról. Kattintson a "Tovább" gombra.

A következő lépés a szerepszolgáltatások kiválasztása. Pipát teszünk az „Útválasztás” elé, kattintson a „Tovább” gombra.

A következő ablak ismét tájékoztató jellegű, nem kell semmit sem kijelölni, de bepipálhatod az "Automatikus újraindítás a kiválasztott szerveren..." melletti négyzetet, aminek eredményeként a szerver a telepítés után automatikusan újraindul. De manuálisan is megteheti. Kattintson a "Tovább" gombra.

Az utolsó lépés pedig a szerver közvetlen telepítése. A befejezés után nyomja meg a "Bezárás" gombot.

Szerver telepítés

Tehát az internethez csatlakozó számítógépet szerver módban konfiguráltuk. Most be kell állítani rajta a nat-ot.

Nyissa meg a Start / Adminisztráció / Útválasztás és távelérés menüpontot. A megjelenő ablakban a bal oldalon találjuk a "SZERVER (helyi)" elemet, kattintson rá jobb gombbal, majd a legördülő menüben kattintson az "Útválasztás és távoli hozzáférés konfigurálása és engedélyezése" menüpontra.

Megjelenik az Útválasztás és távelérési kiszolgáló konfigurációs varázslója, amelyben a nat.

Az első oldalon röviden bemutatjuk a varázslót - kattintson a "Tovább" gombra. A következő lépésben ki kell választania a futni kívánt szolgáltatások egyikét ezt a szervert... Válassza a "Hálózati cím fordítása (NAT)" lehetőséget, majd kattintson a "Tovább" gombra.

Ezután a varázsló arra kéri, hogy válasszon olyan hálózati kapcsolatot, amely az internetet nézi. A lista mindkét hálózati kártyát tartalmazza (legalábbis attól függően, hogy hány van belőlük telepítve a szerveren). Kiválasztjuk azt, amelyikhez csatlakozik hálózati kábel szolgáltató. Kattintson a "Tovább" gombra.

A következő ablakban a varázsló esküdni kezd, hogy nem találja helyi hálózat DHCP vagy DNS szolgáltatások. Két lehetőség kínálkozik a folytatáshoz – engedélyezze az alapszolgáltatásokat, vagy telepítse a szolgáltatásokat később.

Kiválasztjuk az első elemet, kattintson a "Tovább" gombra. A következő oldalon tájékoztatom, hogy a nat melyik tartományban fog működni. A konfigurációs varázsló automatikusan kiválasztja ezt a tartományt a helyi hálózathoz csatlakoztatott hálózati kapcsolat konfigurációja alapján. Kattintson a "Tovább" gombra.

Nat tartomány

Ez az, a konfigurációs varázsló befejezi a nat beállítását. Kattintson a "Tovább" gombra, majd a következő ablakban a "Befejezés" gombra.

Utolsó dolog maradt az ügyfélszámítógépek, azaz a helyi hálózat összes többi számítógépének konfigurálása. Ehhez az ügyfél számítógépén (ezt a hálózat minden számítógépén meg kell tenni) lépjen a Start / Vezérlőpult / Hálózati és megosztási központ elemre / módosítsa az adapter beállításait. Lépjünk a "Hálózati kapcsolatok" oldalra. Kattintson a jobb egérgombbal az ikonra, és válassza ki a "Tulajdonságok" menüpontot a legördülő menüből. A megjelenő ablakban válassza az "Internet Protocol Version 4 (TCP / IPv4)" lehetőséget, kattintson a "Tulajdonságok" gombra.

A "Fő átjáró" után írja be a szerver számítógép IP-címét (amelyet az utolsó lépésben konfigurált), a "Preferred DNS server" mezőbe írja be a szolgáltató DNS-szerverének IP-címét, amely az Internet kapcsolat információiban van megadva. a szerver. Nyomjuk meg az "OK" gombot, majd ismét az "OK" gombot. Minden, a kliens számítógép csatlakozik az internethez.

Az útválasztó (router) működési elve

Ezt a cikket olvasva szerintem mindenki érti, hogy mi az a router és miért van rá szükség, de gondolt már valaki a működésére? Ebben a cikkben megpróbálom elmondani az útválasztó alapelveit a leginkább elérhető nyelven. Ez a cikk hasznos lesz mind a rendszergazdák, mind a hétköznapi felhasználók számára.

A fő funkció, amely minden útválasztóban működik, a NAT

NAT- A hálózati címfordítást az IP-címek helyettesítésére használják. A helyi hálózatokban főként 192.168.1.XXX típusú vagy hasonló címeket használnak, és ez útválasztási problémát okoz a globális interneten, mivel a hálózaton lévő IP-címeket nem szabad megkettőzni. A probléma megoldása a NAT - a helyi hálózaton lévő számítógépek csatlakoznak a router helyi interfészéhez, IP-címeket és átjárót kapnak onnan (a router átjáróként szolgál), a router WAN interfésze pedig csatlakozik az internethez. .

Most nézzük meg a NAT fordítás elvét:

• Kérelem érkezik a helyi hálózat bármely számítógépéről, például megpróbál hozzáférni bármely webhelyhez - a számítógép elküldi adott kérés az átjáró, azaz a routerünk címére;
• Az útválasztó, miután megkapta ezt a kérést, rögzíti az Ön számítógépét a kapcsolat kezdeményezőjeként, majd a csomag másolata létrejön és elküldi a célcímre, de a router nevében, annak IP-címével és az Ön csomagjával. egyszerűen megsemmisül;
• A szerver, amelyre a kérést küldték, feldolgozza azt, és természetesen választ küld a router címére. A router pedig már erre várt, hiszen készített egy rekordot, hogy a számítógéped kérésére válasz érkezzen, és elküldi a gépedre. Amint látható, ennek a sémának megfelelően csak a helyi hálózat számítógépe lehet a kapcsolat kezdeményezője, és a szerver válasza csak akkor érkezik meg a számítógéphez, ha az útválasztó vár rá (válasz a kérésre) . Más szóval, minden külső csatlakozási kísérlet megáll az útválasztónál, és csak akkor lesz sikeres, ha a router erőforrást biztosít a kért porton, vagy be van állítva a Port Forwarding szabályok, amiről most beszélünk.

Port továbbítás

Port továbbítás- ez lényegében megegyezik a NAT-tal, de a másik irányba, és ezért csak statikus NAT, vagyis bizonyos kérések csak bizonyos gépekhez, mert a globális hálózatban nem tudják a router mögötti IP címeket. Például létrehozott egy FTP vagy HTTP szervert a számítógépén, és hozzáférést szeretne biztosítani ezekhez az erőforrásokhoz, ehhez regisztrálnia kell ezt a szabályt az útválasztóban, amely jelzi, hogy minden bejövő csomag a kívánt portra (21 vagy 80) érkezik. esetünkben) a számítógépünk IP-címe egy adott portra kerül továbbításra (a port módosítható).

NAT - DMZ

NAT - DMZ- ez teljesen ugyanaz, mint a Port Forwarding, de azzal a különbséggel, hogy nem kell minden porthoz szabályt írni, csak be kell állítani a NAT - DMZ-t, amely továbbítja szükséges számítógép minden bejövő kérés az útválasztó WAN-jára. Természetesen már nem lehet portot váltani.

útvonalválasztás

Hogy leegyszerűsítsük, mi ez, azt mondhatjuk, hogy ugyanaz, mint a NAT, de csak mindkét irányban. Ennél a sémánál a routernek 2-nél több LAN interfésszel kell rendelkeznie (nem portokkal, hanem interfészekkel), különböző címterekkel, például az egyik IP interfészen 192.168.0.1, a másikon 192.168.1.1. Következésképpen az egyik hálózaton lévő számítógépek a 192.168.0.XXX, a másik hálózaton a 192.168.0.XXX IP-típust kapják, átjáróik pedig 192.168.0.1 és 192.168.1.1. Így érhető el a kétirányú útválasztás.

Ne felejts el elmenni

A nyilvános IPv4-címek száma nem elegendő ahhoz, hogy az internethez csatlakozó összes eszközhöz egyedi címeket rendeljenek. A legtöbb esetben a hálózatokat privát IPv4-címekkel valósítják meg az RFC 1918 szerint. Az 1. ábra az RFC 1918-ban szereplő címek tartományát mutatja. Valószínűleg az a számítógép, amelyen éppen az oktatóanyagot nézi, privát címet kapott.

Ezeket a privát címeket egy szervezeten vagy entitáson belül használják a helyi eszközök kommunikációjának megkönnyítésére. Mivel azonban ezek a címek nem azonosítanak egy adott vállalatot vagy szervezetet, a privát IPv4-címek nem használhatók az interneten keresztüli útválasztáshoz. Annak érdekében, hogy egy privát IPv4-címmel rendelkező eszköz hozzáférjen a helyi hálózaton kívüli eszközökhöz és erőforrásokhoz, a privát címet először nyilvános címmé kell feloldani.

ábrán látható módon. 2, a NAT privát és nyilvános cím fordítást biztosít. Ez lehetővé teszi a privát IPv4-címmel rendelkező eszközök számára, hogy hozzáférjenek a magánhálózatán kívüli erőforrásokhoz, beleértve az interneten található erőforrásokat is. A magán IPv4-címekkel kombinálva a NAT bizonyította értékét a nyilvános IPv4-címek mentésében. Egyetlen nyilvános IPv4-címet több száz, akár több ezer eszköz oszthat meg, amelyek mindegyike egyedi privát IPv4-címmel rendelkezik.

NAT nélkül az IPv4-címterület már jóval 2000 előtt kimerült volna. Előnyei ellenére a NAT-nak számos korlátja van, amelyeket a fejezet későbbi részében részletesen tárgyalunk. Az IPv4-kimerülés és a NAT-korlátozások megoldása az IPv6-ra való végső átállás.

NAT jellemzői

A hálózati címfordítás A NAT-ot különféle célokra használják, de ennek a mechanizmusnak a fő célja a nyilvános IPv4-címek megőrzése. Ezt úgy éri el, hogy lehetővé teszi a hálózatok számára, hogy privát IPv4-címeket használjanak belső kommunikációhoz, és csak szükség esetén alakítsák nyilvános címekké. A NAT további előnye – fokozott adatvédelem és hálózati biztonság – annak a ténynek köszönhető, hogy elrejti a belső IPv4-címeket a külső hálózatok elől.

A NAT-útválasztó egy vagy több érvényes nyilvános IPv4-címmel konfigurálható. Ezeket a nyilvános címeket NAT-címkészletnek nevezzük. Amikor egy belső eszköz forgalmat küld a hálózaton kívülre, egy NAT-kompatibilis útválasztó lefordítja az eszköz belső IPv4-címét a NAT-készlet nyilvános címére. A külső eszközök számára úgy tűnik, hogy a hálózatba érkező és onnan kilépő összes forgalom nyilvános IPv4-címeket használ a megadott címkészletből.

A NAT útválasztó általában egy zsákutca hálózat szélén fut. A csonkhálózat olyan hálózat, amely egyetlen kapcsolatot használ egy szomszédos hálózathoz, egy bejövő és egy kimenő útvonalat. Az ábrán látható példában az R2 egy élútválasztó. Az ISP szempontjából az R2 router zsákutca hálózatot hoz létre.

Ha egy zsákutca hálózaton lévő eszköznek csatlakoznia kell a hálózatán kívüli eszközhöz, a csomag egy szélső útválasztóhoz kerül továbbításra. A határútválasztó NAT-folyamatot hajt végre úgy, hogy az eszköz belső privát címét nyilvános, külső, irányítható címre fordítja.

jegyzet... Az internetszolgáltató hálózatához való csatlakozás magáncímet vagy a szolgáltató ügyfelei által megosztott nyilvános címet is használhat. A vizsgált téma keretében példaként közbeszólást adunk.

A NAT terminológiában a "belső hálózat" a fordításban részt vevő hálózatok összességét jelenti. A „külső hálózat” kifejezés az összes többi hálózatra vonatkozik.

NAT használatakor az IPv4-címek különböző célállomásokat jelentenek attól függően, hogy magán- vagy nyilvános hálózaton (internet) vannak-e, és hogy a forgalom bejövő vagy kimenő-e.

A NAT 4 típusú címet biztosít:

• belső helyi cím;

• belső globális cím;

• külső helyi cím;

• külső globális cím.

A használandó cím típusának meghatározásakor fontos megjegyezni, hogy a NAT terminológiát mindig a feloldható címmel rendelkező eszközök szempontjából alkalmazzuk:

• Belső cím az eszköz címe a NAT mechanizmus által lefordítva.

• Külső cím a céleszköz címe.

A NAT a lokalitás vagy globalitás fogalmát is használja a címekkel kapcsolatban:

• Helyi cím bármely cím, amely a hálózat belsejében jelenik meg.

• Globális cím bármely cím, amely a hálózaton kívül jelenik meg.

Az ábrán a PC1 belső helyi címe 192.168.10.10. A PC1 szempontjából a webszerver a 209.165.201.1 külső címet használja. Amikor a PC1 csomagokat küld a globális webszerver címére, a PC1 belső helyi címe 209.165.200.226 (a globális címen belül) lesz. A külső eszköz címét általában nem fordítják le, mivel ez a cím általában már nyilvános IPv4-cím.

Vegye figyelembe, hogy a PC1 különböző helyi és globális címeket használ, és a webszerver mindkettőhöz ugyanazt a nyilvános IPv4-címet használja. A webszerver szemszögéből úgy tűnik, hogy a PC1-ről származó forgalom a 209.165.200.226-ról, a belső globális címről származik.

A NAT router (az ábrán R2) jelenti a demarkációs pontot a belső és külső hálózatok, valamint a helyi és globális címek között.

A „belső” és „külső” kifejezéseket a „helyi” és „globális” kifejezésekkel együtt használjuk, amikor konkrét címekre hivatkozunk. Az ábrán az R2 NAT használatára van beállítva. A belső gazdagépekhez rendelt nyilvános címek készletét használja.

• Belső helyi cím a forráscím a belső hálózatból nézve. A PC1 ábrán az IPv4-cím 192.168.10.10. Ez a PC1 belső helyi címe.

• Belső globális cím a forráscím a külső hálózatról nézve. Az ábrán, amikor a PC1 forgalmat küld a webszervernek a 209.165.201.1 címen, az R2 a belső helyi címet belső globális címre fordítja. Ebben az esetben az R2 megváltoztatja az eredeti IPv4-címet 192.168.10.10-ről 209.165.200.226-ra. A NAT terminológiában a 192.168.10.10 belső helyi címet a 209.165.200.226 belső globális címre fordítják.

• Globális címen kívül a célcím a külső hálózatról nézve. Ez egy globálisan irányított IPv4-cím, amely egy gazdagéphez van hozzárendelve az interneten. Például a webszerver a 209.165.201.1 IPv4-címen érhető el. A legtöbb esetben a külső helyi és külső globális címek megegyeznek.

• Külső helyi cím a cél címe a belső hálózatból nézve. Ebben a példában a PC1 forgalmat küld a webszervernek a 209.165.201.1 IPv4-címmel. Ritka esetekben ez a cím eltérhet a globálisan irányított célcímtől.

Az ábra azt mutatja, hogy a belső számítógép által NAT-képes útválasztón keresztül egy külső webszervernek küldött forgalom hogyan történik. Azt is bemutatja, hogy a visszatérő forgalmat hogyan kezelik és térképezik fel.

jegyzet... A külső helyi cím használata túlmutat ennek az oktatóanyagnak a hatókörén.

A NAT hálózati címfordítás típusai

Három mechanizmus létezik a hálózati címek fordítására:

• Statikus hálózati cím fordítás (statikus NAT) a helyi és a globális címek egy az egyhez való megfeleltetése.

• Dinamikus hálózati címfordítás (dinamikus NAT) egy sok a sokhoz címleképezés a helyi és globális címek között.

• Port Address Translation (PAT) egy több az egyhez címleképezés a helyi és globális címek között. Ez a módszer túlterhelésnek is nevezik (NAT túlterheléssel).

Statikus hálózati címfordítás (NAT)

A statikus NAT egy-egy leképezést használ a helyi és a globális címek között. Ezeket a megfeleléseket a hálózati rendszergazda állítja be, és változatlanok maradnak.

Az ábrán az R2 útválasztó statikus leképezésekkel rendelkezik az Svr1, PC2 és PC3 belső helyi címeihez. Amikor ezek az eszközök forgalmat küldenek az internetre, belső helyi címeiket a rendszer lefordítja a megadott belső globális címekre. Külső hálózatokhoz ezek az eszközök nyilvános IPv4-címeket használnak.

A statikus hálózati címfordítási módszer különösen hasznos olyan webszervereknél vagy eszközöknél, amelyeknek állandó címmel kell rendelkezniük, amely elérhető az internetről – például egy vállalati webszerver esetében. A statikus NAT olyan eszközökhöz is alkalmas, amelyekhez hozzá kell férni az irodán kívül dolgozó felhatalmazott személyzet számára, de zárva kell maradniuk általános hozzáférés interneten keresztül. Például a PC4 hálózati rendszergazdája SSH-t tud küldeni az Svr1 (209.165.200.226) belső globális címre. Az R2 router ezt a belső globális címet belső helyi címre fordítja, és összekapcsolja az adminisztrációs munkamenetet az Svr1-gyel.

A statikus NAT elegendő számú nyilvános címet igényel az egyidejű felhasználói munkamenetek teljes számához.

Dinamikus NAT-cím fordítás

A Dynamic Network Address Translation (dinamikus NAT) nyilvános címek készletét használja, amelyek kiosztása érkezési sorrendben történik. Amikor a belső eszköz hozzáférést kér a külső hálózathoz, a dinamikus NAT hozzárendel egy elérhető nyilvános IPv4-címet a készletből.

Az ábrán a PC3 a dinamikus NAT-készlet első elérhető címével éri el az internetet. Más címek továbbra is használhatók. A statikus NAT-hoz hasonlóan a dinamikus NAT-hoz is elegendő számú nyilvános címre van szükség az egyidejű felhasználói munkamenetek teljes számának támogatásához.

Port Address Translation (PAT)

Más néven NAT túlterhelés, több privát IPv4-címet képez le egy vagy több nyilvános IPv4-címre. Ezt a módszert használja a legtöbb otthoni útválasztó. Az internetszolgáltató egyetlen címet rendel az útválasztóhoz, de egyszerre több családtag is elérheti az internetet. A NAT betöltése a leggyakoribb módszer a hálózati címek fordítására.

Ezzel a módszerrel több cím is leképezhető egy vagy több címre, mivel minden privát címet egy portszám is nyomon követ. Amikor egy eszköz elindít egy TCP/IP-munkamenetet, létrehoz egy TCP- vagy UDP-portértéket a forrás számára a munkamenet egyedi azonosítására. Amikor egy NAT-útválasztó csomagot kap egy ügyféltől, a forrásportszámot használja egy adott NAT-fordítás egyedi azonosítására.

A PAT biztosítja, hogy az eszközök más TCP-portszámot használjanak minden egyes munkamenethez egy kiszolgálóval az interneten. Amikor válasz érkezik a kiszolgálótól, a forrás port száma, amely a visszaküldésnél a célportszám lesz, meghatározza, hogy az útválasztó melyik eszközre továbbítsa a megfelelő csomagokat. A PAT folyamat azt is ellenőrzi, hogy a bejövő csomagokat valóban kérték-e, így növelve a munkamenet biztonságát.

Az ábrán látható Lejátszás és Szünet gombokkal vezérelheti az animációt.

Az animáció a portcím-fordítási (PAT) folyamatot szemlélteti. A fordítások megkülönböztetése érdekében a PAT mechanizmus egyedi forrásportszámokat ad a belső globális címhez.

Mivel az R2 minden csomagot feldolgoz, a portszámot (ebben a példában 1331 és 1555) használja az eszköz azonosítására, amelyről a csomag érkezett. A forráscím (SA) a belső helyi cím, hozzáfűzve a hozzárendelt TCP/IP portszámot. A célcím (DA) a külső helyi cím a hozzáfűzött szolgáltatási portszámmal. Ebben a példában a szolgáltatási port 80: HTTP.

A forráscímhez az R2 a belső helyi címet belső globális címre fordítja a hozzáfűzött portszámmal. A célcím nem változik, de mostantól külső globális IP-cím lesz. Amikor a webszerver válaszol, az útvonalat ismét bejárja, csak fordított sorrendben.

Az előző példában az 1331-es és 1555-ös ügyfélportszámok nem változtak a NAT-kompatibilis útválasztón. Ez a forgatókönyv nem túl valószínű, mert nagyon valószínű, hogy ezek a portszámok már használatban vannak más aktív munkamenetekhez.

A PAT megpróbálja megőrizni az eredeti forrásportot. Abban az esetben, ha az eredeti forrásport már használatban van, a PAT hozzárendeli az első elérhető portszámot, a megfelelő portcsoport elejétől kezdve - 0-511, 512-1023 vagy 1024-65535. Ha nincs több elérhető port, és több külső cím is van a címkészletben, a PAT a következő címre lép, és megpróbálja lefoglalni az eredeti forrásportot. Ez a folyamat addig folytatódik, amíg a rendelkezésre álló portok és a külső IP-címek kimerülnek.

A PAT működési elvének megismeréséhez kattintson az ábrán a "Play" gombra.

Az animációban a csomópontok ugyanazt a portszámot választják, az 1444-et. Ez egy belső címre érvényes, mivel a csomópontokhoz egyedi privát IP-címek vannak hozzárendelve. De NAT routeren a portszámokat meg kell változtatni. Ellenkező esetben két különböző csomóponttól származó csomagok ugyanazzal a forráscímmel lépnek ki az R2-ből. Ebben a példában a PAT fordítás során a második csomópont címéhez a következő elérhető port (1445) van hozzárendelve.

A NAT és a PAT összehasonlítása

Az alábbiakban felvázolt NAT és PAT közötti különbségek segítenek megérteni az egyes hálózati címfordítási módszerek sajátosságait.

Amint az ábrán látható, a NAT 1:1 arányban fordítja le az IPv4-címeket privát IPv4-címekre és nyilvános IPv4-címekre. Ugyanakkor a PAT megváltoztatja a címet és a portszámot is.

A NAT a bejövő csomagokat a nyilvános hálózaton lévő gazdagép által biztosított bejövő IPv4-forráscím használatával továbbítja a belső rendeltetési helyükre. A PAT használatakor általában csak egy ill kis mennyiségben nyilvánosan bemutatott IPv4-címek. A nyilvános hálózatról bejövő csomagokat a NAT útválasztó táblázat segítségével a magánhálózaton lévő célhelyekre irányítják. Ez a táblázat figyeli a nyilvános és a privát port párokat, amit kapcsolat leskelődésnek neveznek.

4. szegmensszint nélküli csomagok

Mi történik azokkal az IPv4-csomagokkal, amelyek nem TCP- vagy UDP-szegmenseket hordoznak? Ezek a csomagok nem tartalmaznak Layer 4 portszámot. A PAT az IPv4-en átvitt, TCP-t vagy UDP-t nem használó főbb protokollok többségét transzportréteg-protokolllá alakítja. E protokollok közül a leggyakoribb az ICMPv4. A PAT konverziós folyamat ezeket a protokollokat eltérően kezeli. Például az ICMPv4-kérési üzenetek, a visszhangkérések és a visszhang-válaszok tartalmaznak egy lekérdezési azonosítót. Az ICMPv4 lekérdezési azonosítót használ a visszhangkérés és a megfelelő visszhangválasz azonosítására. A kérésazonosító minden elküldött visszhangkéréssel növekszik. A PAT a kérésazonosítót használja a 4. réteg portszáma helyett.

jegyzet... Más ICMPv4 üzenetek nem használják a lekérdezésazonosítót. Ezek az üzenetek és egyéb protokollok, amelyek nem használnak TCP- és UDP-portszámokat, eltérhetnek egymástól, és ez az oktatóanyag nem foglalkozik velük.

NAT beállítása

Statikus NAT beállítása

Statikus hálózati címfordítás A NAT egy-egy leképezés a belső és külső címek között. A statikus NAT lehetővé teszi a külső eszközök számára, hogy statikusan hozzárendelt nyilvános címekkel kapcsolatot kezdeményezzenek belső eszközökkel. Például egy belső webszerver leképezhető egy belső globális címre, amely külső hálózatokról elérhető.

ábrán. Az 1. ábra egy privát IPv4-címmel rendelkező webszervert tartalmazó belső hálózatot mutat. A statikus NAT az R2-n úgy van konfigurálva, hogy a külső hálózatról (internetről) származó eszközök hozzáférjenek a webszerverhez. A külső hálózaton lévő kliens nyilvános IPv4-címmel fér hozzá a webszerverhez. A statikus NAT a nyilvános IPv4-címet privát IPv4-címmé alakítja át.

A statikus NAT konfigurálása két fő feladatot foglal magában.

1. lépés. Az első feladat egy leképezés létrehozása a belső-lokális és a belső-globális címek között. Például az ábrán. 1, a 192.168.10.254 belső helyi cím és a 209.165.201.5 belső globális cím statikus NAT-fordításként van konfigurálva.

2. lépés. A leképezés konfigurálása után a fordításban részt vevő interfészek a NAT belső vagy külső felületeiként vannak konfigurálva. Ebben a példában az R2 soros 0/0/0 interfésze a belső, a soros 0/1/0 pedig a külső interfész.

A beállított belső helyi IPv4-címről (192.168.10.254) az R2 router belső interfészén (Serial 0/0/0) érkező csomagokat lefordítják, majd továbbítják a külső hálózatra. Az R2 router külső interfészén (Serial 0/1/0) érkező, a konfigurált belső globális IPv4-címre (209.165.201.5) címzett csomagokat a belső helyi címre (192.168.10.254) fordítják le, majd továbbítják a belső hálózatba.

ábrán. A 2. ábra a statikus NAT beállításához szükséges parancsokat mutatja be.

ábrán. A 3. ábra azokat a parancsokat mutatja be, amelyek statikus NAT-leképezés létrehozásához szükségesek az R2-n lévő webkiszolgálóhoz a referencia topológiában. A bemutatott konfiguráció részeként az R2 a 192.168.10.254 címet a 209.165.201.5 nyilvános IPv4-címre konvertálja a webszerver által küldött csomagokban. Az internetes kliens a webes kéréseket a 209.165.201.5 nyilvános IPv4-címre irányítja. Az R2 továbbítja ezt a forgalmat a webszervernek a 192.168.10.254 címen.

Használja a Szintaxis-ellenőrzőt (lásd: 4. ábra) egy további statikus NAT fordítási bejegyzés beállításához az R2-n.

Ez az ábra a statikus NAT-fordítás folyamatát mutatja az ügyfél és a webszerver között az előző konfigurációt használva. A statikus átalakításokat általában akkor használják, ha a külső hálózatról (internetről) érkező ügyfeleknek a belső hálózaton lévő szerverekhez kell hozzáférniük.

1. Az ügyfélnek csatlakoznia kell a webszerverhez. Az ügyfél a 209.165.201.5 nyilvános IPv4 célállomás használatával küldi el a csomagot a webszervernek. Ez a webszerver belső globális címe.

2. Az első csomag, amelyet R2 kap egy ügyféltől a külső NAT interfészen, arra készteti az R2-t, hogy ellenőrizze a NAT tábláját. A cél IPv4-címe a NAT-táblázatban található, és az útválasztó ennek megfelelően fordítja le.

3. Az R2 lecseréli a 209.165.201.5 belső globális címet a 192.168.10.254 belső helyi címre. Az R2 ezután továbbítja a csomagot a webszervernek.

4. A webszerver fogadja a csomagot, és a 192.168.10.254 belső helyi címen válaszol a kliensnek.

5a. Az R2 egy csomagot kap a webszervertől a belső NAT felületén, amelynek forráscíme megegyezik a webszerver belső helyi címével, 192.168.10.254.

5b. Az R2 ellenőrzi a NAT táblát, hogy megnézze, van-e fordítás a belső helyi címhez. Ez a cím megjelenik a NAT táblában. Az R2 visszaalakítja a forráscímet a 209.165.201.5 belső globális címre, és továbbítja a csomagot a kliensnek a Serial 0/1/0 interfészén keresztül.

6. Az ügyfél átveszi a csomagot és folytatja a párbeszédet. A NAT router minden egyes csomagnál végrehajtja a 2-5b lépéseket (a 6. lépés nem látható az ábrán).

Statikus NAT ellenőrzés

A NAT működésének ellenőrzéséhez használja a parancsot ip nat fordítások megjelenítése... Ez a parancs megjeleníti az aktív NAT-fordításokat. A dinamikus fordításokkal ellentétben a statikus fordítások mindig jelen vannak a NAT táblában. ábrán. Az 1. ábra ennek a parancsnak a kimenetét mutatja az előző konfigurációs példához. Mivel a példa egy statikus konfiguráció, a fordítás mindig jelen van a NAT táblában, függetlenül az aktív kommunikációtól. Ha a parancsot egy aktív munkamenet során adjuk meg, a kimenet a külső eszköz címét is tartalmazza, amint az az ábrán látható. egy.

Egy másik hasznos parancs az ip nat statisztikák megjelenítése... ábrán látható módon. 2, csapat ip nat statisztikák megjelenítése

A NAT-fordítás megfelelő működésének biztosítása érdekében javasoljuk, hogy a tesztelés előtt törölje az összes korábbi fordítás statisztikáit a parancs használatával. törölje az ip nat statisztikákat.

Mielőtt kapcsolatba lépne a webszerverrel, a parancsot ip nat statisztikák megjelenítése ne mutasson egyezést. Miután az ügyfél munkamenetet hozott létre a webszerverrel, a parancs eredménye ip nat statisztikák megjelenítése Az egyezések száma 5-re nőtt. Ez megerősíti, hogy statikus NAT-fordítást hajtottak végre az R2-n.

A dinamikus NAT beállítása

Míg a statikus NAT állandó leképezést biztosít a belső helyi cím és a belső globális cím között, a dinamikus NAT támogatja a belső helyi címek automatikus leképezését belső globális címekre. Ezek a belső globális címek általában nyilvános IPv4-címek. A dinamikus NAT nyilvános IPv4-címek csoportját vagy készletét használja a fordításhoz.

A dinamikus NAT, akárcsak a statikus NAT, megköveteli a NAT-fordításban részt vevő belső és külső interfészek konfigurálását. Ha azonban a statikus NAT állandó leképezést hoz létre egyetlen címhez, akkor a rendszer címkészletet használ a dinamikus NAT-hoz.

jegyzet... A nyilvános és privát IPv4-címek közötti fordítás a NAT leggyakoribb használata. A NAT-fordítások azonban bármely címpár között előfordulhatnak.

Az ábrán látható referencia topológiában a belső hálózat az RFC 1918-ban meghatározott privát címtérből származó címeket használ. Két LAN csatlakozik az R1 útválasztóhoz - 192.168.10.0/24 és 192.168.11.0/24. Az Edge Router R2 dinamikus NAT-fordításra van konfigurálva a 209.165.200.226 és 209.165.200.240 közötti nyilvános IPv4-címek készletével.

A nyilvános IPv4-címek készlete (a belső globális címek készlete) a belső hálózat bármely eszköze számára elérhető érkezési sorrendben. A dinamikus NAT egy belső címet egy külső címre fordít. Az ilyen típusú fordításokhoz elegendő címnek kell lennie a készletben ahhoz, hogy lefedje az összes belső eszközt, amelynek egyidejűleg hozzá kell férnie a külső hálózathoz. Ha a készlet összes címe használatban van, az eszköznek várnia kell egy elérhető címre, hogy hozzáférjen a külső hálózathoz.

ábrán. bemutatja a dinamikus NAT beállításához használt lépéseket és parancsokat.

1. lépés. A parancs segítségével ip nat poolállítsa be a fordításhoz használandó címkészletet. Ez a címkészlet általában nyilvános címek csoportja. Ezeket a címeket a készlet kezdő és záró IP-címének megadásával határozzák meg. Kulcsszó hálózati maszk vagy előtag-hosszúságú jelzi, hogy a cím mely bitjei kapcsolódnak a hálózathoz és melyek a gazdagépcímek tartományához.

2. lépés.Állítson be egy szabványos ACL-t, hogy csak azokat a címeket határozza meg (engedje meg), amelyeket le kell fordítani. A túl sok megengedő parancsot tartalmazó ACL kiszámíthatatlan eredményekhez vezethet. Ne feledje, hogy minden ACL végén van egy sor tagadni mindent.

3. lépés Kösse az ACL-t a medencéhez. Csapat ip nat a forráslistán belülhozzáférési lista-számszámkészletmedence neve egy lista készlethez kötésére szolgál. Ezt a konfigurációt használja az útválasztó annak meghatározására, hogy mely eszközök ( lista) melyik címet kapja meg ( medence).

4. lépés. Azonosítsa azokat az interfészeket, amelyek a NAT-on belül vannak, pl. a belső hálózathoz kapcsolódó bármely interfész.

5. lépés. Azonosítsa a NAT-on kívüli interfészeket, pl. bármely külső hálózathoz csatlakoztatott interfész.

ábrán. A 2. ábra egy példa topológiát és a kapcsolódó konfigurációt mutat be. Ez a konfiguráció lehetővé teszi a 192.168.0.0/16 hálózaton a 192.168.10.0 és 192.168.11.0 helyi hálózatokat tartalmazó 192.168.0.0/16 hálózat összes gazdagépének konverzióját, amikor a gazdagépek forgalmat generálnak az S0 / 0/0-ba belépő és az S0 / 1/0-ból kilépő állomások számára. Ezeknek a csomópontoknak a címei a 209.165.200.226 és 209.165.200.240 közötti tartományban elérhető címekre vannak leképezve.

ábrán. A 3. ábra a szintaktikai ellenőrző konfigurálásához használt topológiát mutatja. Használja a szintaktikai ellenőrzőt az ábrán. 4 a dinamikus NAT fordítás konfigurálásához az R2-n.

Dinamikus NAT-elemzés

Az alábbi ábrák a dinamikus NAT fordítási folyamatot mutatják be két kliens és egy webszerver között az előző konfigurációt használva.

ábrán. Az 1. ábrán a forgalom belülről kifelé haladva látható.

1. A forrás IPv4-című gazdagépek (192.168.10.10 (PC1) és 192.168.11.10 (PC2)) nyilvános IPv4-címre (209.165.200.254) küldik a kiszolgálóhoz való csatlakozást kérő csomagokat.

2. Az R2 router megkapja az első csomagot a 192.168.10.10 állomástól. Mivel ez a csomag egy interfészen belüli NAT-ként konfigurált interfészen érkezett, az R2 ellenőrzi a NAT konfigurációt, hogy eldöntse, le kell-e fordítania ezt a csomagot. Az ACL engedélyezi ezt a csomagot, így az R2 átalakítja azt. Az R2 ellenőrzi a NAT tábláját. Mivel ehhez az IP-címhez nincsenek fordítási bejegyzések, az R2 úgy dönt, hogy a 192.168.10.10 forráscím dinamikus fordítást igényel. Az R2 kiválaszt egy elérhető globális címet a dinamikus címkészletből, és létrehoz egy fordítási bejegyzést - 209.165.200.226. Az eredeti IPv4 forráscím (192.168.10.10) a belső helyi cím, a fordításhoz használt cím pedig a belső globális cím (209.165.200.226) a NAT-táblázatban.

Az R2 megismétli az eljárást a második csomóponthoz, a 192.168.11.10-hez, kiválasztva a következő elérhető globális címet a dinamikus címkészletből, és létrehozva egy második fordítási bejegyzést, a 209.165.200.227.

3. Az R2 lecseréli a PC1 belső helyi forráscímét (192.168.10.10) a fordításhoz használt belső globális címre (209.165.200.226), és továbbítja a csomagot. Ugyanezeket a lépéseket hajtjuk végre a PC2 által küldött csomagra is, a PC2-nek megfelelő címet (209.165.200.227) használva fordításhoz.

1. ábra

ábrán. A 2. ábra a forgalom áramlását mutatja kívülről befelé.

4. A szerver megkapja a csomagot a PC1-től, és a 209.165.200.226 cél IPv4 címmel válaszol. A második csomag fogadásakor a szerver a 209.165.200.227 cél IPv4-címmel válaszol a PC2-nek.

5a. Amikor az R2 209.165.200.226 cél IPv4-című csomagot kap, az R2 útválasztó a NAT-táblázatba néz. Az R2 a tábla leképezését használja a cím visszafejtésére a belső helyi címre (192.168.10.10), és továbbítja a csomagot a PC1-nek.

5b. Amikor R2 209.165.200.227 cél IPv4-című csomagot kap, az R2 útválasztó a NAT táblában keres. Az R2 a tábla leképezését használja a cím visszafejtésére a belső helyi címre (192.168.11.10), és továbbítja a csomagot a PC2-nek.

6. A PC1 192.168.10.10 címmel és a PC2 a 192.168.11.10 címmel fogadja a csomagokat, és folytassa a párbeszédet. A NAT router minden egyes csomagnál végrehajtja a 2-5b lépéseket (a 6. lépés nem látható az ábrákon).

2. ábra

Dinamikus NAT ellenőrzés

Csapateredmények ip nat fordítások megjelenítéseábrán látható. 1 információkat tartalmaz a két korábbi NAT-hozzárendelésről. A parancs megjeleníti az összes konfigurált statikus címfordítást és a forgalomfeldolgozás eredményeként generált összes dinamikus fordítást.

Kulcsszó hozzáadása bőbeszédű további információkat jelenít meg az egyes átalakításokról, beleértve a bejegyzés létrehozása és felhasználása óta eltelt időt.

Alapértelmezés szerint a konverziós bejegyzések 24 óra elteltével lejárnak, hacsak nem módosították az időzítő beállítását a paranccsal ip nat fordítási időtúllépésidőtúllépés-másodperc globális konfigurációs módban.

A dinamikus bejegyzések lejárat előtti törléséhez használja a globális konfigurációs mód parancsot egyértelmű ip nat fordítás... Javasoljuk, hogy a NAT-konfiguráció ellenőrzésekor törölje a dinamikus bejegyzéseket. Ahogy a táblázatban látható, ez a parancs kulcsszavakkal és változókkal együtt használható annak meghatározására, hogy mely rekordokat kell törölni. Egyes bejegyzések törölhetők az aktív munkamenetek összeomlásának elkerülése érdekében. Az összes átalakítás eltávolításához a táblából használja a globális konfigurációs parancsot egyértelmű ip nat fordítás *.

jegyzet... Csak a dinamikus transzformációk törlődnek a táblázatból. A statikus konverziók nem távolíthatók el a konverziós táblából.

Amint látható, a parancs ip nat statisztikák megjelenítése információkat jelenít meg az aktív fordítások teljes számáról, a NAT konfigurációs paramétereiről, a készletben lévő címek számáról és a kiosztott címek számáról.

Alternatív megoldásként használhatja a parancsot futó-konfig megjelenítéseés keresse meg a NAT, ACL, interfész vagy pool parancsokat a kívánt értékeket... Gondosan tanulmányozza át az eredményeket, és javítsa ki a talált hibákat.

Port Address Translation (PAT) konfigurálása

A PAT port címfordítása (más néven NAT túlterheléssel) megőrzi a címeket a belső globális készletben azáltal, hogy lehetővé teszi az útválasztó számára, hogy egy belső globális címet használjon több belső helyi címhez. Más szavakkal, egyetlen nyilvános IPv4-cím több száz vagy akár több ezer belső IPv4 privát címhez használható. Az ilyen típusú fordítás konfigurálásakor az útválasztó elegendő magasabb szintű protokoll-információt tárol, például TCP- vagy UDP-portszámokat, hogy a belső globális címet a megfelelő belső helyi címre fordítsa. Ha több belső helyi címet egyetlen belső globális címhez köt, a rendszer TCP vagy UDP portszámokat használ a helyi címek megkülönböztetésére.

jegyzet... Az egy külső címre lefordítható belső címek száma elméletileg elérheti a 65 536-ot IP-címenként. Az egyetlen IP-címhez hozzárendelhető belső címek száma azonban körülbelül 4000.

Kétféleképpen konfigurálhatja a PAT-ot attól függően, hogy az internetszolgáltató hogyan osztja ki a nyilvános IPv4-címeket. Az első esetben az internetszolgáltató több nyilvános IPv4-címet oszt ki a szervezetnek, a második esetben pedig egyetlen nyilvános IPv4-címet, szükséges a szervezet számára az internetszolgáltató hálózatához való csatlakozáshoz.

A PAT beállítása nyilvános IP-címek készletéhez

Ha egy objektumhoz több nyilvános IPv4-cím is hozzá van rendelve, akkor ezek a címek a PAT által használt készlet részét képezhetik. Ez hasonló a dinamikus NAT-hoz, azzal a különbséggel, hogy nincs elég nyilvános cím a belső és külső címek közötti egy-egy megfeleltetés létrehozásához. Egy kis címkészletet sok eszköz oszt meg.

ábrán. Az 1. ábra a PAT címkészlet használatára való beállításának lépéseit mutatja. A fő különbség e konfiguráció és a dinamikus egy-egy NAT konfigurációja között a kulcsszó használata túlterhelés... Kulcsszó túlterhelés lehetővé teszi a PAT munkát.

ábrán látható konfiguráció példája. 2, létrehoz egy túlterhelési fordítást a NAT-POOL2 nevű NAT-készlethez. A NAT-POOL2 209.165.200.226 és 209.165.200.240 közötti címeket tartalmaz. Az átalakítás objektumai a 192.168.0.0/16 hálózat hosztjai. Az S0 / 0/0 interfész a belső interfész, és a külső interfész- S0 / 1/0 interfész.

Használja a szintaktikai ellenőrzőt az ábrán. 3 a PAT konfigurálásához az R2-n egy címkészlet használatával.

A PAT beállítása egy nyilvános IPv4-címhez

ábrán. Az 1. ábra egy PAT-megvalósítás topológiáját mutatja egyetlen nyilvános IPv4-cím lefordításához. Ebben a példában a 192.168.0.0/16 hálózaton (megfelelő ACL 1-nek) lévő összes gazdagép, amely az R2 útválasztón keresztül forgalmat küld az internetre, a 209.165.200.225 IPv4-címre lesz leképezve (az S0 / 1/0 interfész IPv4-címe). ). A forgalmi áramlásokat a NAT-táblázat portszámai határozzák meg, mivel túlterhelés.

ábrán. A 2. ábra a PAT egyetlen IPv4-címmel történő konfigurálásához szükséges lépéseket mutatja be. Ha csak egy nyilvános IPv4-cím áll rendelkezésre, a túlterhelési konfigurációhoz általában az internetszolgáltatóhoz csatlakozó külső interfész nyilvános címét rendelik. A külső interfészt elhagyó csomagokban lévő összes belső cím egyetlen IPv4-címre lesz lefordítva.

1. lépés. Határozzon meg egy ACL-t, amely lehetővé teszi a forgalom konverzióját.

2. lépés. A forrástranszformáció testreszabása kulcsszavak használatával felületés túlterhelés... Kulcsszó felület meghatározza a belső címek lefordításakor használandó interfész IP-címét. Kulcsszó túlterhelés utasítja az útválasztót, hogy kövesse nyomon az egyes NAT-bejegyzések portszámait.

3. lépés Adja meg a NAT-on belüli interfészeket. Ez bármely interfész, amely a belső hálózathoz kapcsolódik.

4. lépés. Adja meg a NAT-on kívüli interfészt. Ennek meg kell egyeznie a 2. lépésben a forrástranszformációs bejegyzésben megadott interfészrel.

Ez a konfiguráció hasonló a dinamikus NAT-hoz, azzal a különbséggel, hogy a kulcsszó egy külső IPv4-cím meghatározására szolgál címkészlet helyett. felület... Ezért nincs NAT-készlet definiálva.

A szintaxis-ellenőrző segítségével konfigurálja a PAT-ot az R2-n egyetlen címmel.

PAT elemzés

A NAT túlterhelési fordításának folyamata ugyanaz, ha címkészletet vagy egyetlen címet használ. Folytatva az előző, egyetlen nyilvános IPv4-címet használó PAT-példát, a PC1-nek csatlakoznia kell az Svr1 webszerverhez. Ugyanakkor egy másik kliensnek, a PC2-nek hasonló munkamenetet kell létrehoznia az Svr2 webszerverrel. Mind a PC1, mind a PC2 privát IPv4-címekkel van konfigurálva, és a PAT engedélyezve van az R2-n.

Csomagok számítógépről szerverre történő átvitelének folyamata

1. Az ábrán. Az 1. ábra azt mutatja, hogy a PC1 és PC2 számítógépek csomagokat küldenek az Svr1 és Svr2 szervereknek. A PC1 a 192.168.10.10 IPv4-címet és az 1444-es forrás-TCP-portot használja. A PC2 a 192.168.10.11-es forrás IPv4-címet használja, és véletlenül ugyanazt az 1444-es TCP-portot használja.

2. A PC1-ről érkező csomag először az R2 routert éri el. A PAT használatával az R2 a forrás IPv4-címét 209.165.200.225-re módosítja (a globális címen belül). A NAT-táblázatban nincs más, az 1444-es portot használó eszköz, így a PAT ugyanazt a portszámot tartja. A csomag ezután továbbításra kerül az Svr1 szerverre a 209.165.201.1 címen.

3. Ezután egy csomag érkezik az R2 útválasztóhoz a PC2-ről. A PAT beállítás biztosítja, hogy minden fordítás ugyanazt a belső globális IPv4-címet használja, 209.165.200.225. A PC1 fordítási folyamatához hasonlóan a PAT megváltoztatja a PC2 IPv4 forráscímét a 209.165.200.225 belső globális címre. Ez a PC2-csomag azonban a PC1-et konvertáló aktuális PAT-bejegyzésben már szereplő forrásportszámot használja. A PAT addig növeli a forrás port számát, amíg az egyedi lesz az adott táblában. Ebben az esetben a forrásport-bejegyzés a NAT-táblázatban és a PC2-ről érkező csomag 1445-ös számot kap.

Bár a PC1 és a PC2 ugyanazt a lefordított címet használja, a belső globális cím 209.165.200.225, és ugyanaz a forrásportszám 1444, a PC2 megváltozott portszáma (1445) a NAT tábla minden bejegyzését egyedivé teszi. Ez akkor válik nyilvánvalóvá, amikor a szerverek visszaküldik a csomagokat a klienseknek.

A csomagok kiszolgálókról számítógépekre történő átvitelének folyamata

4. ábrán látható módon. A 2. ábrán látható, hogy egy tipikus kliens-szerver központban az Svr1 és Svr2 szerverek válaszolnak a PC1 és PC2 számítógépektől kapott kérésekre. A szerverek a fogadott csomag forrásportját használják a visszatérő forgalomhoz célportként, és a forráscímet célcímként. A szerverek úgy viselkednek, mintha egyetlen 209.165.200.225 csomóponttal kommunikálnának, de ez nem így van.

5. A csomagok fogadása után az R2 útválasztó egyedi bejegyzést talál a NAT táblában az egyes csomagok célcímének és célportjának felhasználásával. Ha csomag érkezik az Svr1-től, akkor a 209.165.200.225 IPv4 célcím több bejegyzésnek is megfelel, de ezek közül csak az egyik tartalmazza az 1444-es célportot. Ezzel a táblázatbejegyzéssel az R2 útválasztó a csomag cél IPv4 címét 192.168.10.10-re módosítja. Ebben az esetben nincs szükség a célport megváltoztatására. A csomag ezután továbbításra kerül a PC1-re.

6. Miután megkapta a csomagot az Svr2 szervertől, az R2 ugyanazt az átalakítást hajtja végre. Az útválasztó ismét megtalálja a 209.165.200.225 IPv4 célcímet több bejegyzéssel. Az 1445-ös célport használatával azonban az R2 egyedileg azonosítani tudja a leképezési bejegyzést. A cél IPv4-címe 192.168.10.11-re módosult. Ebben az esetben a célportot is vissza kell állítani a NAT táblában tárolt eredeti 1444-es értékre. A csomag ezután továbbításra kerül a PC2-re.

PAT ellenőrzés

Az R2 úgy van beállítva, hogy PAT-ot biztosítson a 192.168.0.0/16 hálózaton lévő ügyfelek számára. Amikor a belső gazdagépek az R2-n keresztül kimennek az internetre, a címeik feloldódnak a PAT-készlet IPv4-címére, egyedi forrásportszámmal.

A PAT-ellenőrzés ugyanazokat a parancsokat használja, mint a statikus és dinamikus NAT-ellenőrzés, amint az ábra mutatja. 1. Csapat ip nat fordítások megjelenítéseátalakításokat ad ki két különböző webhelyről különböző webszerverekre. Vegye figyelembe, hogy két különböző belső gazdagéphez ugyanaz a 209.165.200.226 IPv4-cím (belső globális cím) van hozzárendelve. A forrásportszámok a NAT-táblázatban a két tranzakció megkülönböztetésére szolgálnak.

ábrán látható módon. 2, csapat ip nat statisztikák megjelenítése lehetővé teszi annak ellenőrzését, hogy egy cím van-e kijelölve a NAT-POOL2-ben mindkét fordításhoz. A parancs kimenete információkat tartalmaz az aktív fordítások számáról és típusáról, a NAT-beállításokról, a készletben lévő címek számáról és a kiosztott címek számáról.

A NAT vagy a Network Address Translation egy módja annak, hogy az egyik címteret a másikhoz hozzárendeljük az Internet Protokollban vagy az IP-ben található hálózati címadatok megváltoztatásával. A csomagfejlécek az útválasztó eszközökön keresztül történő továbbítás során változnak. Ezt a módszert eredetileg a forgalom egyszerűbb átirányítására használták az IP-hálózatokon anélkül, hogy minden gazdagépet számozni kellett volna. Fontos és népszerű eszközzé vált a globális címtér kiosztására és karbantartására az IPv4-címek akut hiányával szemben.

Mi az a NAT?

A hálózati címfordítás célja, hogy minden címet leképezzünk egy címtérből egy másik címtérben lévő címre. Erre abban az esetben lehet szükség, ha a szolgáltató megváltozott, és a felhasználónak nincs lehetősége nyilvánosan bejelenteni az új útvonalat a hálózatnak. A globális címtér kimerülése miatt az 1990-es évek vége óta egyre gyakrabban alkalmazzák a NAT technológiát. Ezt a technológiát általában az IP-titkosítással együtt használják. Az IP-titkosítás olyan módszer, amellyel több IP-címet konvertálnak egyetlen térbe. Ezt a mechanizmust olyan útválasztó eszközben valósítják meg, amely perzisztens fordítási táblákat használ a rejtett címek egyetlen IP-címre való leképezésére. Ezenkívül átirányítja az összes kimenő IP-csomagot a kimeneten. Így ezek a csomagok az útválasztó eszközt elhagyó csomagokként jelennek meg. A visszacsatolási válaszok az eredeti IP-címre vannak leképezve a fordítási táblázatokban tárolt szabályok segítségével. A fordítási táblák viszont rövid idő után törlődnek, ha a forgalom nem frissíti az állapotát. Ez az alapvető NAT mechanizmus. Mit is jelent ez? Ez a technológia csak akkor teszi lehetővé az útválasztón keresztüli kommunikáció megszervezését, ha a kapcsolat titkosított hálózatban történik, mivel ez fordítási táblázatokat hoz létre. Egy ilyen hálózaton belül a webböngésző meg tud tekinteni egy azon kívül lévő webhelyet, de ha azon kívül van telepítve, nem tudja megnyitni a rajta tárolt erőforrást. A legtöbb NAT-eszköz manapság lehetővé teszi a hálózati rendszergazda számára, hogy állandó használatra konfigurálja a fordítási tábla bejegyzéseit. Ezt a szolgáltatást gyakran porttovábbításnak vagy statikus NAT-nak nevezik. Lehetővé teszi, hogy a "külső" hálózatba kimenő forgalom elérje a titkosított hálózat kijelölt gazdagépeit. Az IPv4 címtér megőrzésére használt technika népszerűsége miatt a NAT szó gyakorlatilag a titkosítás szinonimájává vált. Mivel a hálózati címfordítás megváltoztatja az IP-csomagok címinformációit, ez súlyos következményekkel járhat a kapcsolat minőségére nézve. Tehát nagy figyelmet igényel a megvalósítás minden részlete. A NAT használatának módjai eltérnek egymástól sajátos viselkedésükben a különböző helyzetekben, amelyek a hálózati forgalomra gyakorolt ​​hatáshoz kapcsolódnak.

Alap NAT

A NAT legegyszerűbb típusa lehetővé teszi az IP-címek egy az egyhez fordítását. Ennek az adásnak a fő típusa az RFC-2663. Ebben az esetben csak az IP-címek módosulnak, valamint az IP-fejlécek ellenőrző összege. Az alapvető fordítási típusok használhatók két inkompatibilis címzésű IP-hálózat összekapcsolására.

A legtöbb NAT-változat képes több privát gazdagépet egyetlen nyilvánosan kijelölt IP-címhez rendelni. Egy tipikus konfigurációban a LAN az alhálózathoz hozzárendelt „privát” IP-címek egyikét használja. Ezen a hálózaton az útválasztó magáncímmel rendelkezik a térben. Ezenkívül az útválasztó az internetszolgáltató által hozzárendelt „nyilvános cím” használatával csatlakozik az internethez. Mivel a forgalom a helyi internetről érkezik, az egyes csomagokban lévő forráscímeket menet közben lefordítják privátról nyilvánosra. A router minden aktív kapcsolat alapadatait is nyomon követi. Ez különösen az olyan információkra vonatkozik, mint a cím és a rendeltetési kikötő. Amikor a választ visszaküldi neki, a kilépési fázisban elmentett kapcsolati adatokat használja fel. Erre azért van szükség, hogy meghatározzuk a belső hálózat privát címét, amelyre a választ kell irányítani. Ennek a funkciónak a fő előnye, hogy praktikus megoldást jelent az IPv4 címtér kimerítésének problémájára. Még nagy hálózatok is csatlakoztathatók az internethez egyetlen IP-cím használatával. Az IP-hálózatok összes csomagadatcsomagjának két IP-címe van - a forráscím és a célcím. A magánhálózatból a nyilvános hálózatba utazó csomagok csomagforrás-címmel rendelkeznek, amely a nyilvánosról a magánhálózatra való áttérés során megváltozik. Bonyolultabb konfigurációk is lehetségesek.

A NAT konfiguráció jellemzői

A NAT konfiguráció specifikus lehet. További módosításokra lehet szükség a visszaküldött csomagok lefordításával járó gondok elkerülése érdekében. Az internetes forgalom nagy része UDP-n és TCP-n keresztül fog menni. A számuk módosul, így az IP-címek és a portszámok megegyeznek az adatok visszaküldésekor. A nem UDP-n vagy TCP-n alapuló protokollok eltérő fordítási módszereket igényelnek. Általában az ICMP vagy az Internet Message Control Protocol korrelálja a továbbított információkat a meglévő kapcsolattal. Ez azt jelenti, hogy azokat az eredetileg beállított IP-címmel és számmal kell megjeleníteni. Mit kell figyelembe venni? A NAT konfigurálása az útválasztón nem biztosít végpontok közötti kapcsolatot. Emiatt az ilyen útválasztók nem vehetnek részt egyes internetes protokollokban. Előfordulhat, hogy azok a szolgáltatások, amelyek TCP-kapcsolatok kezdeményezését igénylik a külső hálózatról vagy a nem protokollt használó felhasználókról, egyszerűen nem érhetők el. Ha a NAT router nem különleges erőfeszítések Az ilyen protokollok támogatásához a bejövő csomagok soha nem érik el a célt. Egyes protokollok ugyanabban a fordításban tárolhatók a részt vevő gazdagépek között, néha egy alkalmazási réteg átjáró használatával. A kapcsolat azonban nem jön létre, ha mindkét rendszert NAT segítségével leválasztják az internetről. Ezenkívül a NAT használata bonyolítja az alagútkezelési protokollokat, például az IPsec-et, mivel megváltoztatja a fejlécek értékeit, amelyek kölcsönhatásba lépnek a kérések integritás-ellenőrzésével.

NAT: létező probléma

Az internet alapelve a végpontok közötti kapcsolat. Megalakulása óta létezik. A hálózat jelenlegi állapota csak azt bizonyítja, hogy a NAT szabálysértés ezt az elvet... Professzionális környezetben komoly aggodalomra ad okot a hálózati címfordítás elterjedt használata az IPv6-ban. Így ma felvetődik a kérdés, hogyan lehet ezt a problémát kiküszöbölni. Mivel a NAT-útválasztókban a fordítási állapottáblázatok nem eleve állandóak, a belső hálózaton lévő eszközök nagyon rövid időn belül elveszítik az IP-kapcsolatot. Nem szabad megfeledkeznünk erről a körülményről, amikor arról beszélünk, hogy mi a NAT egy útválasztóban. Ez jelentősen csökkenti az újratölthető akkumulátorral és akkumulátorral működő kompakt készülékek működési idejét.

Méretezhetőség

A NAT is csak azokat a portokat figyeli, amelyeket a több párhuzamos kapcsolatot használó belső alkalmazások gyorsan kimeríthetnek. Lehet HTTP kérések sok beágyazott objektumot tartalmazó oldalakhoz. Ez a probléma enyhíthető a cél IP-címének követésével a porton kívül. Egy helyi portot így számos távoli gazdagép oszthat meg.

NAT: néhány komplikáció

Mivel az összes belső cím egyetlen nyilvános címnek van álcázva, lehetetlen, hogy a külső gazdagépek kapcsolatot kezdeményezzenek egy adott belső gazdagéppel anélkül, hogy speciális konfigurációt állítanának be a tűzfalon. Ennek a konfigurációnak át kell irányítania a kapcsolatokat egy adott portra. Az IP-telefónia, a videokonferencia és hasonló alkalmazások megfelelő működéséhez NAT bejárási technikákat kell használniuk. Rapt fordítási port visszaszállítási cím lehetővé teszi, hogy egy gazdagép, amelynek IP-címe időről időre változik, elérhető maradjon szerverként az otthoni hálózat rögzített IP-címét használva. Ennek elvileg lehetővé kell tennie a szerverbeállítás számára a kapcsolat megtartását. Bár ez a megoldás nem ideális, egy másik hasznos eszköz lehet a hálózati adminisztrátor fegyvertárában az útválasztón a NAT konfigurálásával kapcsolatos problémák megoldásához.

PAT vagy Port Address Translation

A Port Address Translation egy Cisco Rapt megvalósítás, amely több privát IP-címet képez le egyetlen nyilvános címre. Így több cím is leképezhető címként, mivel mindegyik portszámmal van nyomon követve. A PAT egyedi belső globális IP-forrás portszámokat használ az adatátvitel irányának megkülönböztetésére. Ezek a számok 16 bites egész számok. Az egy külső címre lefordítható belső címek száma elméletileg elérheti a 65536-ot. A valóságban körülbelül 4000 portok száma, amelyekhez egyetlen IP-cím rendelhető. A PAT általában igyekszik megtartani az eredeti címet. az "eredeti" kikötője... Ha már használatban van, a Port Address Translation hozzárendeli az első elérhető portszámot, a megfelelő csoport elejétől kezdve. Ha nincs elérhető port, és egynél több külső IP-cím van, a PAT a következőre lép, hogy kijelölje a forrásportot. Ez a folyamat addig folytatódik, amíg a rendelkezésre álló adatok el nem fogynak. A Cisco Service megjeleníti a címet és a portot. Egyesíti a fordítási port címét és az adatokat az IPv4-csomagok belső IPv6-hálózaton keresztüli alagútvezetéséhez. Valójában ez a Carrier Grade NAT és a DS-Lite alternatív verziója, amely támogatja a portok és címek IP-fordítását. Ezzel elkerülhetők a kapcsolat létrehozásával és fenntartásával kapcsolatos problémák. Átmeneti mechanizmust is biztosít az IPv6 telepítéséhez.

Fordítási módszerek

Számos fő módja van a hálózati cím és port fordításának. Egyes alkalmazásprotokollok megkövetelik a kapcsolat másik végén használt külső NAT-cím meghatározását. Gyakran szükséges az átvitel típusának tanulmányozása és osztályozása is. Ez általában azért történik, mert két különálló NAT-ok mögötti kliens között kívánatos egy közvetlen kommunikációs csatorna létrehozása. Erre a célra egy speciális RFC 3489 protokollt fejlesztettek ki, amely egyszerű UPD bejárást biztosít a NATS-en keresztül. Ma már elavultnak számít, mivel manapság az ilyen módszereket nem tartják elegendőnek az eszközök működésének helyes értékeléséhez. 2008-ban kifejlesztették az RFC 5389-et, és új módszereket szabványosítottak. Ezt a specifikációt ma Session Bejárásnak hívják. Ő képviseli speciális segédprogramúgy tervezték, hogy a NAT működjön.

Hozzon létre kétirányú kommunikációt

Minden UDP és TCP csomag tartalmazza a forrás IP-címét és portszámát, valamint a cél port koordinátáit. A portszám nagyon fontos a nyilvános szolgáltatások, például a levelezőszerver funkcióinak eléréséhez. Így például a 25-ös port az SMTP levelezőszerverhez, a 80-as pedig ehhez csatlakozik szoftver web szerver. A nyilvános szerver IP-címe szintén elengedhetetlen. Ezeket a paramétereket megbízhatóan ismerniük kell azoknak a csomópontoknak, amelyek kapcsolatot kívánnak létrehozni. A privát IP-címek csak a helyi hálózatokon relevánsak.