Pevné UDP porty mohou obejít přesměrování portů, ale ne každý NAT

Dva domácí routery, žádné přesměrované porty a VPN, která se někdy přesto připojí. UDP to umožňuje, protože firewall propustí paket, který dokáže spárovat s tokem, jenž stroj už zahájil. Je to podmíněný trik, ne funkce, a podmínky se dají snadno vyjmenovat, jakmile víte, co firewall porovnává. Jsou také důvodem, proč se stejné profily chovají na různých sítích odlišně.

Porovnání, které firewall provádí

Každý odchozí datagram vytvoří krátkodobou položku: zdrojová adresa, zdrojový port, cílová adresa, cílový port. Cokoli přijde a odpovídá položce, považuje se za odpověď a projde. Pravidla pro příchozí provoz do toho nevstupují.

Otázka tedy není, zda firewall pustí partnera dovnitř. Jde o to, zda paket partnera vypadá jako odpověď, na kterou položka čeká. Změňte jedno pole této čtyřdílné n-tice a paket se stane cizincem. Proto se fungující nastavení může rozbít, když se změní jen číslo portu, a proto stejný port může na jednom routeru fungovat a na dalším selhat.

Zafixujte místní zdrojový port a stejné číslo se objeví na obou stranách výměny. To je celý mechanismus a vysvětluje, proč je trik křehký, a ne záhadný.

Zafixování jednoho portu na každém konci

Výchozí UDP port OpenVPN je 1194 a lport nastavuje zdrojový port, ze kterého se odesílá. Zafixujte oba partnery a odchozí n-tice každého bude ukazovat na port, na kterém ten druhý naslouchá:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

To funguje jen dokud žádný router mezi nimi nepřepisuje zdrojový port. Když se pakety objeví v zachytávce, ale tunel nevznikne, je přepis prvním podezřelým.

Kde se n-tice přestane shodovat

NAT, který mapuje podle cíle, dá každému partnerovi jiný vnější port. Adresa, kterou partnerovi řekli, aby použil, není adresa, která k němu dorazí, takže příchozí paket ničemu neodpovídá a je tiše zahozen.

Překlad u operátora, vrstvený NAT i randomizace portů končí stejně. Stejně tak jakýkoli prostředník, který přepisuje porty a adresy nechává být.

U proudových transportů je to horší. TCP handshake se sleduje krok za krokem, takže VPN postavená na TCP se takhle nedá probourat vůbec a potřebuje posluchače někde na cestě.

Obvykle selže nejdřív jedna strana

V praxi se obě sítě chovají málokdy stejně. Jeden router může přidělovat předvídatelné mapování, zatímco druhý přiděluje porty podle cíle, a výsledkem je konfigurace, která funguje mezi dvěma domovy a selže z mobilní sítě. Protichůdné zprávy obvykle popisují dvě různé dvojice routerů. Ani jeden autor se nemýlí a ani jeden výsledek se nezobecňuje.

Než se dotknete profilů, zjistěte, která strana paket zahodila. Zachytávky na obou koncích to vyřeší na jeden pokus: datagramy, které opustí A a nikdy nedorazí do B, znamenají, že tok byl po cestě přepsán, zatímco datagramy, které dorazí do B a žádná odpověď se nevrací, znamenají, že je firewall nepřijal jako související.

Dva partneři s veřejnými adresami IPv6 celý problém obejdou. Bez překladu není co párovat, takže stačí pravidlo firewallu, které partnery pojmenuje, a návrh přestane záviset na chování routeru.

Kdy přestat zkoušet

Hostitel s veřejnou adresou je spolehlivá odpověď. Může ukončit tunel pro oba partnery, nebo jim prostě pomoci zjistit aktuální vnější adresu toho druhého, a obě uspořádání fungují bez ohledu na to, co NAT dělá. Spravovaný overlay poskytuje stejnou koordinaci, pokud to politika dovolí.

Nic z toho nepotřebuje vypnutý firewall. Vypnout ochranu, abychom vyhráli přímé spojení, zahazuje důvod, proč byl přímý pokus lákavý, a nechává stroj otevřený po celou dobu testu.

Zkuste nejdřív přímé uspořádání a pak si zapište, co jste viděli. Chování NAT a zachytávka, která ho ukázala, mají větší cenu než dvojice portů, kterou jste nakonec použili, protože příští síť bude jiná. manuál OpenVPN 2.6 dokumentuje lport a volby remote, na kterých to závisí.