VPN på routeren eller portvideresendelse: hvad vinder?

Routeren afslutter selv VPN, og en gammel videresendelsesregel sender stadig den samme UDP-port til en maskine på LAN’et. Kun én af dem kan være det rigtige endepunkt, og kernen afgør ikke sagen. Destinationsoversættelse omskriver pakken, før den lokale tjeneste bliver spurgt, så VPN-processen venter på trafik, der allerede er sendt et andet sted hen. Opgaven er at afgøre, hvem der ejer porten, og derefter få reglerne til at stemme.

Én port, to hævdede ejere

En VPN-server, der kører inde i routeren, har brug for en indgående tilladelse, der fører til dens egen socket. En destinations-NAT-post for den samme port fører et helt andet sted hen: en LAN-adresse og en videresendelsesbeslutning. Det er forskellige endepunkter med forskellige logfiler og forskellige fejlmåder. Det sædvanlige tegn er, at én adressefamilie virker og den anden ikke, fordi den efterladte post blev skrevet til én familie og aldrig revideret.

Skriv kravet ned, før du redigerer: familie, ekstern adresse, transport, port og det oversatte mål.

Oversættelsen kører før den lokale kontrol

Destinations-NAT ændrer pakkens mål i prerouting-fasen, før kernen vælger mellem lokal levering og videresendelse. Når målet er en LAN-vært, tager pakken videresendelsesvejen. Inputregler for routerens egen socket bliver aldrig konsulteret, og derfor forbliver VPN-loggen tom, mens klienten venter forgæves.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Den rækkefølge er hele mekanismen, og apparatgrænseflader skjuler den bag afkrydsningsfelter uden at ændre den. Destinationens ejer bestemmer stadig, hvilken vej en pakke tager.

Hvis LAN-værten er det tilsigtede endepunkt, er videresendelsen korrekt, og routeren bør ikke også lytte på den port.

Behold én mapping, og fjern den anden

List NAT-posterne for den port og familie, og vælg den, der overlever:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

En TCP-post med samme nummer er irrelevant for en UDP-fejl, og hvis man behandler dem som ét objekt, sletter man den forkerte regel. Når den lokale socket skal vinde, fjerner eller omskriver ejeren af den konfliktende mapping netop den post, og den indgående tilladelse til routerens egen port bliver på plads. Urelaterede videresendelser, administrationsvejen og en kopi af regelsættet bør alle overleve ændringen.

Hvis VPN’et bor på en separat vært, er videresendelsen det rigtige objekt. En tjeneste i en container eller virtuel maskine kan have brug for en offentliggjort port, selv når kassen kaldes routeren, så følg socket’en og dens namespace frem for etiketten på kabinettet.

Bekræft ejeren udefra

Test hver familie for sig, fordi en IPv6-forbindelse, der afsluttes på routeren, intet siger om en IPv4-forbindelse, som en gammel regel omdirigerer. Læs den modtagende tjenestes log for at se, hvilket endepunkt der svarede, og betragt klientens succesmeddelelse som svagt bevis. Der kræves et nyt flow til en meningsfuld test. Send en sonde fra en ekstern vært med nc -zvu 203.0.113.7 1194, og læs vinderens log med journalctl -u openvpn@server -n 20. Routerens lytter logger selv forbindelsen, mens en LAN-vært logger den i sin egen tjeneste.

Forbindelsessporing holder eksisterende flows på deres oprindelige mapping, så en etableret session kan overleve den regel, du netop har rettet.

Når det tilsigtede endepunkt svarer med sine normale identitetskontroller, test en privat ressource bag tunnelen. At nå den ydre lytter er kun første hop; indre routing og applikationsgodkendelse er separate resultater.