NAT

[Svatopluk Dedic]

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
1000
í 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 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