Vlákno názorů k článku Přelez, přeskoč a podlez NAT od anonym - Zhodou okolnosti som sa zaoberal technikami preliezania NATov...

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