Vlákno názorů k článku NAT vesus NAP od Tom - Nemohu s vámi v žádném případě souhlasit protožě...
-
Článek je starý, nové názory již nelze přidávat.
- Podle hodnocení
- Podle vláken
- Nejnovější
-
Ondrej Zajicek (neregistrovaný)>> Je zde hromada problemu a IPv6 je vsechny elegantne resi.
>Co je na IPv6, nedejboze na hruze jako dualni IP stack elegantniho?
Co je spatneho na dual stacku? Clovek muze mit v systemu i vice stacku (IPv4, IPv6, IPX, DECnet, ...)
> Funkcni IPv4 stack jde napsat v cca 6kb i386 kodu- to ma k "eleganci" pres vsechny svoje chyby mnohem bliz.
Mluvim o eleganci reseni problemu, ktery prinaseji NATy - tyto problemy samozrejme samotny IPv4 stack neresi.
> STUN
O STUNu sice mnoho nevim, ale pochybuji ze odstrani tyto problemy:
1) Nefunkcni IPSec pres NAT.
2) 2 klienti na stejne L2 siti s privatnimi adresami, kteri spolu chteji komunikovat, pricemz vyuzivaji registracni software na verejnem Internetu, a tedy znaji akorat sve verejne adresy.
Krom toho implementovat IPv6 do aplikaci je IMHO mnohem jednodussi nez tam implementovat STUN. Aplikaci podporujicich IPv6 je IMHO mnohem vice, nez aplikaci podporujicich STUN (osobne takovou neznam). A jeste jsem nevidel mnoho ISP, kteri k NATu nabizeji take STUN server, i kdyz zde asi ISP poskytujici IPv6 konektivitu prevahu nemaji.
> Sila NATu je ze pro 99% aplikaci je naprosto transparentni, neni treba ani sahnout na binarky, a neni treba utracet $$$ za novy hardware.
Pokud pocitas kopie, tak mozna, ale to je, myslim, irelevantni. Pokud bych pocital kazdy ruzny program prave jednou, tak to odhaduji tak na 50%, spis i mene.
-
Zdenek (neregistrovaný)> Je zde hromada problemu a IPv6 je vsechny elegantne resi.
Co je na IPv6, nedejboze na hruze jako dualni IP stack elegantniho? Dyt i Satrapa kazdych par mesicu pise jak je to nehotovy, nezraly, a neustale se menici bastl. Funkcni IPv4 stack jde napsat v cca 6kb i386 kodu- to ma k "eleganci" pres vsechny svoje chyby mnohem bliz.
> Proste aby svet s NATy slusne fungoval, tak by nejdrive musel existovat standardni zpusob detekce NATu a jejich otvirani zevnitr a musela by se dopsat podpora pro takovy system do vsech NATu a aplikaci.
a) STUN, RFC 3489
b) Nikoliv do vsech aplikaci, pouze do vsech serveru a P2P aplikaci. A IPv6 musi aplikace podporovat (=musi se dopsat) taky, pouha rekompilace obvykle nestaci, takze vam nepobezi ani trivialni klient, ktery za NATem v IPv4 svete v pohode bezi.
Sila NATu je ze pro 99% aplikaci je naprosto transparentni, neni treba ani sahnout na binarky, a neni treba utracet $$$ za novy hardware.
-
xChaos (neregistrovaný)To myslím jenom taková ničím nepodložená teorie.
Stejně dobře by šlo například tvrdit, že v dnešním statickém internetu netečou vůbec žádné informace - ale jenom spam, viry, červy, pornografie, a kradená hudba a filmy. To by ale bylo samozřejmě také jenom takové ničím nepodložené tvrzení... netvrdím že to tak je, dokonce ani netvrdím že by se to mohlo někdy stát, že by to reálně hrozilo...
Zkrátka dynamické přeadresovávání celých sítí je něco, co by se bud' dalo udělat dobře a fungovalo by to - nebo špatně a nefungovalo by to. Podle mě tvrdit, že to z principu NEJDE udělat dobře je trochu přehnané - stejně jako tvrdit, že to NEJDE udělat špatně. Jisté je jenom to, že mnou navrženou koncepci lze vzít, a implementovat ji zcela chybně a nefunkčně - o tom jsem pevně přesvědčen :-)
Samozřejmě je to ještě možné zkombinovat z dynamickou délkou adresy... ale uznávám, že to je už pro většinu lidí hodně obtížně pochopitelné... nejlepší by tedy bylo, kdyby to celé bylo zakodované rovnou v nějakém open source kernelu - takže by to všichni brali tak jak to je a používali by to a zbytečně by do toho nekecali, pokud by jim to vydělávalo nějaké peníze :-)
-
xChaos (neregistrovaný)Řekl bych, že hlavní problém IPv6 je stejný jako u IPv4 - a je jím centrální alokace adres - s tím, že autority které adresní rozsah spravují, si rozhodně za alokaci adres nechávají platit.
Řešení by existovalo - a byla by jím ochota k dynamickému přečíslování u libovolných dvou sítí, které se chtějí propojit. Na délce adresy nebo použitém adresním schématu přitom ochota k automatickému přeadresování v podstatě nezávisí - je možné si ho představit u IPv4, IPv6 i u něčeho úplně jiného a nového. -
J (neregistrovaný)Ony tu nejake pokusy jsou a vetsinu z nich podporuje OS SW, coz nic nemeni na tom ze se globalne moc nepouzivaji.
Ovsem podle me to neni tim, ze by to nefungovalo, ale proto, ze predevsim providerum se soucasny stav hodi do kramu. Proc neprodavat verejnou IP kterou ziskam zdarma ze. Zisk = 100%.
(ano, vim ze za clenstvi v ripe se plati, ale clen za svuj poplatek ziska poradnou porci IP adres a vetsina ISP clenem v ripe neni a IP adresy ziskava v ramci svych smluv v cene konektivity). -
Ondrej Zajicek (neregistrovaný)> Obvykle je NAT jedinou gw, a aplikacni brany jsou umistene na stejnem miste, takze data nejkratsi cestou jdou.
> Ale neni technicky problem udelat IM sluzbu pres UDP, aby byla NAT friendly- UDP je ostatne pro IM uspornejsi a vhodnejsi.
Je zde hromada problemu a IPv6 je vsechny elegantne resi.
Typicky problemovy pripad - dva lidi na lokalni siti spolu komunikujici pres VoIP a pouzivajici registracni server kdesi na Inetu. I pokud vse jde dobre, tak jdou data zbytecne na NATovaci gw a zpatky, coz muze byt drasticky rozdil (typicky pripad - panelak pripojeny wifinou k nejake internetove gateway, kde se provadi NAT).
Dalsi vec, ktera si s NATem neporadi, je P2P software, ktere se neregistruje na zadnem registracnim serveru (napriklad tradicni talk, nebo SIP bez registrace). Takovy software v pasivnim rezimu (cekajici na prichozi hovor) zadne pakety neposila, tudiz nemuze oteverit diru v NATu.
Proste aby svet s NATy slusne fungoval, tak by nejdrive musel existovat standardni zpusob detekce NATu a jejich otvirani zevnitr a musela by se dopsat podpora pro takovy system do vsech NATu a aplikaci.
-
Zdenek (neregistrovaný)O principialnich a neodstranitelnych problemech jsem uz parkrat slysel. Vzdycky to ale dopadlo jinak- staci jen chtit. Namatkou:
/SYN flooding had been considered by security experts before. It was generally considered insoluble. See, for example, ``Practical UNIX and Internet Security,'' by Garfinkel and Spafford, page 778:/ -
Michal Kubeček (neregistrovaný)Do velke miry to univerzalni je. Lidi (navrhari aplikacnich protokolu) uz jsou rozumnejsi, a nestrkaji vnitrni adresy do payloadu, kde je NAT nenajde, tudiz neprepisuje, tudiz to nebeha.
To je jen část problému. Druhou částí je to, že mi ten port forwarding musí někdo připravit. Doma mi to nevadí, protože ten někdo jsem také já. Když budu v roli běžného uživatele ve firemní síti (nebo oběti nějakého pseudopřipojení), vadit mi to bude poměrně dost.
Ale neni technicky problem udelat IM sluzbu pres UDP, aby byla NAT friendly- UDP je ostatne pro IM uspornejsi a vhodnejsi.
Pořád si asi nerozumíme. Základní problém je v tom, že počítače koncových uživatelů dnes nejsou adresovatelné. V tom vám UDP nijak nepomůže.
Problem "toho tretiho": a DNS vam nevadi?
Nevadí. DNS se ptám jednou před samotným navázáním komunikace, ne pro každý paket znovu a znovu. Někdy ani to ne, protože se o to postará lokální cache.
-
Zdenek (neregistrovaný)Do velke miry to univerzalni je. Lidi (navrhari aplikacnich protokolu) uz jsou rozumnejsi, a nestrkaji vnitrni adresy do payloadu, kde je NAT nenajde, tudiz neprepisuje, tudiz to nebeha.
Obvykle je NAT jedinou gw, a aplikacni brany jsou umistene na stejnem miste, takze data nejkratsi cestou jdou.
ICQ funguje tak jak funguje z nekolika duvodu- predevsim je routovani packetu pres centralni server zadouci (jde o slusne "koncentrovana" data pro smirovani a data mining), dale traffic je relativne maly takze jeho nasobeni dvema tolik nevadi, navic je to nejjednodussi a nejspolehlivejsi reseni.
Ale neni technicky problem udelat IM sluzbu pres UDP, aby byla NAT friendly- UDP je ostatne pro IM uspornejsi a vhodnejsi.
Problem "toho tretiho": a DNS vam nevadi? -
Zdenek (neregistrovaný)Dejte pokoj.. skoncime u toho ze primo propojene jsou maximalne dva entanglovane elektrony, kdovi jestli :)))
Tvrdite ze co bezi pres TCP/IP (rozumim bez nadstaveb v aplikacni vrstve), je "primo"? Takze kdyz aplikace pouziva treba upraveny winsock32.dll, ktery vsechno lifruje pres SOCKS proxy, je to podle vas primo?
-
Zdenek (neregistrovaný)Ano, "inzerovanim" rozumim zaregistrovani aplikace v nejakem adresari: uzivatel X je online, dosazitelny na nejake verejne adrese (slozene z vnejsi ip NATu a forwardovaneho portu). Obvykle nastesti klient svou adresu nesdeluje explicitne, ale adresar se ji dozvi ze socketu, takze to funguje zcela transparentne.
Proc by mel NAT premyslet? pod pojmem "portforward" rozumim vyjmuti urciteho portu z poolu, z kterych NAT alokuje vnejsi porty pro odchozi spojeni, a jeho pevny 1:1 preklad do vnitrni adresy.
Obsah paketu se meni vzdy.
Lidi jsou dulezitejsi nez protokoly.
Mejte se hezky.
-
J.K. (neregistrovaný)>Ostatne soudim, ze NAT musi byt znicen.
Já nějak nechápu, proč zrovna NAT, když se v článku právě píše, jak simulovat jeho ochrany (které možná vznikly jako jeho vedlejší efekt).
A navíc v těch bezčárkových hatmatilkách od Krska věčně něčemu napoprvé nerozumím.
Nemohl by si už i Krsek pořídit někde v bazaru českou klávesnici? (Uznávám, že znát zpaměti &#nnn; pro celou češtinu je dost náročné.) -
Michal Kubeček (neregistrovaný)Ano, přesně tak to také chápu. Počítače, které jsou v síti za maškarádou, nejsou pro mne součástí Internetu. Mohou s určitými omezeními přistupovat k některým službám, dostupným přes Internet, ale nejsou jeho součástí. Jeden z mých počítačů (ten, u kterého právě sedím) součástí Internetu je, ten druhý (který je teď vypnutý, ale i kdyby nebyl, nic by se na tom nezměnilo) součástí Internetu není, přestože z něj mohu k některým službám přistupovat.
-
Michal Krsek (neregistrovaný)Je pravdepodobne, ze jste to z druheho konce pochopil Vy :-)
Prime propojeni muze byt realizovano i protokolem TCP/IP. Pokud neprijimate toto paradigma, nemuzete prijmout ani paradigma, ze mezi pocitaci je nejaky dalsi prvek - treba ethernetovy prepinac. Takze prime propojeni byste mel pouze u dvou pocitacu primo propojenych kabelem :-)
-
Michal Kubeček (neregistrovaný)Portforward univarzalni end-to-end konektivitu poskytuje
Univerzální v žádném případě. Nanejvýš částečnou a to ještě jen za určitých předpokladů.
Podivejte myslim ze je uplne jedno jestli jdou data primo nebo pres nejake relays, a je taky uplne jedno jestli jim rikate "routery" nebo "aplikacni brany" … Dokud data putuji nejkratsi cestou, nevidim nejmensi duvod rozlisovat "primo" a "neprimo".
Jenže u mnoha služeb to zdaleka nejkratší cestou nejde a je to právě vinou toho, že většina uživatelů je schovaná za různými maškarádami. Stačí se podívat na to, jak jsou navrženy služby typu ICQ nebo jiné formy "pokeců". Další podstatný rozdíl vidím v tom, že zatímco routing je navržen tak, že dva koncoví uživatelé spolu mouhou komunikovat v podstatě jakýmkoli (aplikačním) protokolem, který je napadne, u různých typů proxy a portforwardingu se to neobejde bez asistence někoho třetího.
-
J (neregistrovaný)Jasne, jenze clislovaci plan je snadne odhalit, pokud jsou IP bezne dostupne zvenku, snadno zjistim ktere IP jsoiu koncove, ktere patri smerovacum a z toho uz muzu odovdit jak se IP prideluji ... .
Jen nevim, na co mi to bude, protoze pokud chci nejaky stroj napadnout, potrebuju predevsim informace o nem.
Me absolutne nejvic stvou firmy (predevsim ty velke), majici casto pridelene ohromne rozsahy verejnych IPv4, ktere se v internetu nikdy neobjevi.
Jinak se znicenim NATu souhlas, uz me nebavi vecne vsem vysvetlovat "a proc mi to od tohodle nejde a od tohodle jo", "a co je to ta verejna IP", "a co je to vlastne ten internet", ... -
Michal Krsek (neregistrovaný)Dobry den,
ja chapu, ze v Praze je ted osklive vedro, ale zkuste mi prosim rict, JAK aplikace inzeruje? Myslite v nejakem adresari? Jenze co kdyz si ten prekladat pomysli, ze ma prekladat jinak?Mimochodem, univerzalni end-to-end konektivita se vyznacuje tim, ze je spojeni transparentni (po ceste se nemeni obsah paketu).
Podotykam, ze v tuto chvili neresim, transparentnost smerem k uzivateli - protoze ta je zcela irelevantni. Resim obycejnou transparentnost pro sitove protokoly :-)
Co se tyce chladici helmy, zatim travim cas v klimatizovane mistnosti a vzhledem k brzke ranni hodine tu neni tak vedro.
Zdravi
MK -
Zdenek (neregistrovaný)Portforward univarzalni end-to-end konektivitu poskytuje, mirne problematicke je pouze ze aplikace musi jako svoji adresu inzerovat vnejsi interface NATu, ale tu se celkem snadno dozvi. Neni to sice uplne transparentni, ale to neni nic.
Adresni plan- souhlas, beru zpet.
Helma: no jestli vam pomuze, tak si ji nasadte :) Podivejte myslim ze je uplne jedno jestli jdou data primo nebo pres nejake relays, a je taky uplne jedno jestli jim rikate "routery" nebo "aplikacni brany", pokud je to pro uzivatele rozumne transparentni.
Lidi posilaji maily, vykecavaji se po voipu, a maji opravneny pocit ze to jde "primo", prestoze data lezou pres X smtp serveru, rtp proxin, a desitky routeru. Dokud data putuji nejkratsi cestou, nevidim nejmensi duvod rozlisovat "primo" a "neprimo". -
Michal Kubeček (neregistrovaný)sem netušil že pro Vás "Internet" končí na defaultní gw
Podle okolností. Pro mne končí Internet tam, kam je možné se dostat pomocí IP protokolu. Ano, velmi často je to na přístupové gatewayi lokální sítě. U hodně zvrácených způsobů "připojení" to může být i někde u ISP…
-
Michal Krsek (neregistrovaný)Problem neni s nejakymi portforwardy. Problem je s tim, ze namete end-to-end konektivitu. A portforwardy rozhodne univerzalni end-to-end onektivitu nedosahnete.
No ja nevim, proc bych mel svuj adresni plan vystavovat na Internetu? Nedelam to u IP, proc bych s tim mel zacit v IPv6? Od RIPE NCC dostanu prefix, stejne jako jsem dostal IP prefix (pravda, je trosku delsi).
Proti trollovani pomaha chladici helma.
Ostatne soudim, ze NAT musi byt znicen.
-
Zdenek (neregistrovaný)> Hlavním problémem NATu je, že narušuje základní princip Internetu, podle nějž jsou všechny počítače jednoznačně adresovány a kdokoli s kýmkoli může komunikovat přímo.
To že PC za NATem nedostane krom vnitřní adresy automaticky i nějaké portforwardy je chyba administrátorů, nikoliv NATu.
portforwardy by šlo alokovat i dynamicky, stačilo by lehce přiohnout DHCP, a do každé P2P aplikace integrovat klienta, aby se čísla portů nemusela nastavovat ručně.
[trolluju ale stejně neodolám]
Každý s každým *PŘÍMO* ??? ..sem netušil že pro Vás "Internet" končí na defaultní gw :) :) :)
> Obludná velikost podsítí (k identifikaci rozhraní slouží 64 bitů, takže podsíť obsahuje 1,8.1019 různých adres) činí skenování prakticky neproveditelným.
Zbytečně dlouhé identifikátory jako IPv6 adresy jsou nepraktické, proto vytvářejí silný tlak na jejich správu adresářovými službami. Protože adresy jsou globální, budou i tyto služby globálně dostupné, takže útočník si je jenom olízne a bude se hákovat jako doposud. Akorát vznikne pár dalších zbytečných standardů, a terabajty zbytečného kódu, kterým zoufalí programátoři tyto standardy budou naplňovat.
> v případě problémů lze zpětně dohledat datové přenosy jednotlivých uživatelů či programů. Ovšem vzhledem k náhodnému přiřazování portů není analýza těchto záznamů zcela triviální.
Proboha kdo bude dělat accounting na vnějším interfacu, když na vnitřním to uvidí všechno hezky roztříděný.
ČLÁNKY DO MAILU