Názory k článku
NAT444 aneb ve dvou se to lépe NATne

Řekl bych, že tohle řešení používá každá menší síť odjakživa ... ono se blbě rozsíťovává několik tisíc adres na X stovek podsítí.

Akorát by mě zajímalo, jestli se dá sehnat nějaké "zařízení", které to udělá za mě při rychlostech v gigabitech, které už jsou přeci jenom pro PC routery trochu problém. A nebude to stát stejně, jako CRS od Cisca ...

Otázkou je, jak budou postupovat menší sítě ve chvíli, kdy ani jim upstream provider nenabídne další veřejné IP, ale jen blok RFC1918 adres. Přijde NAT4444?

Myslel jsem menší, ne mrňavé :-) Ale ono už je fuk, kdo nedá adresy, jestli ripe nebo isp ... I tak se mi zatmělo před očima.
Čistě teoreticky, linuxový SNAT dokáže využít všech 65536 portů, alespoň myslím. I počítač čuně potřebuje maximálně pár set konexí. Takže za pár adres lze schovat opravdu spoustu uživatelů. Jde jenom o to, mít HW který nelehne při prvním přetížení a zvládne několik gigabit (i když asi lepší parametr by byl pps a počet nových konexí za vteřinu).

Ale takovy zarizeni samozrejme existujou.. Napr: http://www.comsource.cz/srx1400

čistě pro informaci ... co to stojí? přibližně ...

Někteří uživatelé dokonce na tomto řešení (NA444) trvají i když mají možnost získat prakticky neomezený počet neveřejných adres za prvním NATem NAT44 ! Argumentují většinou bezpečností a jednoduchostí připojení dalších PC.

Toto je zkušenost z komunitní sítě typu CZfree, která sice nemá dost veřejných IP pro všechny, ale snaží se vnitřní NAT další nezavádět.

Další věcí je, že hodně typů wifi AP ani jiný režim než NAT neumí a pokud mají pouze jeden eth port, tak není jiné volby než je provozovat jako další NAT a tedy celkově jako NAT444.

Protoze ono je to skutecne pohodlne. Prijdu s novym pocitacem, pripojim se k wifi, zadam heslo a ono to funguje. V pripade kdy nemam zanatovano, musim do administrace, zjistovat mac adresu pocitace, prepisovat do administrace, cekat az se to probubla... Dalsi vec je to, ze ten nat jako prvni obrana proti tomu, aby mi soused tiskl na moji tiskarne urcite postaci. Takze pro koncoveho uzivatele jednou krabickou za par kacek ziska jakousi ochranu, rozvede si internet do vsech pocitacu, nemusi nikdy nic dal nastavovat. To mi prijde jako fajn reseni, ne?

Do tý doby než, soused udělá "route add TVOJE_SIT gw TVOJE_BRANA" :) Miluju takový sousedy, aspoň mi nechodí RIAA pamflety a obálky s modrým pruhem :)

Tak to by mě fakt zajímalo jak by toto mohl udělat :).

Slusne nastaveny router by to mel automaticky zahodit

Právě proto tohle bývá jako výchozí nastavení.

Většina těch malých krabiček právě má soustu věcích zakázaných a vypnutých. Přihlášení do administrace z WAN nebo WLAN - vypnuto , SMB z WAN - vypnuto atd... Firewall automaticky zapnut atd...

Bohužel si asi dostatečně neuvědomujete že tito lidé tvoří nějaký 75% možná i víc trhu s komponenty pro nefiremní klientelu.

Takže klidně se tu můžete rozepisovat o tom jak doma potřebujete VPN a přímí přístup, NAS a VoIP atd.... ale jste zástupcem minority.

Furt jsem se nedozvěděl jak bych se mohl z WAN takového routeru dostat na LAN, tam se proroutovat přes jeho GW a vydávat se pod jeho IP WAN. Co já vím, tak i ta nejhloupější SOHO krabička má NAT s jednoduchým firewallem který neumožní source routing.

Zatím jsem nepotkal "krabičku za pár Kč", kde by byl Firewall zapnutý.

A stále bych rád věděl, která volba ve výchozím nastavení zabrání tomu, co popsal? IMHO jakmile prolomí šifrování (což může být lehký, náročný, nebo i nerealizovatelný úkol), tak si už může dělat co chce.

Nedavno (loni) jsem vybiral "krabicku za par Kc" a vsechny mely v defaultu firewall zapnuty. V nekterych pripadech to bylo "ponekud" kontraproduktivni, protoze CPU nestihalo a dochazelo k vyraznemu omezeni datoveho toku (rozdil cca 30%)

s WPA2 asi těžko...

To bude veselé, až přes takovýto ISP-NAT se dva lidi pokusí dostat přes VPN (PPTP) do stejné firemní sítě, a ono to pojede jednou tomu, podruhé tomu druhému nebo ani jednomu, ale nikdy oběma současně. Protože GRE protokol je mezi IP adresami, žádné porty jednotlivá spojení nerozlišují.

A to je chyba NATu, anebo špatně vymyšleného protokolu?

To je jasná chyba NATu.
Internet není jen TCP a UDP.

Nektery implementace NATu se to snazi obchazet pomoci sledovani Sequence Number tech GRE paketu, takze pro male (ale opravdu hodne male) mnozstvi uzivatelu to funguje - ikdyz za cenu vyrazneho zvyseni naroku na HW toho NATu. V Linuxu se to resi napriklad modulem nf_nat_proto_gre.

Bohuzel snaha o zavadeni veci typu nat444 jen opet odrazi v jak zalostnem stavu se IPv6 nachazi. Byt uz v soucasne dobe resi operator problem nedostatkem adres, tak mu IPv6 nijak nepomuze a chte nechte musi zvazovat nasazeni dalsi vrstvy NATu. V okamziku kdy tyto technologie uz budou nasazeny, tak opet pomine duvod zavadeni IPv6, resp. operator tezko bude financovat rozmar v podobe IPv6, kdyz nebude mit objektivni problem k reseni.

Vypada to, ze IPv6 zatim propadlo u kazde zkousky, ktere kdy bylo vystaveno. Sam jsem zvedavy na stredecni "maturitu". Osobne bych to odhadoval spise na ostudu a dalsi reparat. Samozrejme, ze prispechaji "rodice", kteri se budou snazit vec bagatelizovat, ze to vlastne tak zle neni a ze "mlady" se to do priste urcite douci :-) Aby se to ovsem nedoucoval tak dlouho, ze uz to nikoho zajimat.

Maturita ve stredu? IPv6? Ale ne :-)

Ve stredu si chteji nekteri poskytovatele obsahu otestovat, jak jsou na tom poskytovatele infrastruktury. Co se dozvedi, je celkem jasne.

Můj µTorrent teredo adresy přímo miluje. Bude teredo fungovat i za tímto typem natu?

Blbe, ale bude. Samo cim vic NATu zasebou, tim vic pruserovy to je a tim min aplikaci funguje.

Kdyby se takové úsilí raději věnovalo implementaci IPv6. :-(