VPN på ruteren eller portvideresending: hva vinner?

Ruteren avslutter VPN selv, og en gammel videresendingsregel sender fortsatt samme UDP-port til en maskin på LAN-et. Bare én av dem kan være det egentlige endepunktet, og kjernen avgjør ikke mellom dem. Måloversettelsen skriver om pakken før den lokale tjenesten blir spurt, så VPN-prosessen venter på trafikk som allerede er sendt et annet sted. Oppgaven er å avgjøre hvem som eier porten, og deretter få reglene til å stemme.

Én port, to hevdede eiere

En VPN-server som kjører inne i ruteren trenger en innkommende tillatelse som fører til dens egen socket. En mål-NAT-oppføring for samme port fører helt et annet sted hen: en LAN-adresse og en videresendingsbeslutning. Dette er forskjellige endepunkter med forskjellige logger og forskjellige feilmoduser. Det vanlige tegnet er at én adressefamilie virker og den andre ikke, fordi den gjenværende oppføringen ble skrevet for én familie og aldri gjennomgått på nytt.

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

Oversettelsen går før den lokale kontrollen

Mål-NAT endrer pakkens mål i forrutingsfasen, før kjernen velger mellom lokal levering og videresending. Så snart målet er en LAN-vert, tar pakken videresendingsveien. Inndataregler for ruterens egen socket blir aldri konsultert, og derfor står VPN-loggen tom mens klienten venter forgjeves.

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 rekkefølgen er hele mekanismen, og apparatgrensesnitt skjuler den bak avkrysningsbokser uten å endre den. Målets eier bestemmer fortsatt hvilken vei en pakke tar.

Hvis LAN-verten er det tiltenkte endepunktet, er videresendingen riktig, og ruteren bør ikke også lytte på den porten.

Behold én tilordning og fjern den andre

List NAT-oppføringene for den porten og familien, og velg den som overlever:

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

En TCP-oppføring med samme nummer er irrelevant for en UDP-feil, og å behandle dem som ett objekt fører til at feil regel slettes. Når den lokale socketen skal vinne, fjerner eller skriver eieren av den motstridende tilordningen om nettopp den oppføringen, og den innkommende tillatelsen for ruterens egen port blir stående. Urelaterte videresendinger, administrasjonsveien og en kopi av regelsettet bør alle overleve endringen.

Hvis VPN-et bor på en separat vert, er videresendingen det riktige objektet. En tjeneste i en container eller virtuell maskin kan trenge en publisert port selv når boksen kalles ruteren, så følg socketen og navnerommet dens, ikke etiketten på kabinettet.

Bekreft eieren utenfra

Test hver familie for seg, fordi en IPv6-forbindelse som avsluttes på ruteren, ikke sier noe om en IPv4-forbindelse som en gammel regel omdirigerer. Les loggen til tjenesten som mottar, for å se hvilket endepunkt som svarte, og betrakt klientens suksessmelding som svakt bevis. Det kreves en ny flyt for en meningsfull test. Send en sonde fra en ekstern vert med nc -zvu 203.0.113.7 1194 og les vinnerens logg med journalctl -u openvpn@server -n 20. Ruterens lytter logger forbindelsen selv, mens en LAN-vert logger den i sin egen tjeneste.

Tilkoblingssporing holder eksisterende flyter på deres opprinnelige tilordning, så en etablert økt kan overleve regelen du nettopp rettet.

Når det tiltenkte endepunktet svarer med sine vanlige identitetskontroller, test en privat ressurs bak tunnelen. Å nå den ytre lytteren er bare første hopp; indre ruting og applikasjonsautorisasjon er separate utfall.