Názory k článku Přelez, přeskoč a podlez NAT
-
Harvie (neregistrovaný)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.
-
Petr Andrš (neregistrovaný)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í.
-
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 ;-) -
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. -
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 -
Keson (neregistrovaný)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. -
Clock (neregistrovaný)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. -
phokz (neregistrovaný)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.
-
ventYl (neregistrovaný)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. -
Petrik (neregistrovaný)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. -
Gabo (neregistrovaný)
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/
ČLÁNKY DO MAILU