Názory k článku
Přelez, přeskoč a podlez NAT

ale fuj...

jednak je hamachi proprietarne riesenie (aj ked je stranka plna opensource bludov) a jednak s vydanim ostrej verzie 1.0 je vysoka pravdepodobnost, ze bude hamachi spoplatnene

Hamachi krom toho zřejmě provozuje veškeré přenosy přes svůj server, tahle "traverza" vypadá spíše, jako P2P spojení, bez nějakého 3tího počítače, myslím, že první grafické rohraní to spraví, ale udělat malinký open source "tracker", což by bylo záslužné, může nějaká nástavba po zadání jména sítě a hesla stáhnout všechny potřebné a aktuální údaje o druhém počítači (IP NATu,...). Celé to pak může fungovat z pohledu uživatele, jako hamachi.

hamachi som nikdy nepouzil, ale co som cital, tak traffic nejde cez server. vraj to bude zahrnute v platenej verzii (ako riesenie pre prepojenia NAT-NAT, kde sa spojenie nepodarilo).

AFAIK hamachi i zde popisovaný nat-traverse fungují podobně, obecně se této metodě říká UDP punching a používá ji třeba i Skype. Komunikace samotná probíhá přímo, je však potřeba prostředníka pro její sestavení, viz předání adres protilehlých natů a portů v článku. Hamachi to řeší prostřednictvím serveru, skype těžko říct jak, u nat-traverse si to musí účastníci zdělit jiným knálem, což je velmi nepraktické, zejména pokud to chce pro přístup k PC za natem, u kterého nikdo není. Jako hříčka zajímavé, reálná uplatnitelnost diskutabilní.

Proc by mi to ten pocitac u ktereho nikdo neni nemohl sdelit na pozadani mailem? (mail, fetchmail, .forward, nebo .procmailrc, nejaky freemail)

Pokud je problemem bezpecnost, tak se po mailech da udelat i nejaka kryptograficky silna autorizace.

No tak jistě, nebo přes IRC, ale celkově mi to přijde jako drbání se leveou nohou za pravým uchem.

Nejlepší je jako servr na sestavení spojení použít nějaký Jabber servr. Jelikož Jabber je univerzální systém (posílání textových zpráv jako u ICQ je jen jednou z jeho možností) s podporou SSH a dobře se pro něj programuje (založen na XML).

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx

Ajaj, ono se to vazne odeslalo. Pouceni - po editaci titulku je treba zmacknout Tab a ne Enter :-/

Zajimavy programek.

1) podobny pristup, vymyslel i Microsoft pro tunelovani IPv6 protokolu skrz NATy a nazval ho Teredo: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx
Bohuzel Microsoft to pojal prilis vedecky, takze se Teredo nerozsirilo.

2) Druha vec je ze ty UDP packety spojuji stdin/stdout a musi se tam krkolomne dotlacit PPP aby ten tunel vubec k necemu byl. Lepsi by bylo pouzit TUN device a vyrobit rovnou sitovy interface. Nebo jeste lepe - rozsirit OpenVPN o moznosti nat-traverse, cimz by clovek ziskal sitovani, sifrovani a nat-traversovani, all-in-one ;-)

Podle me neni treba OpenVPN rozsirovat. Pokud date na obe strany remote, zvolite netradicni port a NEpouzijete nobind, s trochou stesti by se to mohlo chytnout - zalezi na toleranci firewallu, do jake doby akceptuji paket s "odpovedi".
(Nezkousel jsem, jen si tipuji.)

Ano, pomoci OpenVPN to jde bez jakychkoliv uprav. Prakticky vyzkouseno.

Zhodou okolnosti som sa zaoberal technikami preliezania NATov prednedavnom.

Podla toho popisu (a kratkeho nahladu do zdrojaku) je tam jeden predpoklad:

ze aspon jeden z NATov (na svojej verejnej IP) priradi k spojeniu rovnaky UDP port ako ma odosielatel na svojom stroji s privatnou IP. Ak by sa tak nestalo, pocitace na oboch koncoch by sice posielali pakety na spravne stroje, ale na nespravne porty.

Tato podmienka nemusi byt vzdy splnena (ak NAT forwarduje pakety na ziadanom porte inemu stroju).

Obist sa to da tak, ze na zaciatku budu potrebovat oba stroje iny s verejnou IP, "introducera". Ten im bude vediet povedat, aky port ktory si ktory NAT priradil z pohladu "zvonka z internetu". Potom si na tieto porty navzajom mozu posielat pakety a spojit sa. Introducer je potrebny len na zaciatku.

Aj tento alternativny sposob nefunguje s kazdym NATom - treba "cone NAT", ktory pakety pochadzajuce z rovnakeho zdroja (privatna IP, UDP port) pouzije vzdy rovnaky UDP port u seba, nezavisle, na aky ciel (cielova IP, UDP port) idu.

Premyslim jakym zpusobem se introducer dozvi vnejsi port, ktery si NAT priradil. Kdo mu to prozradi?

Spoleha se na to ze NAT zdrojovy port nezmeni. Vetsinou to plati, 100% to ovsem neni. Linux driv (2.2.x?) vsechny porty premapovaval nekam nad 60000, ted uz to nedela. Potreba premapovat porty je jen v pripade ze by dva NATovane pocitace chtely spojeni ze stejneho zdrojoveho portu na stejnou cilovou IP + stejny cilovy port. A to se casto nestava, takze obvykle neni zdrojovy port potreba menit. Tedy pokud vynecham sluzby ktere specificky zdrojovy port vyzaduji (NTP?, nekdy DNS, atd.)

To mi pripomina, ze ten nat-traverse by sa dal vylepsit o synchronizaciu via NTP. Oba stroje, co sa chcu spojit, by si najprv zistili aktualny cas a na hranici napr. 10 sekund by zacali vysielat pakety na nejaky UDP port. Keby sa nepodarilo, po 10 sekundach by port zmenili. Uzivatel by zadal postupnost tychto portov (napr. 3 pary na 3 pokusy).

Ako vylepsenie by mohol ten soft pouzit pseudonahodny generator na generovanie cisel portov, ako seed by sa pouzil prave cas. Uzivatel by potom nemusel explicitne zadavat cisla portov.

Rozpisem to trocha presnejsie.

Oba stroje A, B za rozlicnymi NATmi sa pripoja k introducerovi. Introducer vidi, z akych adries [verejna IP, UDP port] mu prisli UDP pakety. Vie stroju A poslat par [verejna IP, UDP port] stroja B a naopak.

Nasledne stroj A zacne z rovnakeho zdrojoveho UDP portu, ako sa pripajal k introducerovi, posielat UDP pakety na verejnu adresu (NAT) stroja B. B spravi to iste, zacne posielat UDP pakety na verejnu adresu stroja A (ktoru sa dozvedel od introducera).

Naviac takto A a B dokazu zistit, ci nahodou nie su na rovnakej privatnej sieti (za spolocnym NATom) a komunikovat priamo. Je este jeden specialny pripad, kde introducer vidi A aj B za rovnakym NATom, ale za tymto NATom su este skryti za rozlicnymi NATmi (v rozlicnych privatnych sietach).

Introducer sa typicky vyskytuje v p2p sietach ako nejaky supernode.

Dalsi detaily v IETF drafte pojednavajucom o UDP hole punchingu: http://www.brynosaurus.com/pub/net/draft-ford-midcom-p2p-00.txt

STUN (http://www.ietf.org/rfc/rfc3489.txt)
Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs), se hojne pouziva pro traverzovani VoIP. Zjisti typ NATu a vnejsi IP adresu.

OK,
mym problemem je, ze chci mit pristup na ipv6 z meho laptopu, ktery bezi na OpenBSD/NetBSD a je za NAT od poskytovatele EDGE pripojeni. Zkousel jsem freenet6 tspc klienta, ale OpenBSD/NetBSD nepodporuje NAT...

Nejake reseni? Predem diky

Jo, samozrejme, ze NAT dela ISP... Asi nejakej problem s nastavenim...

Jestli neni problem v tom, ze OpenBSD/NetBSD gif device nezvladne hazet ipv6 traffic pres gif do ipv4 upd paketu...

skoda, mozna by pomohl nejaky dalsi tunnel... nejaka sluzba k mani? :)

Openvpn routed/bridged tunel na spřátelenou gateway?

Tahle věcička šlape jako hodinky, s IPSecem jsem skončil, AH oželim

Jestli jsem neco neprehlid, tak ty UDP pakety co po lince chodej muzou dojit v odlisnem poradi a pak se data na lince zkorumpujou. V lepsim pripade se na ppp ztrati data, v horsim se to snad asi aj muze uplne zaseknout.

Protokol UDP totiz nezarucuje poradi doruceni dat.

Ja pouzivam skrz NAT IPv6 a muzu vrele doporucit. Chodi to jak ma. A clovek dostane zadarmo 2^48 verejnych IP adres.

Ahoj Clocku,

muzes ve strucnosti popsat, jak to delas?

Jenom 2^48 ? Ja dostal 2^80 ... ne ze by to nebylo jedno ...

No jedno to neni, na 2^48 si uz neudelam normalni autokonfiguraci pac ta vyzaduje 2^64 prefix. Navic neni nahodou i v nejakym rfc doporuceno pridelovat koncovym uzivatelum /64?

jak mam odpovedet? od ISP mam verejnou adresu, ale sam si ji prekladam :)

Tak pro ucely ankety mas verejnou adresu. Ja jsem na tom stejne.

Zdravim, zajimalo by me, jaky mnozstvi dat se musi v tomto pripade prenaset treba za hodinu. Mame datovy limit :( Dekuju.

Opet zalezi na nastaveni tech NATu, napr. v linuxu je v /proc/sys/net/ipv4/netfilter rada promennych, kterymi se ridi ruzne timeouty. Napriklad ip_conntrack_udp_timeout u me je nastaveno na 30, takze predpokladam ze 1 ping 56bytu za 25sec by mel stacit. Vychazi to cca 189kB prenesenych dat za den.

"Název nat-traverse se skládá ze slov NAT a traverse."
Opravdu? :)

tomuto sa hovori udp hole punching, bezia na tom principe veci ako hamachi a podobne, ma to zopar nevyhod, samotna technologia zarucuje 75% uspesnost pri spojeni, existuju vsak situacie, kedy sa spojit neda.

konkretne hamachi vytvara ponad takyto UDP tunel tun zariadenie a cez vznikly sietovy interface tuneluje veskery traffic, takze TCP nie je problem.

tento skript nie je novinkou, existuje uz tusim nieco okolo roka. rovnako ako technologia udp hole punching. kdesi som cital, ze existuje budto koncept, alebo aj funkcny model TCP hole punchingu, ale tam su vacsie problemy.

To je skutecne tak snadne oblafnout NAT vcetne obvykleho stavoveho firewallu? Predpokladam ze vetsina lidi, co maji doma NAT, maji zaroven stavovy firewall. Nepouziva nahodou linuxovy stavovy firewall nejaky pokrocilejsi testovani UDP packetu, aby odhalil ze ve skutecnosti to nejsou odpovedi, ale ze jsou podstrceny? To se opravdu kouka pouze na cisla portu? Neda se to tedy velmi jednoduse zneuzit?

UDP je bezstavovy protokol, nan stavovy firewall moc dobre nefunguje. Na rozdiel od TCP nema SYN/ACK handshake a nema SEQ/ACK cisla.

Jedine, co firewall/NAT vidi, je, ze z vnutornej siete odisiel na danu IP/UDP port paket a ze z danej IP/UDP portu prichadza paket naspat.

Podstrcit paket pre utocnika je preto jednoduche (musi len vediet ako zvolit IP/cisla portov, napr. ze odpocuje paket pri jeho ceste von do internetu).

Ad. zneuzitie: aplikacia pouzivajuca UDP bud proti tomu musi nieco spravit sama, alebo nechat to tak, jak to je.

> Predpokladam ze vetsina lidi, co maji doma NAT, maji zaroven stavovy firewall.

Tak myslim, ze tento predpoklad IMHO neplati.

Kdyby to ti troubove delali, tak maj mnohem vetsi load a traffic

konečně po delší době článek, který mě zaujal. díky.

Mam v ceste dva routery (prvni pridely neverejnou ip a druhej ji routuje na dalsi neverejny ip). Pude pak spojit takovej pocitac s nakym jinym?

imho ano, princip je porad stejny (tedy pokud samozrejme bude splnen i puvodni predpoklad, ze NAT nezmeni zdrojove pory, jak bylo zmineno vyse)

no nevim, je to neco jineho nez ssh -N a ssh -L ?

V případě ssh tunelu za NAT musíš použít prostředníka z veřejnou ip. Skript zde diskutovaný prostředníka s veřejnou ip nepotřebuje.

chtel bych se pripojovat z win prostredi za NAT k sobe domu rovnez za NAT - je na to nejake reseni?

si delas prdel? :D
vsak o tom je ten navod :D
ale poradim ti. prvy krok co spravis je ze prejdi na nejaky linux :D

Aspoň trochu útechy poskytuje projekt Gitso, zameraný na jednoduché použitie. Pomocou jednoduchého GUI vytvoríte priame spojenie medzi dvomi PC.
http://code.google.com/p/gitso/