Fasta UDP-portar kan hoppa över portvidarebefordran, men inte alla NAT

Två hemmaroutrar, inga vidarebefordrade portar och en VPN som ändå ibland ansluter. UDP tillåter det, eftersom en brandvägg släpper igenom ett paket som den kan matcha mot ett flöde som maskinen redan har startat. Det är ett villkorat trick, inte en funktion, och villkoren är lätta att ange när man vet vad brandväggen jämför. De är också anledningen till att identiska profiler beter sig olika i olika nätverk.

Jämförelsen en brandvägg gör

Varje utgående datagram skapar en kortlivad post: källadress, källport, måladress, målport. Allt som kommer in och stämmer med posten behandlas som ett svar och släpps igenom. Regler för inkommande trafik spelar ingen roll.

Frågan är alltså inte om brandväggen släpper in peeren. Det är om peerns paket ser ut som svaret posten väntar på. Ändra ett fält i den fyrdelade tuppeln och paketet blir en främling. Därför kan en fungerande uppsättning gå sönder när bara portnumret ändras, och därför kan samma port fungera på en router och misslyckas på nästa.

Lås den lokala källporten, och samma nummer dyker upp på båda sidor av utbytet. Det är hela mekanismen, och den förklarar varför tricket är skört och inte mystiskt.

Att låsa en port i varje ände

OpenVPNs standard-UDP-port är 1194, och lport ställer in källporten den skickar från. Lås båda peerarna och varje parts utgående tuppel pekar på en port som den andra lyssnar på:

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

Det fungerar bara så länge ingen router mellan dem skriver om källporten. När paket dyker upp i en fångst men ingen tunnel reser sig är omskrivningen den första misstänkta.

Där tuppeln slutar stämma

En NAT som mappar per destination ger varje peer en annan extern port. Adressen som din peer fick veta att använda är inte adressen som når den, så det inkommande paketet matchar ingenting och kastas tyst.

Operatörsnivå-översättning, staplad NAT och portrandomisering slutar alla likadant. Det gör också vilken mellanbox som helst som skriver om portar och låter adresserna vara.

Strömtransport är sämre ställt. Ett TCP-handskakning följs steg för steg, så en TCP-baserad VPN kan inte hålas på det här sättet alls och behöver en lyssnare någonstans på vägen.

Vanligtvis misslyckas en sida först

I praktiken beter sig de två nätverken sällan likadant. En router kan ge en förutsägbar mappning medan den andra ger portar per destination, och resultatet är en konfiguration som fungerar mellan två hem och misslyckas från ett mobilnät. Rapporter som motsäger varandra beskriver oftast två olika par av routrar. Ingen av författarna har fel, och inget av resultaten kan generaliseras.

Ta reda på vilken sida som släppte paketet innan du rör profilerna. Fångster i båda ändar avgör det i ett försök: datagram som lämnar A och aldrig når B betyder att flödet skrevs om under vägen, medan datagram som når B utan att något svar kommer tillbaka betyder att brandväggen inte accepterade dem som relaterade.

Två peers med offentliga IPv6-adresser går runt hela problemet. Utan översättning finns inget att matcha, så en brandväggsregel som namnger peerarna räcker och designen slutar bero på routerbeteende.

När man ska sluta försöka

En värd med offentlig adress är det pålitliga svaret. Den kan avsluta tunneln för båda peerarna, eller helt enkelt hjälpa dem att hitta varandras nuvarande externa adress, och båda arrangemangen fungerar vad NATarna än gör. Ett hanterat överlägg ger samma samordning om policyn tillåter det.

Inget av detta behöver en avstängd brandvägg. Att stänga av skyddet för att vinna den direkta anslutningen kastar bort skälet till att det direkta försöket var attraktivt, och det lämnar maskinen öppen under hela testet.

Prova det direkta arrangemanget först och skriv sedan ned vad du såg. NAT-beteendet och fångsten som visade det är värda mer än det portpar du till slut använde, eftersom nästa nätverk blir annorlunda. OpenVPN 2.6-handboken dokumenterar lport och de remote-alternativ som detta beror på.