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".
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.
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.
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.
ČLÁNKY DO MAILU