VPN på routern eller portvidarebefordran: vad vinner?

Routern avslutar VPN själv, och en gammal vidarebefordringsregel skickar fortfarande samma UDP-port till en maskin på LAN. Bara en av dem kan vara den riktiga slutpunkten, och kärnan avgör inte mellan dem. Målöversättningen skriver om paketet innan den lokala tjänsten tillfrågas, så VPN-processen väntar på trafik som redan skickats någon annanstans. Uppgiften är att avgöra vem som äger porten och sedan få reglerna att stämma.

En port, två hävdade ägare

En VPN-server som körs inuti routern behöver ett inkommande tillstånd som leder till dess egen socket. En mål-NAT-post för samma port leder helt någon annanstans: till en LAN-adress och ett vidarebefordringsbeslut. Det är olika slutpunkter med olika loggar och olika felmoduser. Det vanliga tecknet är att en adressfamilj fungerar och den andra inte, eftersom den kvarvarande posten skrevs för en enda familj och aldrig granskades om.

Skriv ner anspråket innan du redigerar: familj, extern adress, transport, port och det översatta målet.

Översättningen går före den lokala kontrollen

Mål-NAT ändrar paketets mål i prerroutingfasen, innan kärnan väljer mellan lokal leverans och vidarebefordran. När målet är en LAN-värd tar paketet vidarebefordringsvägen. Inmatningsregler för routerns egen socket konsulteras aldrig, och därför står VPN-loggen tom medan klienten väntar.

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 ordningen är hela mekanismen, och apparatgränssnitt gömmer den bakom kryssrutor utan att ändra den. Målets ägare avgör fortfarande vilken väg ett paket tar.

Om LAN-värden är den avsedda slutpunkten är vidarebefordran korrekt, och routern bör inte också lyssna på den porten.

Behåll en mappning och ta bort den andra

Lista NAT-posterna för den porten och familjen och välj den som överlever:

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

En TCP-post med samma nummer är irrelevant för ett UDP-fel, och att behandla dem som ett enda objekt leder till att fel regel raderas. När den lokala socketen ska vinna tar ägaren av den motstridiga mappningen bort eller skriver om just den posten, och det inkommande tillståndet för routerns egen port blir kvar. Orelaterade vidarebefordringar, hanteringsvägen och en kopia av regeluppsättningen bör alla överleva ändringen.

Om VPN:et bor på en separat värd är vidarebefordran rätt objekt. En tjänst i en container eller virtuell maskin kan behöva en publicerad port även när lådan kallas routern, så följ socketen och dess namnområde, inte etiketten på höljet.

Bekräfta ägaren utifrån

Testa varje familj separat, eftersom en IPv6-anslutning som slutar på routern inte säger något om en IPv4-anslutning som en gammal regel omdirigerar. Läs loggen för den mottagande tjänsten för att se vilken slutpunkt som svarade, och betrakta klientens framgångsmeddelande som svagt bevis. Ett nytt flöde krävs för ett meningsfullt test. Skicka en sond från en extern värd med nc -zvu 203.0.113.7 1194 och läs vinnarens logg med journalctl -u openvpn@server -n 20. Routerns lyssnare loggar anslutningen själv, medan en LAN-värd loggar den i sin egen tjänst.

Anslutningsspårning håller befintliga flöden på deras ursprungliga mappning, så en etablerad session kan överleva regeln du just rättade.

När den avsedda slutpunkten svarar med sina vanliga identitetskontroller, testa en privat resurs bakom tunneln. Att nå den yttre lyssnaren är bara första hoppet; intern routning och applikationsauktorisering är separata utfall.