Ma megvizsgáljuk az internet-hozzáférés megosztásának és az automatikus hálózati konfigurációnak a Windows platformon történő megszervezésének kérdését. Annak ellenére, hogy ez egy drágább megoldás, alkalmazása a kiépített hálózati infrastruktúrával való szoros integráció esetén lesz indokolt. Windows Server.
Munkafelületként a Windows Server 2008 R2-t használtuk, mint ma a legkorszerűbb platformot, azonban minden elhangzott kisebb módosításokkal a Windows Server 2003/2008 korábbi verzióira is vonatkozik.
Kezdetben konfigurálnia kell a hálózati interfészeket. Esetünkben a szolgáltató hálózatába betekintő interfész DHCP-n keresztül kapja meg a beállításokat, átneveztük EXT-re. A belső interfész (LAN) statikus IP-címe 10.0.0.1, maszkja pedig 255.255.255.0.
A szervezés legegyszerűbb módja általános hozzáférés az Internethez engedélyezi a megfelelő opciót a hálózati kapcsolat beállításainál. Ez a módszer azonban minden egyszerűsége ellenére rendkívül rugalmatlan, és csak akkor fogadható el, ha nincs más útválasztási feladat a szerver elé. Jobb első pillantásra bonyolultabb utat választani, de egy nagyon hatékony és rugalmas eszközt találni, amely lehetővé teszi sokkal összetettebb hálózati problémák megoldását.
Kezdjük a várakozásoknak megfelelően egy új kiszolgálói szerepkör hozzáadásával: Hálózati házirend és hozzáférési szolgáltatások.
A szerepszolgáltatásoknál vegye figyelembe Útválasztási és távelérési szolgáltatások, minden más most nem érdekel minket. A szerepkör sikeres telepítése után folytathatja az útválasztási beállításokat.
BAN BEN Öntvény keresse meg az útválasztási szolgáltatást és a menün keresztül Műveletek választ Konfigurálja és engedélyezze az útválasztást és távoli hozzáférés . A beállítás egy varázsló segítségével történik, amely lépésről lépésre végigvezet minket az összes beállítási lépésen. Konfigurációként válassza ki Hálózati címfordítás (NAT), bármely más funkció később manuálisan konfigurálható.
Itt kell megadni, hogy a szerverünk milyen interfésszel csatlakozik az internethez, szükség esetén létrehozhatja (pl. PPPoE ill. VPN kapcsolatok).
A többi beállítást alapértelmezésben hagyjuk, és a gombra kattintás után elindul az Útválasztás és távelérés szolgáltatás, szerverünk készen áll az ügyfelek kiszolgálására. belső hálózat. A teljesítményt úgy ellenőrizheti, hogy a kliensgépnek megad egy IP-címet a belső hálózat tartományából, és megadja átjáróként és DNS szerverek szerverünk címét.
A hálózati beállítások automatikus konfigurálásához az ügyfélgépeken, nos, ne futtasson egyik helyről a másikra manuálisan IP-címeket írva elő, hozzá kell adnia a szerepet DHCP szerver A.
Erre választunk Szerep hozzáadása V Szerverkezelőés jelöljük meg a számunkra szükséges opciót.
Most néhány egyszerű kérdésre kell válaszolnunk. Különösen annak kiválasztásához, hogy mely belső hálózatokhoz használja a DHCP-t, szükség esetén különféle beállításokat konfigurálhat különböző hálózatok. Ezután egymás után adja meg a DNS- és WINS-kiszolgálók paramétereit. Ez utóbbi hiányában elhagyható. Ha a hálózatán nem találhatók olyan régi munkaállomások, amelyek Windows NT 5 vagy újabb operációs rendszert futtatnak (2000 / XP / Vista / Seven), akkor nincs szükség WINS-kiszolgálóra.
A DHCP hatókör hozzáadásával nagyon óvatosan kell bánni, itt egy hiba a teljes hálózat működésképtelenségéhez vezethet. Itt nincs semmi bonyolult, csak óvatosan adja meg az összes szükséges hálózati paramétert, ügyelve arra, hogy a kiosztott IP-tartomány ne legyen átfedésben a többi eszköz számára már kiosztott IP-tartományban, és ne felejtse el helyesen megadni a maszkot és az átjárót.
Külön kell figyelni egy olyan paraméterre, mint a cím bérleti ideje. A bérlet felének lejárta után az ügyfél kérést küld a szervernek a bérlet megújítására. Ha a szerver nem elérhető, a kérés a hátralévő idő fele után megismétlődik. Vezetékes hálózatokban, ahol a számítógépek nem mozognak a hálózaton belül, megfelelő hosszú bérleti időszakot állíthat be, ha van ilyen. egy nagy szám mobil felhasználók (például nyilvános wifi csatlakozási pont kávézóban) a bérleti időszak néhány órára korlátozható, ellenkező esetben a bérelt címek nem kerülnek ki időben, és előfordulhat, hogy a medence nem tartalmaz szabad címeket.
A következő lépés az IPv6 támogatásának megtagadása, és a DHCP szerepkör telepítése után a szerver készen áll a további beállítások nélkül történő működésre. Ellenőrizheti a kliens gépek működését.
A kiadott IP-címek megtekinthetők Bérelt címek a számunkra érdekes területhez kapcsolódik. Itt is konfigurálható a foglalás egy adott cím konkrét kliensére (név vagy MAC-cím kötése), szükség esetén a terület paraméterei is hozzáadhatók, módosíthatók. Szűrők lehetővé teszi engedélyezési vagy megtagadási szabályok létrehozását az ügyfelek MAC-címei alapján. A Windows Server 2008 R2 DHCP-kiszolgáló összes funkciójának teljesebb áttekintése túlmutat e cikk keretein, és valószínűleg külön anyagot fogunk szentelni nekik.
Korábbi cikkünkben a NAT beállításával foglalkoztunk a Windows Server platformon. Ahogy az olvasó válasza is megmutatta, bizonyos nehézségek adódhatnak betárcsázós internetkapcsolatok használatakor: VPN vagy PPPoE. Ma megnézzük a...
NAT(Network Address Translation) az IETF (Internet Engineering Task Force) szabvány. munkacsoport internetes technológiák fejlesztése), melynek segítségével több számítógép privát hálózat(például 10.0.x.x, 192.168.x.x, 172.x.x.x privát címekkel) egyetlen IPv4-címet oszthatnak meg, amely hozzáférést biztosít a globális hálózat. A NAT növekvő népszerűségének fő oka az IPv4-címek növekvő hiánya. Ezenkívül sok internetes átjáró aktívan használja a NAT-ot, különösen a csatlakozáshoz szélessávú hálózatok például DSL- vagy kábelmodemen keresztül.
Ahhoz, hogy útválasztóként működjön, a szervernek 2 hálózati interfésszel kell rendelkeznie. Az Internet és maga a hálózat, amelyet be kell indítani az Internetbe. Nekem van hálózati kapcsolatok LAN_1 (Internet) és LAN_2 (helyi hálózat) néven ismert.
Hadd mondjam el, hogy a szolgáltatás Windows tűzfal/internetkapcsolat megosztása (ICS) le kell tiltani.
Tehát kezdjük a telepítéssel:
Tehát telepítettük a hálózati interfészeket, most konfiguráljuk őket.
Először is állítsuk be Külső interfész (LAN_1):
192.168.0.2 - Annak a felhasználónak az IP-címe, aki a szerverünkön keresztül hozzáfér a hálózathoz
10.7.40.154 - a szerver külső IP-címe
Ha ezzel a technológiával csatlakozik az internethez, akkor az IP-címe 10.7.40.154. A beállításnak többféle módja van, minden géphez külön foglalhat címet. A foglalásban megadhat egynél több címtartományt, vagy egyáltalán nem adható meg, majd bármilyen IP-címet megadhat helyi hálózat képes lesz szörfözni az interneten a szerveren keresztül.
Megyünk Tulajdonságok helyi hálózati kártya, Tovább TCP/IP tulajdonságok. Előírjuk a kliens IP-jét, maszkját, be Alapértelmezett átjáróírja be a szerver IP-címét. A DNS mezőkben meg kell adnia a DNS-szolgáltató IP-címét vagy a telepített helyi DNS-kiszolgáló IP-címét.
Minden! Ezzel befejeződik a telepítés és a konfiguráció.
A Network Address Translation (NAT) egy módja annak, hogy az egyik címteret egy másik címterre leképezzük az információk megváltoztatásával, vagyis a csomagfejlécek megváltoznak, miközben a forgalomirányító eszközön áthaladnak. Ezt a módszert eredetileg a forgalom egyszerű átirányítására használták az IP-hálózatokon az egyes gazdagépek átszámozása nélkül. Az IPv4-címek szűkössége miatt népszerű és fontos eszközzé vált a globális címtér megőrzésében és kiosztásában.
A hálózati címfordítás eredeti célja az, hogy az egyik címtérben lévő címeket leképezzék egy másik térben lévő megfelelő címre. Erre például akkor van szükség, ha az internetszolgáltató megváltozott, és a felhasználónak nincs lehetősége nyilvánosan bejelenteni egy új útvonalat a hálózatnak. Az IP-címtér előreláthatóan globális kimerülésével a NAT technológiát az 1990-es évek vége óta egyre gyakrabban alkalmazzák az IP-titkosítással kombinálva (ami több IP-cím egyetlen térbe helyezésének módszere). Ezt a mechanizmust egy olyan útválasztó eszközben valósítják meg, amely állapotjelző fordítási táblákat használ a "rejtett" címek egyetlen IP-címre való leképezésére, és a kimenő IP-csomagokat továbbítja. Így az útválasztó eszközből kilépőként jelennek meg. Fordítva a válaszok a forrás IP-címére vannak leképezve a fordítási táblákban tárolt szabályok segítségével. A fordítási táblázat szabályai viszont rövid idő után törlődnek, ha az új forgalom nem frissíti állapotát. Ez a NAT alapvető mechanizmusa. Mit is jelent ez?
Ez a módszer csak akkor engedélyezi a kommunikációt az útválasztón keresztül, ha a kapcsolat titkosított hálózaton van, mivel ez fordítási táblázatokat hoz létre. Például egy ilyen hálózaton belüli webböngésző meg tud tekinteni egy azon kívül eső webhelyet, de ha azon kívül van telepítve, nem tudja megnyitni a benne tárolt erőforrást. A legtöbb NAT-eszköz azonban manapság lehetővé teszi a fordítási tábla bejegyzéseinek konfigurálását állandó használatra. Ezt a szolgáltatást gyakran nevezik statikus NAT-nak vagy porttovábbításnak, és lehetővé teszi, hogy a "külső" hálózatról származó forgalom elérje a titkosított hálózat kijelölt gazdagépeit.
Az IPv4-címterület megőrzésére használt módszer népszerűsége miatt a NAT kifejezés (ami valójában – fentebb említettük) szinte a titkosítási módszer szinonimájává vált.
Mivel a Network Address Translation megváltoztatja az IP-csomagok címinformációit, ennek komoly következményei vannak az internetkapcsolat minőségére nézve, és fokozott figyelmet igényel a megvalósítás részletei.
A NAT implementációk sajátos viselkedésükben különböznek egymástól a hálózati forgalomra gyakorolt hatást tekintve.
A Network Address Translation (NAT) legegyszerűbb típusa az IP-címek egy az egyhez fordítását biztosítja. Az RFC 2663 ennek a fordításnak a fő típusa. Ebben a típusban csak az IP-címek és az IP-fejlécek ellenőrző összege módosul. Az alapvető fordítási típusok két olyan IP-hálózat összekapcsolására használhatók, amelyek címzése nem kompatibilis.
A NAT legtöbb változata 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 rendelt „privát” IP-címek egyikét használja (RFC 1918). Ezen a hálózaton egy útválasztó magáncímmel rendelkezik ezen a területen.
Az útválasztó az internetszolgáltató által hozzárendelt „nyilvános” cím használatával is csatlakozik az internethez. Mivel a forgalom minden egyes csomagban a forrás helyi hálózatáról halad át, azt menet közben lefordítják privát címről nyilvános címre. Az útválasztó nyomon követi az alapvető információkat minden aktív kapcsolatról (különösen a cél címét és portját). Amikor a választ visszaküldi neki, a kimenő szakasz során tárolt kapcsolati adatok alapján határozza meg a belső hálózat privát címét, amelyre a választ továbbítani kell.
Ennek a funkciónak az egyik előnye, hogy praktikus megoldást jelent a közelgő IPv4-címterület-kimerülésre. Még nagy hálózatok is csatlakozhatnak az internethez egyetlen IP-címmel.
Az IP-hálózatokon lévő összes adatcsomagnak 2 IP-címe van - forrás és cél. Jellemzően a magánhálózatból a nyilvános hálózatba utazó csomagok forráscíme megváltozik a nyilvános hálózatról a magánhálózatra való visszatérés során. Bonyolultabb konfigurációk is lehetségesek.
A NAT beállításának lehetnek bizonyos sajátosságai. További módosításokra van szükség a visszaküldött csomagok fordításával kapcsolatos nehézségek elkerülése érdekében. Az internetes forgalom túlnyomó többsége a TCP és az UDP protokollokon keresztül megy keresztül, és ezek portszámai úgy változnak, hogy az IP-cím és a portszám kombinációja az adatok visszaküldésekor kezd megegyezni.
A nem TCP-n és UDP-n alapuló protokollokhoz más fordítási módszerekre van szükség. A Message Control Protocol (ICMP) általában korrelálja a továbbított adatokat egy meglévő kapcsolattal. Ez azt jelenti, hogy azokat az eredetileg beállított IP-címmel és számmal kell megjeleníteni.
A NAT beállítása az útválasztón nem biztosít végpontok közötti kapcsolatot. Ezért 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 külső hálózatról vagy nem protokollfelhasználókról, nem érhetők el. Ha a NAT útválasztó nem tesz sok erőfeszítést az ilyen protokollok támogatására, a bejövő csomagok nem érhetik el a célt. Egyes protokollok ugyanabban a fordításban hosztolhatók a résztvevő gazdagépek között (például "passzív módú" FTP), néha egy alkalmazási réteg átjáró segítségével, de a kapcsolat nem jön létre, ha mindkét rendszert NAT választja el az internettől. . A NAT használata bonyolítja az olyan "tunneling" protokollokat is, mint például az IPsec, mivel megváltoztatja a fejlécek értékeit, amelyek kölcsönhatásba lépnek a kérés integritásának ellenőrzésével.
A végpontok közötti kapcsolat az internet alapelve a kezdetek óta. A hálózat jelenlegi állapota azt mutatja, hogy a NAT sérti ezt az elvet. Komoly aggodalomra ad okot a szakértők körében a hálózati címfordítás mindenütt elterjedt használata az IPv6-ban, és felmerül a kérdés, hogyan lehetne ezt hatékonyan kiküszöbölni.
A NAT-útválasztókban a fordítási állapottáblázatok rövid élettartama miatt a belső hálózati eszközök elveszítik IP-kapcsolatukat, jellemzően nagyon rövid időn belül. Ha arról beszélünk, hogy mi a NAT egy útválasztóban, nem szabad megfeledkeznünk erről a körülményről. Ez jelentősen csökkenti az elemekkel és akkumulátorokkal működő kompakt eszközök működési idejét.
Ráadásul a NAT használatakor csak azokat a portokat figyelik, amelyek gyorsan kimeríthetők. belső alkalmazások, amelyek több egyidejű kapcsolatot használnak (például HTTP-kérelmek nagyszámú beágyazott objektumot tartalmazó weboldalakhoz). Ez a probléma enyhíthető a cél IP-címének követésével a porton kívül (így egy helyi porton sok távoli gazdagép osztozik).
Mivel az összes belső cím egyetlen nyilvános címnek van maszkírozva, lehetetlenné válik a külső gazdagépek számára, hogy kapcsolatot kezdeményezzenek egy adott belső gazdagéppel anélkül, hogy a tűzfalon (amelynek egy adott portra kell továbbítania a kapcsolatokat) speciális konfigurációt ne hozzon létre. Olyan alkalmazások, mint az IP telefonálás, videokonferencia és hasonló szolgáltatások A megfelelő működéshez NAT bejárási módszereket kell használnia.
A fordított cím- és portfordítás (Rapt) lehetővé teszi, hogy egy gazdagép, amelynek valós IP-címe időről időre megváltozik, fix IP-címet használó szerverként elérhető maradjon. otthoni hálózat. Alapvetően ennek lehetővé kell tennie a kiszolgálók beállításai számára, hogy megtartsák a kapcsolatot. Bár ez nem tökéletes megoldás a problémára, lehet egy másik hasznos eszköz a hálózati adminisztrátor fegyvertárában, amikor megoldja a NAT konfigurálását az útválasztón.
A Cisco Rapt megvalósítása a Port Address Translation (PAT), amely több privát IP-címet képez le egyetlen nyilvános IP-címként. Több cím is megjeleníthető címként, mert mindegyiket egy portszám követi. A PAT egyedi forrásportszámokat használ a belső globális IP-címen 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őre fordítható belső címek száma elméletileg elérheti a 65536-ot. A tényleges portok száma, amelyekhez egyetlen IP-cím hozzárendelhető, körülbelül 4000. A PAT általában megpróbálja megtartani az eredeti portot. eredeti". 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 - 0-511, 512-1023 vagy 1024-65535. Ha nincs több elérhető port, és egynél több külső IP-cím van, a PAT a következőre lép, hogy megpróbálja kijelölni a forrásportot. Ez a folyamat addig folytatódik, amíg a rendelkezésre álló adatok el nem fogynak.
A cím- és portleképezést egy Cisco szolgáltatás végzi, amely egyesíti a fordítási port címét a belső IPv6-hálózaton keresztüli IPv4-csomagok alagútinformációival. Ez lényegében a CarrierGrade NAT és DS-Lite nem hivatalos alternatívája, amely támogatja az IP-címek/portok fordítását (és így a NAT beállítása is támogatott). Így elkerülhető a kapcsolat létrehozásával és karbantartásával kapcsolatos problémák, valamint átmeneti mechanizmust biztosít az IPv6 telepítéséhez.
Számos módja van a hálózati cím- és portfordítás megvalósításának. Egyes, titkosított hálózaton futó IP-cím-alkalmazásokat használó alkalmazásprotokollokban meg kell határozni a külső NAT-címet (amit a kapcsolat másik végén használunk), és emellett gyakran szükséges tanulmányozni és osztályozni a átvitel típusa. Erre általában azért kerül sor, mert kívánatos egy közvetlen kommunikációs csatorna létrehozása (akár a szerveren keresztüli adatátvitel zavartalan tartása, akár a teljesítmény javítása érdekében) két kliens között, amelyek mindegyike külön NAT mögött található.
Erre a célra (a NAT beállítása) 2003-ban egy speciális RFC 3489 protokollt fejlesztettek ki, amely az UDP egyszerű megkerülését biztosítja a NATS felett. Ma már elavult, mivel az ilyen módszerek ma már nem elegendőek számos eszköz teljesítményének helyes értékeléséhez. Az új módszereket az RFC 5389 szabványban szabványosították, amelyet 2008 októberében fejlesztettek ki. Ez a specifikáció ma SessionTraversal néven ismert, és egy segédprogram a NAT futtatásához.
Minden TCP és UDP csomag tartalmazza a forrás IP-címét és portszámát, valamint a célport koordinátáit.
A nyilvános szolgáltatások, például a levelezőszerver-funkciók esetében a portszám fontos. Például csatlakozik a szoftver webszerver, 25 pedig SMTP levelezőszerver. A nyilvános szerver IP-címe is jelentős, például postai cím vagy telefonszám. Mindkét paramétert megbízhatóan ismernie kell minden kapcsolatot létesíteni szándékozó csomópontnak.
A privát IP-címek csak azokon a helyi hálózatokon számítanak, ahol használják őket, és a gazdagép portokon is. A portok egyedi kommunikációs végpontok a gazdagépen, így a NAT-kapcsolatot kombinált port és IP-cím-leképezés támogatja.
A PAT (Port Address Translation) feloldja azokat az ütközéseket, amelyek két különböző gazdagép között fordulhatnak elő, ugyanazt a forrásportot használva, hogy egyidejűleg egyedi kapcsolatokat hozzon létre.
/05.07.2004 20:43/Az utóbbi években az orosz hálózati rendszergazdák körében divatba jött a FireWall ill NAT. Az Eserv-felhasználók már a 90-es évek közepe óta ismerik a hozzáállásomat ezekhez a technológiákhoz, de néha a FireWall / NAT-ról ilyen kérdéseket tesznek fel a kezdők, é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 a NAT van soron.
Dokumentum tartalomjegyzék
Ennek a problémának a legegyszerűbb megoldása - a visszatérési cím helyettesítése a hálózatok szélén - a felszínen feküdt, és nem is késett a közzététel: 1994 májusában, i.e. két hónappal a "hálózatok szakasza" után javasolták 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ár átlátszó számukra, egyszerűen programozottan "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 fordított IP-címet a "határ" számítógép valódi címére cserélték. , és fordítva lecseréli a bejövő csomagokban. Emellett általában a LAN forrás portszámát is lecserélték. A csomagok a LAN különböző gépeiről származhatnak azonos portszámmal. Azok. nem csak az IP-címeket fordítják le, hanem a portszámokat is (néha a portfordítókat külön PAT rövidítésnek nevezik). A feltételes besorolásban a NAT "statikus, dinamikus és maszkolásra (masquerading)" van felosztva, de a gyakorlatban elsősorban a harmadik típust használják, amely lehetővé teszi több ezer kapcsolat kiszolgálását a LAN-ból egy valós címen keresztül (ideális esetben), míg portfordítás mindig használatos. Egy NAT számítógépen vagy útválasztón + NAT a fordításhoz használt portok tartománya van lefoglalva, például 60 000-nél nagyobb számokkal (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 táblázat az aktuális munkamenetekről / címleképezések. Minden egyes átmenő csomagot a táblázat és a port ellenőrzik, és megtörténik a megfelelő helyettesítések. A technológia annyira egyszerű, hogy ma már egyre ritkábban találni routert vagy kábelmodemet beépített NAT (és FireWall, olyan primitív, mint a NAT) nélkül, és a NAT már a 40 dollártól kezdődő hubokban is megtalálható. megemlíteni az "ingyenes "NAT-ot, amely több része legújabb verziói Windows nevű " kapcsolat megosztása"És" kapcsolat megosztása A NAT méltán népszerűvé tette a rendelkezésre állást, a könnyű megértést/használatot és a kliensszoftverek iránti igénytelenségét.
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 ehhez á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 egy további portot, és mondja el 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 (ez a szabványos ftp.exe-ben nincs), ez az FTP-szerver rendszergazdájának is némi erőfeszítést igényel - különösen, ha a tűzfalak és a NAT-ok részben blokkolják is. (ahogy az Eserv FTP fejlesztői szerverei első kézből ismerik ezeket a problémákat). Általában itt a NAT nem segíti a csatlakozást, hanem zavarja.
Most a NAT-on belüli protokoll rekonstrukciójáról, hogy a kliens számára "átlátszó" legyen a probléma megkerülése. Az a néhány NAT, amely képes erre (bár a gyakorlatban ők is deklarálják, mint tehetnék, valójában egy hálózati réteggel feljebb lépnek - a legegyszerűbb csomagtovábbítás helyett címfordítással a fejlécben ugyanazt kezdik csinálni, mint a TCP verem nem - összeállítja a TCP-csomagokat, így azokat egy túlfejlett útválasztóból alulfejlett TCP-alkalmazásproxyvá alakítja át. ez az eset egy FTP proxyhoz vagy egy FTP-kapuhoz. Fejletlen, mert a kliens nem tud erről a proxyról, a NAT viszont továbbra is kitalálja a protokollt, és olyan feladattal foglalkozik, amelyet annak szintjén (IP-csomagok szintjén) kényelmetlen megoldani.
Ez a feladat sokkal könnyebben megoldható, ha a NAT helyett vagy mellette azonnal speciális proxyt (FTP-kapu) vagy univerzális TCP-proxyt, például Socks-t vagy szélsőséges esetben httpS-t használ (ez az extrém eset továbbra is működik jobb, mint a 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 kettős TCP-összeállítást. Ráadásul az adminnak 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 nem maradt, de a legrosszabb esetekről beszélünk), akkor Socks proxy használatakor a kliens munkája is átláthatóvá tehető SocksCapture vagy belföldi segítségével. FreeCap programok. A szegély átlátszósága mindig trükk, de a SocksCapture vagy a FreeCap nem IP-csomagokat, hanem programhívásokat fog el az operációs rendszer felé, így mindig pontosan 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 irányítsa át ezeket a műveleteket a Socks -proxyn keresztül.
A Socks leküzdötte a NAT összes korlátját, és legalább három kényelmes eszközt adott hozzá, amelyek nemcsak szinte bármilyen TCP- és UDP-protokoll „proxyzását” teszik lehetővé, hanem az internet LAN-ról történő használatának javítását is:
Ugyanez vonatkozik minden más alkalmazásprotokollra, amelyhez speciális proxyk vannak – ezek mindig egy nagyságrenddel jobban kezelhetőek, mint az általános 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). Az ehhez szükséges zokni és NAT speciális ismereteket igényelne a továbbított protokoll megértésében, pl. valójában egy POP3 proxy "emulálása" ehhez nem túl kényelmes eszközökkel.
Ezért szóba jöhet a Socks vagy a NAT használata azokkal a 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) vannak. erőltetett nem optimális megoldás. Kényszer - vagy abból ered, hogy szervezeti okokból nem lehet használni a kívánt típusú proxyt (nincs hová tenni a kívánt típusú proxyt, vagy a kapcsolat típusa nem biztosítja valódi IP-cím jelenlétét, mint ahogy az a Internet GPRS-en vagy otthoni hálózaton keresztül - ezekben az esetekben a NAT vagy a "kényszerített HTTP proxy" már a szolgáltató oldalán áll), vagy a felelős személyek, pl. adminok. Nem veszem figyelembe az anyagi megszorításokat, 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 nem fejlesztenek speciális proxykat, mert szinte láthatatlanok a hálózathasználat általános hátterében. Ha nincs levelezőszerver vagy pop3 / smtp proxy a LAN-ban, akkor a Socks5 is a következő jelölt lesz, bár nem minden levelezőkliens támogatja, és vannak olyan funkciók, amelyek nem nyilvánvalóak (lásd Mozilla ThunderBird).
A lehetőségek válogatásakor a NAT lesz az "utolsó megoldás" - ha nem találtak jobbat, vagy ha a NAT-ot a szolgáltató állította be kezdetben - kábelmodemben, routerben, mobil kapcsolat(Ezekbe a vasdarabokba a NAT van telepítve, nem pedig a népszerű protokollok speciális proxyjai, alapvető megvalósításának rendkívüli egyszerűsége miatt: az Eproxyban található hasonló NAT UDPMAP plugin forráskódja 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 legalább valahogy dolgozni, mint egyáltalán nem dolgozni.
Itt van egy részletes magyarázat az elmúlt 8 év jól ismert álláspontjáról - "Eserv soha nem lesz NAT" 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 az A szolgáltató választásáért. , használhatja a beépített Windows kapcsolatmegosztást, 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ása alkalmazás adaptáción keresztül, 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épeihez (ellentétben az enyémmel és egy másik független NAT-problémák leírásával.
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. ("Nem lehet engedélyezni a megosztott hozzáférést. 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, el kell indítania az ICS engedélyezése előtt.
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 olyan programokban, mint az MSN Messenger. Lehet, hogy egyes NAT-megvalósításokban az aktív ftp-vel, a külső VPN-kiszolgálókhoz való csatlakozással stb. is vannak problémák, de ha Linuxon keresztül dolgozik a NAT-on (megfelelő beállításokkal), ezzel nincs probléma. A NAT előnye ebben az esetben az IP-címek és a tűzfal mentése.
Ha összehasonlítjuk a NAT-ot egy proxyval (az internet elérésének módjaként, azaz a kérések átirányítása a gyorsítótárazás, az URL-elemzés stb. funkcióinak figyelembe vétele nélkül), akkor több alkalmazás és protokoll működik a NAT-on keresztül (minden); A NAT nem igényel speciális beállításokat a felhasználó részéről; a proxy igényesebb a hardverre. A proxy-k általában nem biztosítanak cél-NAT (DNAT) funkcionalitást, bár az Eserve-ben a tcp / udp leképezés használatával elérheti a DNAT részleges hasonlóságát. Az idézet vége.
Ez az idézet azt mutatja, hogy a szolgáltatóknak nagyon eltérő követelményei vannak a vállalatok rendszergazdáitól.
| visszamutató linkek |
|---|
| cikkeket |
| tűzfal |
| MxServer |
| NCSI |
| WhatIsProxyServer |
A SNAT mellett pl. gyakran használják a helyi hálózat felhasználóinak belső címek biztosítását az internet eléréséhez Cél NAT, amikor a kívülről érkező kéréseket a tűzfal sugározza a helyi hálózat olyan szerverére, amely belső címmel rendelkezik, és ezért nem érhető el közvetlenül a külső hálózatról (NAT nélkül).
Az alábbi ábrák egy példát mutatnak be a NAT mechanizmus működésére.
Rizs. 7.1.
Felhasználó vállalati hálózat kérést küld az Internetre, amely a címre érkezik belső interfész router, hozzáférési kiszolgáló vagy tűzfal (NAT-eszköz).
A NAT-eszköz fogadja a csomagot, és bejegyzést készít a kapcsolatkövetési táblázatban, amely kezeli a címfordítást.
Ezután lecseréli a csomag forráscímét saját külső nyilvános IP-címére, és elküldi a csomagot a célállomásra az interneten.
A célállomás fogadja a csomagot, és visszaküldi a választ a NAT-eszköznek.
A NAT eszköz pedig, miután megkapta ezt a csomagot, megkeresi az eredeti csomag küldőjét a kapcsolatkövetési táblában, lecseréli IP-cím célállomást a megfelelő privát IP-címre, és továbbítja a csomagot a forrásszámítógépnek. Mivel a NAT-eszköz az összes belső számítógép nevében küld csomagokat, megváltoztatja az eredetit hálózati portÉs ez az információ a kapcsolatkövetési táblában tárolva.
A címfordításnak 3 alapfogalma van:
Statikus NAT egy az egyben leképezi a helyi IP-címeket meghatározott nyilvános címekre. Akkor használatos, ha a helyi gazdagépnek kívülről elérhetőnek kell lennie rögzített címekkel.
Dinamikus NAT privát címek halmazát képezi le nyilvános IP-címek halmazára. Ha a helyi gazdagépek száma nem haladja meg a rendelkezésre álló nyilvános címek számát, minden helyi cím garantáltan megegyezik egy nyilvános címmel. Ellenkező esetben a nyilvános címek száma korlátozza azon gazdagépek számát, amelyek egyidejűleg hozzáférhetnek a külső hálózatokhoz.
Álarcos NAT(NAPT, NAT Overload, PAT, masquerading) a dinamikus NAT egyik formája, amely több privát címet képez le egyetlen nyilvános IP-címhez különböző portok használatával. Más néven PAT (Port Address Translation).
A belső helyi hálózat és a külső nyilvános hálózat közötti interakciónak számos mechanizmusa lehet – ez attól függ konkrét feladat hozzáférést biztosít a külső hálózathoz és fordítva, és bizonyos szabályok előírják. A hálózati címfordítás 4 típusa van meghatározva:
A NAT első három típusában ugyanazt a külső portot használják a külső hálózat különböző IP-címeivel való kommunikációhoz a helyi hálózatról származó címekkel. A negyedik típus - szimmetrikus - minden címhez és porthoz külön külső portot használ.
Full Horse, az eszköz külső portja (router, hozzáférési szerver, tűzfal) nyitva áll bármely címről érkező kérések számára. Ha az internetről érkező felhasználónak csomagot kell küldenie a NAT mögött található kliensnek, akkor csak annak az eszköznek a külső portját kell ismernie, amelyen keresztül a kapcsolat létrejön. Például egy 192.168.0.4 IP-című NAT mögötti számítógép a 8000-es porton küld és fogad csomagokat, amelyek a külső IP-címhez és a 10.1.1.1:12345 porthoz vannak leképezve. A külső hálózatról érkező csomagok a 10.1.1.1:12345 IP-cím:porttal érkeznek az eszközre, majd elküldik a 192.168.0.4:8000 ügyfélszámítógépre.
A bejövő csomagokban csak a szállítási protokoll kerül ellenőrzésre; célcím és port, forráscím és port nem számít.
NAT használatakor úgy működik, mint Korlátozott kúp, az eszköz külső portja (router, hozzáférési szerver, tűzfal) nyitva van minden, a kliens számítógépről küldött csomag számára, példánkban: 192.168.0.4:8000. És a külső hálózatról (például a 172.16.0.5:4000 számítógépről) a 10.1.1.1:12345 cím:porttal rendelkező eszközre érkező csomag csak akkor kerül elküldésre a 192.168.0.4:8000 számítógépre, ha a 192.168.0.4:8000 korábban kérést küldött a külső gazdagép IP-címére (esetünkben a 172.16.0.5:4000 számítógépre). Vagyis a router csak egy adott forráscímről küldi tovább a bejövő csomagokat (esetünkben a számítógép 172.16.0.5:4000), de a forrás port száma bármi lehet. Ellenkező esetben a NAT blokkolja az olyan gazdagéptől érkező csomagokat, amelyekre a 192.168.0.4:8000 nem küldött kérést.
NAT mechanizmus Port Restricted Cone csaknem hasonló a NAT Restricted Cone mechanizmusához. Csak ebben az esetben a NAT blokkol minden olyan gazdagépről érkező csomagot, amelyre a 192.168.0.4:8000 ügyfélszámítógép nem küldött kérést egyetlen IP-címre és portra sem. Az útválasztó figyel a forrás port számának egyezésére, és nem figyel a forráscímre. Példánkban a router bármilyen forráscímmel továbbítja a bejövő csomagokat, de a forrás portnak 4000-nek kell lennie. Ha a kliens több IP-címre és portra küldött kéréseket a külső hálózatba, akkor képes lesz csomagokat küldeni a kliensnek. az IP-címen: 10.1 .1.1:12345 port.
Szimmetrikus NAT jelentősen eltér az első három mechanizmustól abban, ahogyan egy belső IP-cím:portot leképez egy külső cím:portra. Ez a leképezés annak a számítógépnek az IP-címe:portjától függ, amelyre a küldött kérést szánják. Például, ha egy ügyfélszámítógép a 192.168.0.4:8000 számon kérést küld az 1. számítógépre (172.16.0.5:4000), akkor ez 10.1.1.1:12345-ként jelenhet meg, ugyanakkor, ha ugyanarról küldi. port (192.168. 0.4:8000) egy másik IP-címre, másként jelenik meg (10.1.1.1:12346).
Meg kell azonban említeni ennek a technológiának a hátrányait is:
