NAT

[Jenik]

1000
rsk.klfree.net/mailman/listinfo/kladno>,
	<mailto:kladno-request na klfree.net?subject=subscribe>
X-List-Received-Date: Wed, 21 Jan 2004 11:40:01 -0000



ahoj, nebudu odpovidat na technickou polemiku, ale spise reknu strucne proc.

No na tom ze nebudeme akceptovat NAT jsme se dohodly kdyz se vytvarel 
provozni rad.

Asi nejvetsi duvod byl ten aby nedoslo k sireni sitoveho pripojeni 
nacerno dale za jednoho registrovaneho uzivatele.

Nat neni potreba , mame dost ipadres. A treba casem prejdeme na IPV6.

Proc delat nat ? Ja nevidim duvod proc. Klfree dela nat, protoze neni 
dostatek verejnych IPV4 adres pro cely rozzsah site. Kdyby bylo dost 
IPV4 adres tak myslim ze zmizi NAT a ipadresy na cele siti v rozsahu 
neverejnych IP , pr: 192.168.0.0/16 atd..

Mozna by bylo dobre vase reakce prehodnotit , treba na valne hromade s 
pripravou vteto diskuzi.

Ja bych chtel vedet, proc treba ty tu techniku chces vyuzivat :).

Ktomu ICMP, na nekterych zarizenich to opravdu nejde, tam se neda nic 
delat. Avsak tento bod take splnujes, protoze ti odpovida alespon na 
jedne strane :).

myslim ze milanK mozna napise, pokud najde nejaky cas, a vysvetli jeste 
nejak technicky, ci zareaguje na tve otazky.

jenik


Svatopluk Dedic napsal(a):
> Jenik wrote:
> [ snip cca 60 radku ktere vysvetluji NAT ale nevysvetluji proc ne NAT ]
> 
>> iniciovala, jak byly zme(ne(ny porty a pod.) a tyto informace si pamatuje
>> pouze ne(jakou dobu. Pokud do této doby neprojde pr(es router žádný paket
>> patr(ící do toho konkrétního pr(ekladu, router pr(eklad zapomene a port
>> uvolní. Tato doba je u protokolu TCP ne(kolik minut, u UDP jsou to
>> obvykle desítky sekund. I toto mu*že vadit, když pošleme do Internetu
>> dotaz a odpove(d( nestihne pr(ijít pr(ed vypršením c(asového limitu, 
>> tak se
>> informace o pr(ekladu odstraní z opožde(ná odpove(d( se ignoruje, 
>> protože se
>> neví, jakému vnitr(nímu poc(ítac(i patr(í.
> 
> 
> Ano, to je velmi podstatne; nicmene mezi klFree a Internetem je NAT / 
> transparentni proxy ktery prave takoveto problemy zpusobuje (muze 
> zpusobovat). Mimochodem - skutecne se mapovani zapomina u *spojovaneho* 
> a otevreneho TCP kanalu ?
> 
> [snip 20 radek, ktere vysvetluji pouziti globalniho NAT pro pripojeni 
> klFree do Inetu]
> [snip 10 radek o port fowardovani]
> [snip 18 radek vysvetlujici NAT 1:1]
> 
> 
>> NAT má v podstate( dve( výhody. První je využití jediné adresy mnoha
>> poc(ítac(i. Protože máme uvnitr( kLfREE dostatek never(ejných IP 
>> adres, není
>> jimi potr(eba takto šetr(it. Druhou výhodou je vedlejší ochrana 
>> zpu*sobená
> 
> OK, toto je vysvetleni _nepotrebnosti_ NATu, nikoliv skodlivosti pro 
> provoz site.
> 
>> Na druhou stranu je tu plno nevýhod NATu, které me( pr(ivedly k jeho
>> zákazu. Poc(ítac(, který se pr(es NAT napojuje ven, nedokáže odhadnout, z
>> jaké adresy a portu jeho spojení ve skutec(nosti pu*jde
>> (adresa by ješte( odhadnout šla, port nikoliv). To je velký problém u
>> služeb, které si tyto údaje pr(edávají. Dále není možno s poc(ítac(em za
> 
> Techniky pro vyreseni tohoto problemu uz jsou znamy:
> - SOCKS 4/5 proxy (ma ji klFree?)
> - pasivni prenosy pro FTP
> 
> Zminil bych jeste jeden problem:
> - nespravna identifikace klientske stanice na strane serveru mimo NAT 
> domenu. Ten totiz vidi stroj, ktery provozuje NAT.
> 
>> NATem navázat komunikaci, velký problém internetové telefonie. Dalším
> 
> 
> [poznamka: termin "klFree NAT" se vztahuje k dnat.klfree.net, pres ktery 
> je (vnitrni) sit klFree pripojena k Internetu a ktery provozuje NAT 
> "klasicke forme" - skryvani adresoveho prostoru vnitrni site klFree]
> 
> Kolik lidi nyni pouziva internetovou telefonii - a jak se tento problem 
> resi vyhozenim NATu uvnitr klFree, kdyz je NAT na vstupu do klFree ?
> 
>> problémem jsou c(asové limity, které vynutily zásah do služeb a
>> zvyšují tok dat (je potr(eba obc(as posílat bezvýznamné pakety jen proto,
>> aby se oddálilo vypršení c(asovac(e). Ne(které problémy NATu nejsou 
>> dodnes
> 
> N/A - skutecne se to deje ? V pripade transparentni proxy klient ani 
> nevi (nema vedet) ze tam
1000
 nejaky NAT je (a tudiz nema potrebu pakety 
> vysilat)
> 
> Ad nefunkcnost sluzeb za "lokalnim" NATem:
> Vzhledem k tomu ze _vsechny_ pocitace klFree jsou za "klFree NATem", 
> budto sluzba funguje s jednim NAT (a pak proc ne s vice retezenymi), 
> nebo se stejne musi podniknout specialni kroky i v pripade absence NAT 
> _uvnitr_ klFree.
> Stejnou techniku forwardovani portu jako snat.klfree.net muze pouzit i 
> jedinec ktery si chce zprovoznit NAT u sebe.  Pocet prepisu IP headeru 
> neni prece nijak omezeny. Kdyz zvladne NAT, mel by zvladnout i tohle.
> 
> Resume:
> - sluzby budto nejsou funkcni ani bez lokalnich NATu (kvuli klFree 
> NATu), nebo
> - musi byt podpora v klientskych programech (passive ftp, socks, ...)
> - se musi pouzit specialni opatreni na NAT (port fwd), ktere lze retezit
> 
> Takze - kde NATy zpusobuji problem ? Zbyva celkem logicka "ochrana 
> standardniho uzivatele" - ale ten si snad nebude porizovat svuj soukromy 
> firewall, ne ?
> 
> Pojdme se pripadne soustredit ne na to "co NAT je a jak se pouziva", ale 
> "proc nema NAT byt uvnitr klFree"; v predchozich e-mailech vicemene 
> postradam realne duvody krome jedineho ktery nebyl vyrcen: monitorovani 
> rozsahu, stavu site (coz by odpovidalo pozadavku na ICMP protokol na 
> vsech zarizenich) a adresne monitorovani datovych toku (napr. odchyt 
> extremnich stahovacu).
> Nechci argumentovat za nebo proti NATu, skutecne mne zajimaji duvody 
> proc - doposud uvadena zduvodneni jsou, v pritomnosti dnat.klfree.net 
> mirne zavadejici (daji se aplikovat take na nej).
> 
> [off-topic]
> Pozadavek na ICMP a ping se ukazal (pro mne prekvapive) docela striktni 
> -- napriklad muj DLink 900+ AP sice akceptuje z vnitrniho ethernet 
> interface ping, ale z wireless interface na nej zvysoka kasle, stejne 
> jako na http protokol (kterym se spravuje). Nastavit to samozrejme nejde.
> 
> Hezky den,
> -Svata
>