/05.07.2004 20:43/

Posledné roky medzi Rusmi správcov siete móda pre FireWall a NAT... Používatelia Eserv poznajú môj postoj k týmto technológiám už od polovice 90-tych rokov, no niekedy takéto otázky o FireWall / NAT kladú nováčikovia a musím sa opakovať. Preto som asi pred rokom napísal samostatný článok o FireWall a dnes je na rade NAT.

Epigraf

Pridané 28.12.2005. Google poskytol dobré zhrnutie problému NAT: „Zariadenia NAT, ktoré sú čoraz populárnejšie v domácnostiach a kanceláriách, umožňujú viacerým počítačom zdieľať jednu internetovú adresu. V dôsledku toho je pre aplikácie, ako je hlasový chat, ktoré vyžadujú, aby partneri sa navzájom priamo oslovujú, aby sa spoľahlivo vytvorilo spojenie typu peer-to-peer." (Zariadenia NAT, ktorých popularita v domácnostiach a kanceláriách rastie, umožňujú zdieľanie viacerých zariadení jeden internetová adresa. Výsledkom sú aplikácie ako napr hlasový chat vyžadujúce priame oslovenie strán, je stále ťažšie a ťažšie vytvárať spoľahlivé spojenia point-to-point.)

Obsah dokumentu

História NAT

Najprv pár slov o histórii vzniku potreby proxy / gating / tunelovania na internete, potom budú možnosti jasnejšie rôzne prístupy a ich „hierarchiu“. Ako viete, nedostatok IP adries v 4-bajtovom adresnom priestore bol predpovedaný už na začiatku 90. rokov (plus nedostatok peňazí na prenájom blokov adries v niektorých spoločnostiach. Preto sme sa už v marci 1994 dohodli na segmentácii adries " spoločný priestor- pridelenie samostatných rozsahov IP adries pre lokálne siete a vylúčenie týchto IP adries z používania na internete (http://www.ietf.org/rfc/rfc1597.txt, marec 1994 Prideľovanie adries pre súkromné ​​​​internety; citát na účel tohto dokumentu "Autori dúfajú, že použitie týchto metód povedie k významným úsporám pri prideľovaní adries"). Toto riešenie umožnilo spoločnostiam alokovať malé bloky IP adresy pre svoje internetové servery av rámci LAN si IP adresy pre vlastnú potrebu prideľovali samotné firmy z rozsahov pre lokálne siete. Výsledkom bolo, že internetové servery spoločnosti (poštové a www / ftp) boli ľahko dostupné z internetu aj zo siete LAN a počítače v rámci siete LAN mohli bez problémov komunikovať pomocou rovnakých protokolov IP. Toto rozhodnutie však postavilo bariéru medzi lokálnymi sieťami a internetom. rovnakú IP adresu je možné použiť v rôznych sieťach LAN a odvtedy z tohto dôvodu internet prestal smerovať pakety na adresovanie blokov pridelených pre siete LAN. Tie. v skutočnosti "fyzická bariéra" (bez prestrihnutia drôtov, čo si užívali v ruských bankách po prvých vlámaniach, a bez inštalácie FireWallu, čo sa im teraz páči). Siete sa stali izolovanými tak, ako sú v modernej dobe izolované úlohy operačné systémy- každý má svoj vlastný adresný priestor. Táto bariéra nebola pre poštu problémom, od r podnikové poštové servery boli inštalované na okraji sietí a boli viditeľné z internetu aj LAN. Ale s prístupom z LAN k externým zdrojom - na ftp a stále rastúcou popularitou v tých rokoch, http-servery začali mať problémy. Ak predtým bolo možné priamo interagovať so serverom z akéhokoľvek počítača, teraz táto príležitosť zostala iba pri počítačoch so skutočnými internetovými adresami, pretože ktorá LAN má poslať odpoveď na IP paket s lokálnou adresou v spiatočnej adrese - router to nedokáže určiť.

Najjednoduchším riešením tohto problému je nahradiť spiatočná adresa na hranici sietí - ležal na povrchu a nebol pomalý na zverejnenie: v máji 1994, t.j. dva mesiace po tom, čo „sekcia sietí“ navrhla špecifikáciu NAT: http://www.ietf.org/rfc/rfc1631.txt The Network Address Translator (NAT) máj 1994 Autori to ohlásili ako „krátkodobé riešenie“, t.j. dočasné riešenie tento problém, akýsi „hack“, kým sa bežné riešenia nerozšíria. Ale, ako viete, nič nie je také trvalé ako dočasný IPv6, na rozdiel od očakávaní, sa rýchlo neudomácnil a za posledných 10 rokov sme svedkami čoraz viac bitiek na hraniciach LAN a internetu. NAT sa rozšíril, pretože v tých rokoch neexistovalo iné prijateľné riešenie tohto problému: FTP klienti a HTTP klienti (prehliadače) sa nestihli prispôsobiť zmenenému obrazu sveta, nevedeli pracovať z LAN s externými zdrojmi, aby sa hranica pre nich transparentné, jednoducho bol softvér „oklamaný“ pomocou NAT – všetky IP pakety adresované z LAN smerom von boli na hranici podrobené najjednoduchšiemu spracovaniu: nahradenie spiatočnej IP adresy skutočnou adresou „hraničného“ počítača, a spätná náhrada v prichádzajúcich paketoch. Okrem toho sa zvyčajne nahradilo aj číslo portu zdrojovej siete LAN. s rôzne autá v sieti LAN môžu mať pakety rovnaké čísla portov. Tie. sa prekladajú nielen IP adresy, ale aj čísla portov (niekedy sa porty prekladača nazývajú samostatnou skratkou PAT). V konvenčnej klasifikácii sa NAT delí na „statický, dynamický a maskovací“, v praxi sa však používa najmä tretí typ, ktorý umožňuje obsluhovať tisíce pripojení z LAN cez jednu reálnu adresu (v ideálnom prípade sa vždy používa preklad portov). Na počítači s NAT alebo smerovačom + NAT je pridelený rozsah portov používaných na preklad, napríklad s číslami väčšími ako 60 000 (aby sa tieto porty rýchlo rozlíšili od portov pridelených pre vlastné potreby tohto počítača) a dynamická tabuľka aktuálnych relácie / mapovania adries. Každý prechádzajúci paket sa skontroluje podľa tejto tabuľky a port a vykonajú sa príslušné substitúcie. Technológia je taká jednoduchá, že v dnešnej dobe je čoraz menej bežné nájsť router alebo káblový modem bez vstavaného NAT (a FireWall, ktorý je rovnako primitívny ako NAT) a NAT už možno nájsť aj v hube „ach s ceny začínajú na 40 dolároch. Nehovoriac o tom, že " "zadarmo NAT je súčasťou niekoľkých najnovšie verzie Windows pod názvom " zdieľanie pripojenia" a " zdieľanie spojenia„Práve dostupnosť, jednoduchosť pochopenia/používania a nenáročnosť klientskeho softvéru urobili NAT zaslúžene populárnym.

NAT „očami“ internetových programov

Ak by v praxi bolo všetko také jednoduché, nebolo by to zaujímavé. Ale, samozrejme, ako pri každom inom softvérový trik V NAT sa okamžite začali objavovať rôzne nepríjemné vedľajšie účinky. V čase vzniku NAT bol jedným z najpopulárnejších protokolov FTP a práve tento protokol sa stal prvým nestráviteľným protokolom pre NAT. To odhalilo problém, ktorý NAT za týchto 10 rokov nijako úspešne nevyriešil. A v všeobecný prípad nedá sa to vyriešiť v rámci NAT, môžu existovať len úpravy pre konkrétne protokoly, ale tieto úpravy nemožno považovať za spoľahlivé riešenie. Tento problém spočíva v tom, že v niektorých protokoloch, z ktorých najstarší je FTP, sa prenáša IP adresa klientskeho počítača a túto IP adresu používa server na prenos údajov klientovi. Keďže v prípade NAT je klientsky program spustený z LAN "oklamaný" NAT, môže poslať svoju vlastnú lokálnu IP adresu iba serveru, ku ktorému sa môže pripojiť. externý server nebude môcť kvôli neviditeľnosti lokálnych sietí z internetu. Ďalšími príkladmi sú protokoly ICQ, MS NetMeeting, RealAudio a mnohé ďalšie protokoly, ktorých vývojári zrejme sedeli v sieťach bez
NAT NAT môže ponúknuť len jedno riešenie tohto problému – na základe čísel portov uhádnuť konkrétny protokol, ktorý sa prekladá, a začať monitorovať obsah paketov IP. Keď narazia na príkaz FTP PORT, ktorý špecifikuje: lokálny klientsky port ( textový príkaz v tele paketu, a nie v hlavičke paketu IP), potom nahraďte nielen hlavičky, ale celý paket prepočítaním kontrolný súčet a organizáciu odpočúvania iného prichádzajúceho portu. Nanešťastie pre NAT je protokol TCP, v ktorom sa prenášajú príkazy FTP, streamingový protokol organizovaný cez - príkaz PORT, keď vstúpi do vrstvy IP, môže byť rozdelený na 2 pakety (alebo aj viac, v závislosti od FTP klienta a vyrovnávacej pamäte v OS). Preto, aby ste spoľahlivo detegovali miesto podvrhnutia NAT, "budete musieť rekonštruovať pôvodný TCP stream, uložiť do vyrovnávacej pamäte a znovu zostaviť pakety. Vrátime sa k" rekonštrukcii protokolu "v NAT, ale zatiaľ si všimneme len multi- stupňovitá úroveň potenciálnych chýb a nespoľahlivosti v tomto procese.V praxi to vedie k tomu, že štandardný režim FTP pomocou príkazu PORT cez NAT vo všeobecnosti NEFUNGUJE.

Preto "problém NAT" v protokole FTP musí byť obídený špeciálnym spôsobom v FTP klientoch alebo v inom prostrednom špecializovanom FTP proxy. V FTP klientovi je potrebné prepnúť na tzv. "pasívny režim" - namiesto príkazu PORT použite príkaz PASV. PASV požiada FTP server o otvorenie dodatočný port doma a informovať o tom klienta: port. Klient sa potom pripojí k zadanému (NAT ho opäť oklame, odvysiela) a relácia je úspešná. Okrem potreby podpory režimu PASV v FTP klientovi (štandardný ftp.exe ho nemá) si to vyžaduje určité úsilie zo strany správcu FTP servera – najmä ak je čiastočne blokovaný aj firewallmi a NATmi ( ako vývojár FTP serverov pre Eserv tieto problémy nepoznám z počutia). Vo všeobecnosti tu NAT nepomáha pripojiť sa, ale ruší.

Teraz o rekonštrukcii protokolu vo vnútri NAT pre klientsky transparentné riešenie. Tých pár NAT, ktorí to dokážu (hoci v praxi tiež skôr deklarujú ako vedia ako, v skutočnosti sa sieťová vrstva up – namiesto najjednoduchšieho preposielania paketov s prekladom adries v hlavičke začnú robiť to isté, čo robí TCP stack – zostavovať TCP stream z paketov. Transformujú sa tak z príliš vyvinutého smerovača na nedostatočne vyvinutý proxy aplikačný TCP. V tomto prípade v FTP proxy alebo v FTP bráne. Nedostatočne vyvinutý, pretože klient o tomto proxy nevie a NAT zase pokračuje v hádaní protokolu a zapája sa do úlohy, ktorá je nepohodlná na riešenie na jeho úrovni (úroveň IP paketov).

Oveľa jednoduchšie sa tento problém vyrieši, ak namiesto NAT alebo navyše k nemu okamžite použijete špecializovaný proxy (FTP brána) alebo univerzálne TCP proxy ako Socks alebo v extrémnych prípadoch httpS (tento extrémny prípad však bude fungovať lepšie ako NAT). Tie spočiatku pracujú na úrovni TCP a FTP klienta neklamú, ale spolupracujú s ním. Tri vrstvy problémov zmiznú naraz: FTP klient môže použiť akýkoľvek režim - aktívny alebo pasívny (v httpS iba pasívny, ako v NAT), nie je potrebné hádať protokol a dvojitú zostavu TCP. Okrem toho má admin viac možností ovplyvniť proces (o tom neskôr).

Ak klientsky program nevie, ako pracovať cez špeciálny proxy (takéto proxy prakticky neexistujú, ale budeme hovoriť o najhoršie prípady), potom pri použití Socks proxy možno prácu klienta sprehľadniť aj pomocou programov SocksCapture alebo domáceho FreeCap. Transparentnosť hraníc je vždy klam, ale SocksCapture alebo FreeCap nezachytia IP pakety, ale volania programov do OS, takže vždy vedia s istotou a z toku paketov presne nevypočítajú, akú akciu chce program vykonať, a podľa toho presmerovať tieto akcie cez Socks -proxy.

NAT vs Socks

Keď už sme pri téme ponožiek, musím povedať pár slov o tomto proxy protokole. Navyše, historicky boli Socks po NAT ďalším nástrojom, ktorý prekročil hranicu medzi LAN a internetom: prvý prehľadový článok „čo sú ponožky“ bol publikovaný v októbri 1994, čoskoro sa objavila špecifikácia Socks4 (predchádzajúce „verzie“ neboli použité v žiadnej produkty) http : //www.socks.nec.com/protocol/socks4a.protocol a až 5. verzia v marci 1996 zrelá na publikovanie v ietf ako RFC: http://www.ietf.org/rfc/rfc1928. TXT. Existuje ruská verzia tohto dokumentu - preklad urobil Alexander Gorlach, ktorý v tom čase (97. a 98.) pracoval v našej spoločnosti a podieľal sa na tvorbe Eserv / 2, pozri stránku Socks5.

Socks prekonali všetky obmedzenia NAT a pridali aspoň tri pohodlné nástroje, ktoré umožňujú nielen „proxy“ takmer akýkoľvek protokol TCP a UDP, ale aj zlepšiť kontrolu nad používaním internetu z LAN:

1. Socks slúžia nielen na odchádzajúce pripojenia, ale tiež vám umožňujú vytvárať počúvajúce prichádzajúce zásuvky na proxy stroji (metóda BIND) na žiadosť proxy klienta - to je potrebné len pre FTP a podobné multi-prepojené protokoly.
2. Socks4a a Socks5 vám umožňujú odstrániť z klienta úlohu rozlíšenia doménových mien na klientovi a urobiť to priamo v serveri proxy. Tie. stroj vo vnútri LAN sa stane zbytočným DNS serverom alebo DNS mapovaním (cez NAT alebo špeciálny UDPMAP), administrátorovi sa odstráni jeden „tik“ jeho starostí a navyše vďaka DNS cache na serveri klient pracuje rýchlejšie.
3. Socks5 podporuje rôzne možnosti explicitná autentifikácia a autorizácia klienta. V NAT bolo možné rozlišovať medzi priateľmi a nepriateľmi iba podľa.

Ale hoci Socks zlepšili použiteľnosť v porovnaní s NAT, zostáva univerzálnym „programovateľným mapovaním“. Niektoré problémy NAT v ňom zostali nevyriešené. A nemožno ich vyriešiť na nízkej úrovni bez pochopenia podrobností konkrétneho protokolu proxy. Rovnako ako napríklad telefón je schopný prenášať ľudskú reč, no nie je schopný jej porozumieť a odfiltrovať nadávky. Preto tí správcovia, ktorí chcú úplná kontrola nad tým, čo sa deje v jeho sieti, použite špecializované proxy.

NAT a špecializované servery proxy očami systémového správcu

Najprv opäť malý exkurz do histórie. Protokol HTTP bol vyvinutý začiatkom 90-tych rokov (tzv. „verzia 0.9“) a v polovici 90-tych rokov sa stal „zabijakou aplikáciou“ internetu – dôvodom, prečo sa začali spájať nielen vedci a vojenský personál na internet, ale aj „obyčajných obchodníkov a obyčajných ľudí“. Potreba štandardizácie je teda zrelá. V máji 1996 bola vydaná špecifikácia HTTP / 1.0 pod významným víťazným číslom RFC: 1945. Autori špecifikácie už zohľadnili nové reálie internetu, vr. potreba proxy protokolu pre LAN. Okrem toho v praxi HTTP existuje už viac ako rok a má „skúsenosti s proxy“. Preto dokument obsahuje potrebné definície a poznámky o proxy, bránach a tuneloch. A vlastne tam bol definovaný nielen samotný HTTP protokol (z pohľadu bežného webservera), ale boli popísané aj HTTP-proxy a HTTPS-proxy protokoly. Metóda „CONNECT“, zavedená do protokolu HTTP špecificky s cieľom poskytnúť možnosť pripojenia k zabezpečeným serverom HTTP prostredníctvom proxy, však umožňovala neobmedzovať sa na port 443, ale špecifikovať akýkoľvek port pre pripojenie. Tvárou v tvár HTTPS proxy teda získame ďalšie „programovateľné mapovanie TCP“ pre akýkoľvek protokol, aj keď s oveľa viac postihnutí než ponožky 5. HTTP proxy pre svoj natívny protokol HTTP je úplne iná záležitosť. Zvládne to s plné znalosti prípady - vyrovnávacia pamäť, filtrovanie podľa adresy URL a obsahu, obmedzenie, smerovanie, autorizácia atď. Často si tieto akcie vyžadujú také netriviálne akcie na úrovni TCP a iných komponentov OS, ktoré sú prakticky nemožné na paketovej úrovni NAT alebo slepé mapovanie Socks.

To isté platí pre akýkoľvek iný aplikačný protokol, pre ktorý existujú špecializované proxy – sú vždy rádovo lepšie spravovateľné ako univerzálne nízkoúrovňové. Napríklad veľa serverov proxy POP3 vám umožňuje filtrovať spam, ako napríklad PopFile (hoci je oveľa správnejšie filtrovať spam nie na serveri proxy, ale na serveri SMTP). Socks a NAT by si vyžadovali špeciálne zručnosti na pochopenie prenášaného protokolu, t.j. v skutočnosti "emulácia" POP3 proxy nie je pre tento prostriedok príliš vhodná.

Preto použitie Socks alebo NAT na prácu s tými protokolmi, pre ktoré existujú špecializované proxy (HTTP, HTTPS, FTP, SMTP, POP3, IMAP) alebo všeobecne akceptovaná architektúra medziľahlých serverov (SMTP, POP3, IMAP, DNS) môže považovať za vynútené suboptimálne riešenie. Nútené - buď z neschopnosti používať správny typ splnomocnenca z organizačných dôvodov (nie je možné umiestniť požadovaný pohľad proxy, alebo typ pripojenia nezabezpečuje prítomnosť jedinej reálnej IP adresy, ako je to v prípade internetu cez GPRS alebo variantoch domácich sietí - v týchto prípadoch je už NAT alebo "vynútený HTTP proxy" na strane poskytovateľa), alebo z nedostatočnej informovanosti zodpovedných osôb, vr. správcov. Neberiem do úvahy finančné obmedzenia, pretože existuje veľa možností pre bezplatné alebo veľmi lacné proxy pre všetky tieto protokoly.

V niektorých prípadoch je použitie Socks5 celkom opodstatnené - napríklad pre ICQ a iných messengerov. Pre tieto protokoly jednoducho nie sú vyvinuté špeciálne proxy sú takmer neviditeľné na všeobecnom pozadí používania siete. Pri absencii lieku poštový server alebo pop3 / smtp-proxy Socks5 budú tiež ďalším kandidátom, aj keď nie všetci poštoví klienti ich podporujú a v niektorých má aj neznáme funkcie (pozri Mozilla ThunderBird).

Pri prezeraní možností bude NAT "poslednou možnosťou" - v prípade, že sa nenašlo nič lepšie, alebo ak NAT pôvodne dodal poskytovateľ - v Káblový modem, router, mobilné pripojenie(V týchto kusoch železa je nainštalovaný NAT a nie špeciálny proxy pre populárne protokoly, kvôli extrémnej jednoduchosti jeho základnej implementácie: zdrojový kód zásuvného modulu UDPMAP podobného v zariadení NAT v Eproxy má veľkosť iba 4 kb). Niektoré z protokolov nebudú fungovať, bude ťažké zvládnuť prácu. Ale v takýchto extrémnych prípadoch je lepšie nejako pracovať, ako nepracovať vôbec.

Tu je také podrobné vysvetlenie môjho známeho postoja za posledných 8 rokov - "v Eserve nikdy nebude NAT" V drvivej väčšine prípadov NAT buď nepotrebujete, alebo ho už máte za trest. pre výber providera.v zdieľaní pripojenia Windows to funguje presne ako NAT.

Pozrite si aj „barličku“ pre NAT na webovej stránke Microsoftu: Prechod NAT – prechod NAT prispôsobením aplikácií, konfigurácia NAT / Firewall cez UPnP. Ak počujete frázu NAT traversal prvýkrát, je to preto, že vývojári uprednostňujú Socks5 namiesto bariel pre opravy a táto iniciatíva nedostala „podporu kódu“. Ale ten článok je dobrý na obrázky (na rozdiel od môjho a iného nezávislého popisu problémov NAT.

NAT, ICS je už zabudovaný do všetkých nových verzií Windows

Všetky verzie systému Windows vydané od roku 1999 obsahujú NAT. Najprv pod názvom ICS (Internet Connection Sharing), neskôr pod vlastným názvom NAT. Tu je dialógové okno na povolenie NAT v systéme Windows 2003 (cez "Smerovanie a vzdialený prístup"system32rrasmgmt.msc).

Vo Windows XP je NAT / ICS povolený vo vlastnostiach internetového pripojenia.

Ak sa zobrazí správa „Nedá sa povoliť zdieľanie. Chyba: 1722: RPC server nedostupné. "(" Nie je možné povoliť zdieľaný prístup. Chyba: 1722: Server RPC je nie je k dispozícií."), potom ste s najväčšou pravdepodobnosťou zastavili alebo zakázali službu klienta DHCP, musíte ju spustiť pred povolením ICS.

NAT očami poskytovateľa Linuxu

(Dodatok 6. júla 2004 - prvá reakcia na článok. Rovnako ako v článku na FireWall, dajme slovo skutočnému sysadminovi

Citovať Ak porovnáme prácu cez NAT s reálnym, tak doteraz som mal problémy s NAT len pri prenose hlasu, videa a súborov v programoch ako MSN Messenger. Možno v niektorých implementáciách NAT "a existujú aj problémy s aktívny ftp, pripojenie na externé VPN servery a pod., ale pri práci cez NAT v Linuxe (s príslušným nastavením) to nie je problém.Výhoda NAT je v tomto prípade v šetrení IP adries a firewalle.

Ak porovnáme NAT s proxy (ako spôsob prístupu na internet, teda preposielanie požiadaviek bez ohľadu na funkcie cachovania, URL parsovania atď.), tak cez NAT funguje viac aplikácií a protokolov (všetky); nevyžaduje sa pre NAT špeciálne nastavenia užívateľom; proxy sú náročnejšie na hardvér. Proxy zvyčajne neposkytujú funkciu Destination NAT (DNAT), hoci v Eserv môžete dosiahnuť čiastočnú podobnosť DNAT pomocou mapovania tcp / udp. Koniec citátu.

Tento citát ukazuje, že požiadavky poskytovateľov sú tiež veľmi odlišné od požiadaviek správcov v podnikoch.

Spätné odkazy
články
POŽARNE dvere
MxServer
NCSI
WhatIsProxyServer

Proxy server navrhnutý tak, aby sprostredkoval medzi pracovná stanica a celosvetovej siete.

Proxy počítač odovzdá požiadavky používateľa cez seba a potom vráti výsledky získané z internetu. Toto je druh "dôverníka", ktorý uľahčuje súčasný prístup všetkých strojov lokálna sieť na internete. Zároveň je administrátor, ktorý nastavuje grid, zbavený potreby prideľovať každému jednotlivému bodu vlastnú IP adresu, aby komplexná schéma smerovanie, požiadajte poskytovateľa o doplnkovú (zvyčajne platenú) službu.

Okrem zbytočných starostí a neopodstatnených vysokých nákladov sa pri takýchto metódach, ktoré sú už našťastie minulosťou, stráca úroveň zabezpečenia dát v sieti LAN, čím sa každý jej počítač stáva potenciálnym cieľom pre vírusové útoky a hackerské vlámania... Navyše z dôvodu nedostatku centralizované riadenie, pribudnú správcovi starosti s ovládaním každej jednotlivej stanice. A, mimochodom, s druhou metódou konfigurácie výstupu LAN na internet, tiež potrebujete doplnkový program k hlavnému počítaču, ktorý bude smerovať pakety, ale na rozdiel od proxy prenáša skutočných IP klientov.

Smerovač, ktorý môže meniť adresy, je pomenovaný NAT-proxy(z anglickej skratky network address translation, čo možno preložiť ako „prekladač sieťových adries“).

NAT- najprv, najjednoduchší pohľad tohto programu také prechodné prepojenie z jedného typu nastavenia lokálnej siete na iný typ. Oprávnený " Všeobecný prístup k internetovému pripojeniu „NAT-proxy sa už nachádza vo Windows 2000 a XP. Tento program je určený pre bežného užívateľa, ktorý nemusí mať hlboké znalosti kvalifikovaného systémový administrátor... Ak chcete pracovať, nemusíte vykonávať žiadne špeciálne mazané nastavenia. Ale v skutočnosti je táto výhoda veľmi pochybná. NAT, ako univerzálny proxy, nie je schopný komplikovanosti aplikačné protokoly... Preto pre správnejšie a bezpečná práca stojí za to zoznámiť sa so špecializovanými proxy programami.

Najrozšírenejším softvérom vo svojej triede je НТТР-proxy. Už z názvu je zrejmé, že je založený na princípe organizácie práce podľa protokolu HTTP. Bez tohto programu sa nezaobíde žiadna seriózna sieť. Čo dokáže:

• Súbory prijaté z internetu uložte na disk servera, čo vám umožňuje pri opakovanej požiadavke vydávať existujúce dáta bez prístupu na WWW, čím sa zvyšuje rýchlosť práce a celková úspora prevádzky.
• Obmedzte prístup k zdrojom. Nedovoľte napríklad klientom navštevovať stránky z „čiernej listiny“. Alebo nie všetci klienti, ale len určitá skupina. Alebo nie po celý čas, keď ste online, ale iba v určitých hodinách. Táto výhoda sa otvára najširšie možnosti organizácia klientskej strany lokálnej siete
• Spravujte priority sťahovania. To pomáha vyhnúť sa úplnej absorpcii návštevnosti milovníkmi bezplatnej hudby alebo sledovania online filmov.
• Vypočítajte návštevnosť použitú v danom časovom období.
• Určite hodnotenie rôznych zdrojov

A ani tento pomerne rozsiahly zoznam zručností HTTP proxy nie je úplným vymenovaním jeho výhod. HTTP proxy dokáže pracovať aj s FTP servermi. Ale pri vzájomnej konverzii FTP a HTTP sa nuansy funkčnosti FTP čiastočne strácajú. Prirodzene, pre správna prácašpecializovaní ftp klienti sú vhodnejší a špecializovaný softvér. FTP proxy môže byť súčasťou HTTP proxy resp samostatný program ako v Eserv a Eproxy. Na zdôraznenie tohto bodu sa proxy servery Eserv a Eproxy zvyčajne nazývajú FTP-brána.

Samostatne stojí časť oddelená od NTTR pre prácu s utajovanými skutočnosťami - NTTPS-proxy. poštové služby Páči sa mi to Netopier a Outlook Express... Na tieto účely je nainštalovaný lokálny obraz servera požadovaný programom. To znamená, že ide o druh podvodu, triku, ktorý však takmer vždy funguje.

Proxy ponožiek- program, ktorý naberá na popularite tým, že zákazníkom poskytuje možnosť transparentne využívať služby za firewallmi. Naše proxy zoznamy obsahujú výber funkčných proxy serverov Eserv a Eproxy implementujú všetky uvedené typy proxy serverov (okrem NAT).

Zoberme si typický scenár – interná sieť je pripojená cez internetový prístupový server a používa jednu externú „bielu“ IP-adresu (pozri prípad použitia v časti „Kancelárska sieť“).

Úloha poskytovania prístupu na internet z internej siete sa zvyčajne rieši pomocou NAT alebo proxy servera. Každý prístup má svoje výhody a nevýhody.

Ako funguje NATje jednoduchý preklad IP adries a portov v paketoch, keď prechádzajú cez server. Prístup cez NAT nevyžaduje žiadnu konfiguráciu klientskych programov – služba transparentne prekladá všetky odchádzajúce požiadavky von. Aj tento prístup rozlišuje maximálnu produktivitu a nie náročnosť na zdroje servera. NAT však neumožňuje aplikácii otvárať prichádzajúce spojenia. To kladie obmedzenia na niektoré protokoly, ako napríklad IRC.

Dopravný inšpektor používa službu Windows NAT. Toto sa nazýva ICS ( pripojenie k internetu Zdieľanie) alebo RRAS (Server pre smerovanie a vzdialený prístup) pre serverové verzie systému.

NAT môže pracovať v režime prekladu portov a adries. Ak sa použije jedna externá adresa, použije sa preklad portu. Môžete však dodatočne získať skupinu adries od poskytovateľa a potom je možné prostredníctvom NAT priradiť externú adresu k internej. To je výhodné v prípade, keď sú v sieti nejaké servery a je potrebný transparentný preklad portov bez ich výmeny. Vždy však existuje možnosť publikovania mimo interných serverov, dokonca aj na jedinú externú adresu.

Vo svojej čistej forme je NAT z Windows málo používaný, pretože prakticky neexistuje možnosť riadenia prístupu a riadenia prevádzky.

Proxy server pracuje na úrovni aplikačných protokolov a vyžaduje primeranú podporu klientskych programov a ich konfiguráciu. Prostredníctvom nej môžete ďalej pracovať HTTP protokoly alebo FTP. Existuje aj špeciálny protokol SOCKS proxy cez ktorý môže bežať každá aplikácia využívajúca TCP. Prostredníctvom SOCKS môžete otvárať odchádzajúce aj prichádzajúce pripojenia, aby sa odstránili problémy s NAT. Jediným obmedzením je potreba podpory SOCKS z klientskych programov.

Pri práci s HTTP na šetrenie prevádzky využívajú proxy servery cachovanie (dočasné ukladanie) nahratých objektov, ktoré je možné použiť na opakované požiadavky. Používanie vyrovnávacej pamäte môže zvýšiť rýchlosť prístupu na rušnom internete.

Pomocou proxy servera môžete tiež implementovať filtrovanie na aplikačnej úrovni – napríklad zakázať prístup ku konkrétnemu zdroju na serveri alebo vykonať vymedzenie podľa obsahu údajov.

V rámci Dopravného inšpektora existuje plne funkčný proxy server HTTP / FTP / SOCKS. Implementované flexibilné filtrovanie, cachovanie a možnosť obmedzenia rýchlosti práce. Autor: funkčnosť nie je v žiadnom prípade horší ako ostatné proxy servery. Pri práci cez HTTP je dostupná práca s metódou CONNECT, ktorá umožňuje prácu s SSL a pomocou tejto metódy je možné pracovať s FTP, e-mailom a ďalšie aplikácie, ktoré to podporujú. Je tiež možné pracovať s FTP cez HTTP - klient používa HTTP ( bežný prehliadač), prijímanie údajov zo servera FTP vo forme stránok.

Existuje ešte jedna príležitosť na prácu s internetom z internej siete - je to získanie podsiete IP od poskytovateľa, konfigurácia prístupového servera ako smerovača a distribúcia „bielych“ adries klientom. Dopravný inšpektor v tejto verzii bude tiež môcť fungovať. Tento prístup je však málo užitočný predovšetkým z bezpečnostných dôvodov. Pri organizovaní DMZ (takzvaná „demilitarizovaná zóna“) však môže byť potrebné sieťové smerovanie. verejné servery(pozri aplikáciu v časti "

0

V niektorých messagingových systémoch si dvaja messaging klienti posielajú/prijímajú pakety priamo od seba v rámci chatu, resp hlasový hovor... Myslím, že hlavný mechanizmus (ako TCP) je: tieto klientske programy otvoria počúvajúci TCP socket a informujú server na odosielanie správ / ich koordinačný pár IP / PORT. Klientske programy potom získajú IP / PORT druhej strany zo servera na odosielanie správ / koordináciu. A jeden z nich (povedzme A) potom inicializuje TCP s druhým (povedzme B) s prijatým párom IP / PORT B ​​​​.

Keď pasívny klient B (ktorý očakáva paket TCP SYN) nie je za NAT alebo proxy, je to v poriadku. Ale ak B je za NAT alebo proxy, potom je pár IP / PORT v skutočnosti verejný sieťové rozhranie NAT alebo proxy.

Moja otázka teda znie, aká je jeho reakcia, keď NAT alebo proxy prijme TCP SYN? Ako odovzdajú TCP SYN príslušnému hostiteľovi / procesu za ním?

• 2 odpovede

Triedenie:

Aktivita

0

Pochybujem, že tvoj pôvodný predpoklad je správny. S najväčšou pravdepodobnosťou sa otvárajú obe aktívne spojenia na server a server medzi nimi smeruje údaje. Je to oveľa jednoduchšie a problémy, ktoré popisujete, zmiznú.

0

Táto otázka bola jasne položená už dávno, ale stále ...

chat a hlasové/video hovory sa zvyčajne riešia veľmi odlišne. V prípade chatovania budete pravdepodobne používať protokol XMPP, kde sa oba konce spoja so serverom a budú cez neho komunikovať. XMPP je na TCP na vrstve 4, pretože spoľahlivosť má v tomto prípade prednosť pred latenciou. Keďže klienti sú tí, ktorí otvárajú a udržiavajú pripojenie, v tomto prípade nebudete mať žiadne problémy s NAT.

• časti, v ktorých diskutujete o sieti (IP adresa a port) a podrobnosti o kodekoch potrebných na signalizáciu nastavenia hovoru (známe ako SDP - Session Description Protocol)
• mediálna časť, kde si efektívne vymieňate hlasový/video obsah medzi dvoma predplatiteľmi.

Signál zvyčajne prechádza cez TCP pomocou protokolov cez vysoký stupeň ako je SIP (Session Initiation Protocol). Táto správa prejde cez server. Médiá putujú cez UDP pomocou protokolov vyššej vrstvy, ako je RTP (Real Time Transport Protocol) a táto časť správ je zvyčajne peer-to-peer. Jeden UDP port možno použiť na prenos aj príjem prevádzky pre jeden hlasový / video kanál. Tiež pravdepodobne budete chcieť informácie o kvalite hovoru počas hovoru, aby ste mohli napríklad znížiť použitú šírku pásma, aby ste predišli strate paketov. Na tento účel musíte použiť RTCP (Control Protocol vozidlo v reálnom čase). V tomto prípade je prechod NAT kritický! Keďže žiadny z klientov nepozná svoje verejné IP adresy, potrebujete server vo vašej internej sieti (na verejnom internete), ktorý môže povedať „ako vidíte zvonku“, teda za NAT. Najmä. Svet WebRTC tento server pozná ICE. Keď partner vie, ako je vidieť z internetu, umiestni túto informáciu do časti SDP signalizačnej správy, aby ju druhý koniec dosiahol cez internet. Uvedomte si, že router, ktorý vykonáva NAT, môže tiež vyžadovať nejaké dodatočné nastavenia na sledovanie použitých UDP portov pre hlas a video (pre prenos NAT-back z internetu k vám).

Nakoniec sa v týchto prípadoch používajú aj iné riešenia, ale to závisí od vášho nastavenia. Ak píšete softvér pre koncový užívateľ potom budú platiť predchádzajúce vysvetlenia. Ak však píšete softvér pre podnikový trh, riešenia ako dodatočný server (známy ako EDGE) na okraji vášho firemná sieť bude spoločný postup.

Môžem o tom písať hodiny, ale to by vám malo na začiatok stačiť... :)