Faste UDP-porter kan hoppe over portvideresending, men ikke enhver NAT

To hjemmerutere, ingen videresendte porter og en VPN som likevel noen ganger kobler til. UDP tillater det, fordi en brannmur slipper inn en pakke den kan matche mot en strøm maskinen allerede har startet. Det er et betinget triks, ikke en funksjon, og betingelsene er enkle å angi når man vet hva brannmuren sammenligner. De er også grunnen til at identiske profiler oppfører seg ulikt på forskjellige nettverk.

Sammenligningen en brannmur gjør

Hver utgående datagram oppretter en kortvarig oppføring: kildeadresse, kildeport, måladresse, målport. Alt som kommer inn og samsvarer med oppføringen, behandles som et svar og slippes gjennom. Regler for innkommende trafikk spiller ingen rolle.

Så spørsmålet er ikke om brannmuren slipper peeren inn. Det er om pakken fra peeren ser ut som svaret oppføringen venter på. Endre ett felt i den firedelte tuppelen, og pakken blir en fremmed. Derfor kan et oppsett som virker bryte sammen når bare portnummeret endres, og derfor kan samme port virke på én ruter og feile på den neste.

Låser du den lokale kildeporten, vises samme nummer på begge sider av utvekslingen. Det er hele mekanismen, og den forklarer hvorfor trikset er skjørt og ikke mystisk.

Å låse én port i hver ende

OpenVPNs standard UDP-port er 1194, og lport setter kildeporten den sender fra. Lås begge peerne, og hver parts utgående tuppel peker på en port den andre lytter på:

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

Dette virker bare så lenge ingen ruter mellom dem skriver om kildeporten. Når pakker dukker opp i en fangst men ingen tunnel reiser seg, er omskrivingen den første mistenkte.

Der tuppelen slutter å stemme

En NAT som mapper per destinasjon gir hver peer en annen ekstern port. Adressen peeren din fikk beskjed om å bruke, er ikke adressen som når den, så den innkommende pakken matcher ingenting og forkastes i stillhet.

Operatørnivå-oversettelse, stablet NAT og portrandomisering ender alle likt. Det samme gjør enhver mellomkasse som skriver om porter og lar adressene være.

Strømtransport er verre stilt. Et TCP-håndtrykk følges trinn for trinn, så en TCP-basert VPN kan ikke hules på denne måten i det hele tatt og trenger en lytter et sted på veien.

Vanligvis feiler én side først

I praksis oppfører de to nettverkene seg sjelden likt. Én ruter kan gi en forutsigbar mapping mens den andre gir porter per destinasjon, og resultatet er en konfigurasjon som virker mellom to hjem og feiler fra et mobilnett. Rapporter som motsier hverandre beskriver vanligvis to forskjellige par av rutere. Ingen av forfatterne tar feil, og ingen av resultatene kan generaliseres.

Finn ut hvilken side som droppet pakken før du rører profilene. Fangster i begge ender avgjør det i ett forsøk: datagrammer som forlater A og aldri når B betyr at strømmen ble skrevet om underveis, mens datagrammer som når B uten at noe svar kommer tilbake betyr at brannmuren ikke godtok dem som relaterte.

To peers med offentlige IPv6-adresser går utenom hele problemet. Uten oversettelse er det ingenting å matche, så en brannmurregel som navngir peerne er nok, og designet slutter å avhenge av ruteratferd.

Når man bør slutte å prøve

En vert med offentlig adresse er det pålitelige svaret. Den kan avslutte tunnelen for begge peerne, eller rett og slett hjelpe dem med å finne hverandres nåværende eksterne adresse, og begge ordningene virker uansett hva NAT-ene gjør. Et administrert overlay gir samme koordinering hvis policyen tillater det.

Ingen av disse trenger en deaktivert brannmur. Å slå av beskyttelsen for å vinne den direkte forbindelsen kaster bort grunnen til at det direkte forsøket var attraktivt, og det lar maskinen stå åpen gjennom hele testen.

Prøv den direkte ordningen først, og skriv så ned det du så. NAT-atferden og fangsten som viste den er mer verdt enn portparet du endte med å bruke, fordi det neste nettverket blir annerledes. OpenVPN 2.6-håndboken dokumenterer lport og remote-valgene dette avhenger av.