Faste UDP-portar kan hoppe over portvideresending, men ikkje kvar NAT

To heimerutarar, ingen vidaresende portar og eit VPN som likevel nokre gonger koplar til. UDP tillèt det, fordi ein brannmur slepp inn ein pakke han kan matche mot ein straum maskinen allereie har starta. Det er eit vilkårleg triks, ikkje ein funksjon, og vilkåra er enkle å nemne når ein veit kva brannmuren samanliknar. Dei er også grunnen til at identiske profilar oppfører seg ulikt på ulike nettverk.

Samanlikninga ein brannmur gjer

Kvar utgåande datagram opprettar ein kortvarig oppføring: kjeldeadresse, kjeldeport, mål adresse, målport. Alt som kjem inn og samsvarar med oppføringa, blir handsama som eit svar og sleppt gjennom. Reglar for innkommande trafikk spelar inga rolle.

Så spørsmålet er ikkje om brannmuren slepp peeren inn. Det er om pakken frå peeren ser ut som svaret oppføringa ventar på. Endrar du eitt felt i den firedelte tuppelen, blir pakken ein framand. Difor kan eit oppsett som verkar bryte saman når berre portnummeret blir endra, og difor kan same porten verke på éin ruter og feile på den neste.

Låser du den lokale kjeldeporten, viser same nummeret seg på begge sider av utvekslinga. Det er heile mekanismen, og han forklarer kvifor trikset er skjørt og ikkje mystisk.

Å låse éin port i kvar ende

Standard UDP-porten til OpenVPN er 1194, og lport set kjeldeporten han sender frå. Lås begge peerane, og kvar parts utgåande tuppel peikar på ein port den andre lyttar på:

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

Dette verkar berre så lenge ingen ruter mellom dei skriv om kjeldeporten. Når pakkar dukkar opp i ein fangst men ingen tunnel reiser seg, er omskrivinga den første mistenkte.

Der tuppelen sluttar å stemme

Ein NAT som mappar per destinasjon gir kvar peer ein annan ekstern port. Adressa peeren din fekk beskjed om å bruke, er ikkje adressa som når han, så den innkommande pakken matchar ingenting og blir kasta i stillheit.

Operatørnivå-omsetjing, stabla NAT og portrandomisering endar alle likt. Det same gjer kvar mellomkasse som skriv om portar og lèt adressene vere.

Straumtransport er verre stilt. Eit TCP-handtrykk blir følgd trinn for trinn, så eit TCP-basert VPN kan ikkje hulast på denne måten i det heile og treng ein lyttar ein stad på vegen.

Vanlegvis feilar éi side først

I praksis oppfører dei to nettverka seg sjeldan likt. Éin ruter kan gi ei føreseieleg mapping medan den andre gir portar per destinasjon, og resultatet er ein konfigurasjon som verkar mellom to heimar og feilar frå eit mobilnett. Rapportar som motseler kvarandre skildrar vanlegvis to ulike par av rutarar. Ingen av forfattarane tek feil, og ingen av resultata kan generaliserast.

Finn ut kva side som sleppte pakken før du rører profilane. Fangstar i begge endar avgjer det i eitt forsøk: datagram som forlèt A og aldri når B betyr at straumen vart skriven om undervegs, medan datagram som når B utan at noko svar kjem tilbake betyr at brannmuren ikkje godtok dei som relaterte.

To peers med offentlege IPv6-adresser går utanom heile problemet. Utan omsetjing er det ingenting å matche, så ein brannmurregel som namngir peerane er nok, og designet sluttar å avhenge av ruteråtferd.

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

Ein vert med offentleg adresse er det pålitelege svaret. Han kan avslutte tunnelen for begge peerane, eller rett og slett hjelpe dei å finne kvar sin noverande eksterne adresse, og begge ordningane verkar same kva NAT-ane gjer. Eit administrert overlay gir same koordinering om policyen tillèt det.

Ingen av desse treng ein deaktivert brannmur. Å slå av vernet for å vinne den direkte sambandet kastar bort grunnen til at det direkte forsøket var attraktivt, og det lèt maskinen stå open gjennom heile testen.

Prøv den direkte ordninga først, og skriv så ned det du såg. NAT-åtferda og fangsten som viste ho er meir verdt enn portparet du enda med å bruke, fordi det neste nettverket blir annleis. OpenVPN 2.6-handboka dokumenterer lport og remote-vala dette avheng av.