Názory k článku NAT -- brzda rozvoje Internetu?

Prilis nechapu smysl toho clanku.
Je jasne, ze na Lupe se nebudou rozebirat technicke detaily a tudiz jsem ani necekal nejaky hlubsi vhled do problematiky. Kazdopadne by melo takovym jednoduchym tvrzenim jako napr. "Internet by se bez NAT obesel" predchazet hlubsi studium. Reseni typu ipchains samozrejme podporuji pripou komunikaci dvou klientu; viz. moduly: ip_masq_icq, ip_masq_ftp atd.

Autor by nemel situaci spatne nakonfigurovaneho NATu zevseobecnovat.

Mimochodem - vetsina problemu je dle meho nazoru spise zpusobena problematicnosti kazdeho konkretniho protokolu a nikoli NATem.

Jenze tady se nejedna o dobrou ci spatnou konfiguraci NATu, nybrz o to, ze NATy porusuji zakladni principy architektury TCP/IP (end-to-end konektivita, bezstavovost IP, TCP idle atd.), kvuli cemuz samozrejme dochazi ke spouste problemu. Ty ale nejsou zpusobeny problematicnosti konkretnich protokolu (ta vetsinou spociva pouze v tom, ze se vyrobcum a uzivatelum NATu chovani protokolu nehodi do kramu :-) ), nybrz pochybenosti prekladu adres jako takovou. Zminovane moduly ip_masq_icq a ip_masq_ftp jsou jen a pouze berlicky, ktere se snazi pro konkretni protokoly problem obejit a dodatecne napravit.

Ja si myslim, ze spravne otazka nezni "obejde se Internet bez NATu?", nybrz "existuje jediny rozumny duvod, proc NAT pouzivat" :-)

Jediny rozumny duvod, proc NAT pouzivat, podle meho nazoru existuje.

Firma, ve ktere jsem pracoval, potrebovala pevnou linku. Problem byl ovsem v tom, ze podle providera nemame narok na cele C, ktere by nam vyhovovalo, ale protoze jsme mala firma, tak nam priklepnou maximalne 32 adres. V te dobe by to sice jeste bylo jakz-takz OK, ale do budoucna bylo zapotrebi pocitat s tim, ze se mnozstvi pocitacu ve firme zvysi, takze podle me jedinym resenim bylo NAT. Nebyl jsem z toho vubec stastnej, ale co se dalo delat. Navic nam jeste vyhrozovali, ze pokud je nebudeme pouzivat, ze nam je seberou - rekl jsem si, at si je teda strcej nekam :)

Da se to udelat jeste jinak? Pripojit 100 pocitacu pomoci 32 (presneji 30) adres?

Zalezi na tom, co potrebujete. Ja tady mam podobnou situaci. Resim to bez NATu - mam na gateway vyply forwarding, HTTP a FTP se dela pres proxy (Squida), pro mail mame POP3 a ten gateway dela smarthosta. A staci to.

Toto je krásný příklad, že paradigma Internetu end-to-end změnily dávno před NATem proxy-servery. Ale ty se všude z úvah vynechávají.
(A transparentní obzvlášť - pouze jednou za rok se někde napíše, jak třeba v červnu 2001 nejely a jak na jaře to už bude lepší.)
Ovšem úvahy typu "bez NATů by už bylo IPv6" jsou asi podložené stejně, jako že bez NATů by bylo více lepších proxy-serverů.

Jde ale o zásadní věc, proč se Internet tak rozšířil. Podle mě právě pro svou jednoduchost, že vyhodil některé skoro zbytečné vrstvy ISO/OSI. Což samozřejmě někdy někomu chybí, ale bez této pragmatičnosti by to s ním dopadlo jako s X.25 (anebo jako kdysi s Algolem oproti Fortranu).
A odtud vzniká otázka, zda IPv6 někde nepřekročilo onu jednoduchost (třeba v překladu adres), a zda právě proto není zatím plně funkční "jen v RFC-dokumentech".

změnily dávno před NATem proxy-servery. Ale ty se všude z úvah vynechávají.

Kdyz mermomoci chcete ironizovat, reknete, co je to DAVNO pro NATem (klidne zahrnte i ty transparentni). At se trosku pobavime, ne?

O NATu je RFC1631 z roku 1994 s odkazy na rok 1993. A ještě tam (tehdy) píší, že o tom nikdo jiný moc neuvažuje. Za to o proxy je zmíňka již v Glosáři z roku 1991 (RFC1208). Je pravda, že ne exlicite s WWW, ale v podobném smyslu.
Pokud ironizuji, tak proto, že vždycky někdo píše někam zasvěcené články o něčem - jako například o transparentních proxy-serverech TENu (teď vlastně zase CESNETu) a pak je mu třeba celý měsíc jedno, že nejedou.
A to o NATech mi připadá podobné. Zase si nějaký "český instalatér" něco někde nainstaloval a teď o tom publikuje vědecké pojednání. Ale nedej Bože, kdyby si přitom jen zmínkou někdo dovolil zapochybovat! Na to jsou přece osvědčené "novinářské" metody.
Abych se tedy vrátil k věci. Jak se Vám v úvahách o end-to-end paradigmatu podařilo zapomenout na proxy? Povězte, ať je ještě více legrace.

Pro porovnani. Zminka v glosari je opravdu trefna (zvlaste v kontextu s WWW) - kazdy necht ji porovna s RFC1631, ktere je NATu venovano cele.
proxy: The mechanism whereby one system "fronts for" another system in responding to protocol requests. Proxy systems are used in network management to avoid having to implement full protocol stacks in simple devices, such as modems.

Jinak, pro Vasi informaci:

• nejsem vynalezce ani instalater end-to-end konektivity
• nemam nic spolecneho s vyberem, funkci a provozem jakekoliv transparentni kese (a to vcetne jeji nefunkcnosti cely mesic)
• vedecka pojednani resim zasadne na vedeckych forech

Komentar neni o end-to-end paradigmatu, ale o NATu. Komentar o end-to-end sluzbach si ponecham na budoucnost.

jinak o proxy v oblasti WWW pojednava napriklad RFC1630 :-)

Za to tady na proxy nezapomněli.
To mi nějak vyjelo z jednoho searche, když jsem zadal některé méně obvyklé termíny z Vašeho článku. Tím ale, zdůrazňuji, vůbec nic jiného nemyslím.)

No tak nevim, ale mam doma sesitovany 2 compy a conectim se dial-upem, na svym mam Winroute, kterej pouziva technologii NAT a na tm druhym compu facha ICQcko bez problemu. Navic je lepsi oproti proxy v tom, ze nemusim konfigurovat localhosta v aplikacich. Samozrejme je rozdil 2 compy a podnikova sit, ale myslim,ze to je dobra technologie. Jedinou nevyhodu bych videl v tom, ze treba kdyz posilam SMSku z PG brany, tak ona detekuje IP, takze, kdyz nekdo posle SMSku z toho druhyho compu tak ja nemuzu na ty 2 min, ale to je detail, jinak sem s tim neshledal zadny problemy.

Na to existuje jednoduche reseni - zmente si providera. Normalni LIR by mela adresy pridelovat podle skutecnych potreb zakazniku. Pokud mate 100 pocitacu, neni zadny duvod, proc by Vam nemela LIR, ktera je soucasti Vaseho ISP, pridelit /25 sit (128 adres) a v pripade, ze pocitate s rozvojem nebo mate slozitou vnitrni strukturu site, tak /24 sit (256 adres).

Zajimave je, ze tech par kusu adres (slo o rady C), o ktere jsem zadal, jsem vzdy dostal.

myslim ze neni problem v providerovi, ale jak sam pisete
"...a v pripade, ze pocitate s rozvojem nebo mate slozitou vnitrni strukturu site..." a jak je uvedeno pro evropu na www.ripe.net obhajit ze ty IP opravdu potrebujete a neplytvat. pak neni problem dostat i nekolik C.

No to jste panve spadli z visne, ne?

Kdyby si VSICHNI si zazadali o IP pro vsechny sve pocitace, tak uz ty IP adresy davno dosly.

tedy fakt, ze neni problem ziskat IP adresy je tu jen a jen proto, ze takto vsichni nejednaji! NASTESTI!

Proc si to myslite ?

Dovolím si nesouhlasit.

Moduly, které umožňují směrování určitých služeb i v rámci privátní sítě sice existují, ale dle mého názoru je to poměrně obskurní řešení. Domnívám se, že pokud to má fungovat stoprocentně, musí to být založeno na znalosti směrovaného protokolu a do něj podle mě jádro systému nemá vůbec co lézt, jeho pole působnosti by mělo končit u hlaviček paketů. A pokud se má řešit problém na úrovni protokolu, měla by to nejspíš dělat aplikační brána.
Navíc říkáte, že autor článku situaci "špatně nakonfigurovaného" NATu zobecnil, ovšem Vy jste se zase naopak konkretizoval pouze na Linux.

Já osobně si myslím, že NAT (i když v tomto článku se mluví spíše o IP masqueradingu) je řešení, které sice jeden problém odstranilo, ale několik dalších způsobilo, a to není dobře.

Vy i pan Mares mate pravdu, ja jsem se vyjadroval spise k jine charakteristice clanku.
Snazil jsem se poopravit informaci uvedenou v clanku, kde se tvrdi, ze nektere veci diky NATu nejsou mozne, coz neni pravda.
Otazkou (spise filosofickou) pak je jakou hodnotu ma informace odvozena z nepravdiveho predpokladu.

Vyhoda NATu je ze rychle (nemluvim ted o kvalite) resil to co se zatim nebylo schopno vyresit "samo" (napr. implementace IPv6).

Ad konkretizace: Reseni ktere jsem uvedl se tyka nekterych klonu Unixu (OpenBSD, Linux,...) - to byl jeden konkretni priklad pro nejcasteji pouzivane NAT prostredi.

Ja bych to formuloval jinak: Nektere veci neni mozno diky NATu delat normalne a aby fungovaly, musi se pro ne zrizovat ruzne vice-ci mene obskurni berlicky.

Návrh pro autora. :-)

Souhlasím s tím, že by NAT být nemusel, ale pak máme problém s počtem IP. :-(

Chtělo by to informace jak daleko je to s jeho prosazením ve světě :-) .........

www.6bone.net ;) IPv6 se nastesti v posledni dobe zacina docela rozvijet. Pokud vim, tak 3G site maji pouzivani IPv6 primo ve specifikaci, proto prave 3G operatori docela tlaci na jeho rozsireni. U nas zatim moc lidi funkcni IPv6 konektivitu nema. A co se tyce sveta, tak mam spis pocit, ze zatim vetsinu provozu generuje IRC ;)
JV

Bohuzel s Vami nesouhlasim, pokud bychom nemeli NAT, IPv6 by tu davno bylo naprosto samozrejme a problem by byl vyresen (vcetne mobilnich IP!!!), takto porad musime hledat berlicky, musime porad pouzivat nejake maskarady, brany, port-forwarding apod. - toto stejne zadne bezpecnosti neprispiva a co vice, mnoho problemu pridava, ja bych podotkl, ze pomerne velkym problemem je prave NAT pri VPN - zalezi samozrejme v ktere casti, protoze konkretne u IP-Secu (AH) je sifrovana a zpetne kontrolovana i hlavicka...
Kdyby se misto omezenych berlicek s velmi kratkodobym dopadem radeji resily skutecne problemy a implementace staly za to, pak dneska by bylo IPv6 a IPsec naprosto normalni a nemusely by se veci, ktere maji byt na transportni urovni (zjednodusim-li vyrazne ISO/OSI) neustale dokola implementovat na urovni aplikacni - konkretni priklad - kdyby byla poradna podpora a vyuziti IPsecu, pak tu neni potreba PGP, SSL, SSH, APOP a jine proprietalni protokoly, protoze tyto veci nepatri na aplikacni, ale transportni uroven... - TCP take automaticky povazujete za protokol, ktery umi A-Z a vse ostatni je zalezitosti transportniho (IP) protokolu... a tim padem takove SSH muzeme degradovat na obycejny telnet, protoze rozhodne neni veci aplikace jaky transportni protokol bude vyuzit a zda-li to budu tunelovat pres SNA, IPX ci jine site... myslim, ze tyto otazky, byt nesouvisi primo s nadpisem clanku velice uzce souvisi s touto problematikou.

Problem s pocem adres se z velke casti povedlo poresit pres classless delegation :-)

Navic je proste pravda, ze zavedeni NATu uspalo na dlouhou dobu IPv6 a nebyt tedy techto nahrazkovych reseni, nemuseli si 3G operatori lamat hlavy, co s tim obsahem, co je na sitich v IPv4 ...

classless by nedostatek neresil.

Podle mne je dnes jiz obrovske mnozstvi stanic na privatnich adresach a kdyby nebyl NAT (neverim ze IPv6 by byl o tolik drive nasazovan, viz stale trvajici problemy s implementacich), meli bychom spoustu problemu.

Clanek je sice IMHO pomerne dobry, nicmene se zaverem nesouhlasim.

NAT je totiz zpravidla implementovan az na prostredcich koncoveho uzivatele (firmy) a ta ma tedy ve vlastnich rukou nastroje na jeho spravu (ISP kteri nedaji klientum zadnou IP verejnou adresu a sami delaji MASQ se snad moc nevyskytuji). Pokud opravdu potrebuje verejne IP adr., muze je ziskat (pokud ma neschopneho providera, musi holt zvolit jineho). Zakaznici maji tedy moznost volby.

NAT je bezesporu _velmi_ uzitecny z hlediska bezpecnosti. Je sice pravda, ze dobre nastaveny firewall muze plnit tutez funkci, jenze spousta firewallu neni nastavena zrovna dobre a pri pouziti NATu se alespon nikdo z vnejsku nedostane na stanice ve vnitrni siti (bez prolomeni firewallu) tj. nemuze zneuzit spatne zabezpeceni kterehokoliv pocitace z interni site.To vyznamne omezuje riziko utoku ze strany :script kiddies: a podobnych :uchylu: :-].

Co se tyka omezeni aplikacnich protokolu, vetsina problemy nema. Samozrejme je to horsi s peer-to-peer aplikacemi, nicmene tech neni moc a pokud je nekdo potrebuje, ma realnou sanci ziskat verejne IP adresy.

Globalne je tedy NAT velmi uzitecnym nastrojem a myslim, ze i v budocnosti (da-li BUH, vendori a dalsi :) IPv6 se budou podobne mechanismy pouzivat.

Sayonara !

myslím, že to strašně zjednodušujete. Kdyby se internet bez NATu obešel, nat by tam prostě nebyl.
Ano, nyní už tak velký problém s IP adresami není, spousta A sítí které byly rozdány předtím některým firmám se sebrala a přerozdělila. Ale i to je jen oddálení problému, stejně jako NAT. Samozřejmě - IP v.6 by to všechno řešilo, ale ...
... použití IP v. 6 je v současné době skoro nemožné. Vždyť ještě nyní naprostá většina aktivních prvků (resp. kromě asi 3 produktů jednoho výrobce) IP v 6. nepodporuje! Stejně tak ještě v ani jednom operačním systému není nativní podpora IP v.6! A ani tak v ostatních IP zařízeních.
V podstatě by to znamenalo vyhodit veškeré zařízení a nahradit je novým. Samozřejmě, dá se tunelovat ip v. 6 přes ip v. 4. Ale to už jsme pak nazpátek u problému s adresami.
Samozřejmě, IP v. 6 přijde. Ale v současné době je to typický problém slepice a vejce - co dřív?
Výrobci systémů a aktivních prvků se brání tím, že není poptávka. A ti co by to chtěli využívat zase nemůžou (a nebo za příplatek) protože není na čem.
Podle mě je nat velmi důležitý a rozhodně na toto mezidobí pomohl vyřešit problémy. Až se rozběhne IP v. 6 či něco jiného, tak sám od sebe možná vysublimuje. Ale do té doby se bude stále více rozšiřovat. A navíc vznikne nová obdoba NAT - a to je právě překlad z/do ip v.4 do ip v.6. Tohle mimochodem naopak velmi urychlí přechod, protože nebudete potřebovat aby všechny stroje uvnitř sítě podporovaly ip v.6, prostě pojedete do nějakého NAT, který to přeloží a pošle po ip v.6 dál.

A už se blýská na lepší časy. Tady v praze už je v provozu testovací síť, testují se aktivní prvky atd. Ale takových míst na světě je že by se dali spočítat na prstou dvou rukou. A tak si určitě ještě nejaký ten pátek počkáme. Tipovací soutěž - nejdříve 2005, spíše ale nikdy (do té doby vymyslí ještě něco jiného)

A Linux podle Vas neni operacni system? :-) Nebo podpora neni nativni, kdyz neni defaultne zapnuta v jadre? ;-)

Linux a OpenBSD urcite maji IPv6 nativni podporu, odtatni BSD unixi muslim taky. To, ze windows nemaji, neznamena, ze zadny system nema.

ale Windows ji maji, jen kdybyste nebyl nouma a podival se :-)

viz http://www.hs247.com/

Cisco jiz konecne zacalo podporovat IPv6 v oficialnich IOSech. A jiz po dlouhou dobu byli dostupne testovaci beta releases. (Taky sem jednu mel na sve malickem 2511, ale po urcitych problemech sem ji byl nucen odstranit). Jinak je pravda, ze v .cz IPv6 nejak moc rozsirene neni. V 6bone databazi je pro .cz asi jen 6 zaznamu, z toho asi trem funguje zahranicni konektivita. Co se tyce vaseho tvrzeni "ale to uz jsme pak nazpatek u problemu s adresami", nemyslim si, ze i pri vetsim pouzivani IPv6-in-IPv4 tunelu potrebujete mnoho IP adres, protoze i jeden takovy tunel vam bez problemu poslouzi pro biliardy v6 adres ;)
JV

Pracuju ve firme, ktera ma cca 55 000 pocitacu po celem svete, ktere jsou propojeny do jedne site a tak je logicky sit chranena Firewally. A prave Firewally (jelikoz jsou dost striktne nakofigurovany) nepropousteji komunikaci peer_to_peer aplikaci jako napr. ICQ, Napster a podob.

A proto nechapu, jak by treba konkretne nasi firme pomohla implementace IPv6, kdyz stejne sit musi byt nejak chranena a nic jineho nez pouziti Firewallu me nenapada.

A co je takhle prekonfigurovat ? :o))) Ne, vazne. Pokud mate tento typ komunikace striktne zakazan na FW, pak uz je jedno, jestli se ven vyklapite pres NAT , nebo 1:1 na IPv6, protoze ta komunikace stejne nepobezi :o)Ostatne valna vetsina FW je nakonfigurovana prave timto systemem.

No, vsechny tyhle uvahy o "nepotrebnosti" a "brzdne funkci" natu jsou velmi hezke, ale v realu se bez NATu bohuzel neobejdeme. Nase firma vlastnila cele Ccko a po zmene providera jsme byli nuceni ustoupit na 16 adres. Byla to vicemene i nase volba, ze preklad zevnitr ven nebude fungovat 1:1 na adresy, ale pouze na porty(PAT). Navic vam NIKDO neda cele Ccko kvuli tomu, aby jste si mohl prekladat intranet ven 1:1 na adresy. To je demagogie a proste to NEOBHAJITE. Dostanete cele Ccko v pripade, ze budete lhat a vymyslet si historie o 50 ssl serverech, 60 webovych serverech atd. Pak Vam to projde. Co vam to dela s zaludkem nevim, ja jsem toho schopen nebyl. V soucasne dobe je to JEDINE pouzitelne reseni. Hajite tu IPv6, ale my uzivatele nemuzeme za to, ze ISP nebyli schopni (ono to ani bez rozumne podpory vyrobcu HW nejde, ze :o) ) IPv6 nasadit do realneho provozu. Takze placete na spatnem rameni nas, uzivatelu, pro ktere je NAT ci PAT spasou v omezenem adresnim prostoru. Necht ISP prestanou skudlit s IP rozsahy, urychli nasazeni IPv6 a muzeme zacit hyrit v IP rozsahu treba 5ti Ccek. Pak uz reseni na bazi NATu nejspis nespatrite :o). Zdravim.

Nase firma vlastnila cele Ccko a po zmene providera jsme byli nuceni ustoupit na 16 adres.

Hm ... Myslim, ze jste uhodil hrebicek na hlavicku. pokud ten pozadavek spravne zargumentujete (a pocet HOSTu v lokalni siti je absolutni argument), tak neni duvod, proc byste nemeli dostat patricny pocet adres. Nebo jste si meli zvolit nejakeho providera, ktery neskrti IP adresy.

At zije univerzitni prostredi! At zije marnotratne pridelovani ostre IP adresy pro kazdy stroj na siti! Proc by Vam nemel nejaky vtipalek posilat po siti formfeedy na tiskarnu! Proc by se nemel pomoci weboveho rozhrani divat, co strkate do kopirky, ktera zarovne funguje jako tiskarna a scanner pristupny pres webovy interface! Pan profesor bude mit take jiste radost, kdyz si jeho vedecka pojednani budou cist script kiddies primo z jeho pocitace, pripadne mu je zmeni nebo smazou! A z CD-ROM serveru urceneho pro instalaci software po lokalni siti se neumyslne stane zajimavy warezacky server...

... pokud si myslite, ze NATem uvedene problemy vyresite, tak se muzete dockat pomerne neprijemneho preqapeni.

V dobe kdy byl NAT navrzen (tusim asi polovina 90. let)
IPv6 nebylo ready, takze se do toho nikomu jit nechtelo. Zda
se, ze s IPv6 to zatim prilis vazne nemysli ani predni vyrobci sitovych routeru (CISCO, 3com, ...) IPv6 je zatim podporovan v otevrenych systemech *BSD, Linux, ..., MAC-OS-X.

Co se tyce odstraneni zasadnich nedostatku NATu (t.j. poruseni E2E) doporucuji precist si RFC k protokolu RSIP,
tusim, ze se jedna o RFC3102 - RFC3105. Je to velice zajimavy napad, i kdyz asi tesko realizovatelny.