VPN på rutaren eller portvideresending: kva vinn?

Rutaren avsluttar VPN sjølv, og ein gammal videresendingsregel sender framleis same UDP-port til ein maskin på LAN-et. Berre éin av dei kan vere det eigentlege endepunktet, og kjernen avgjer ikkje mellom dei. Målomsetjinga skriv om pakken før den lokale tenesta vert spurd, så VPN-prosessen ventar på trafikk som alt er sendt ein annan stad. Oppgåva er å avgjere kven som eig porten, og deretter få reglane til å stemme.

Éin port, to hevda eigarar

Ein VPN-tenar som køyrer inne i rutaren treng eit innkomande løyve som fører til sin eigen socket. Ei mål-NAT-oppføring for same port fører heilt ein annan stad: til ei LAN-adresse og eit videresendingsvedtak. Dette er ulike endepunkt med ulike loggar og ulike feilmåtar. Det vanlege teiknet er at éin adressefamilie verkar og den andre ikkje, fordi den attverande oppføringa vart skriven for éin familie og aldri gjennomgått på nytt.

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

Omsetjinga går før den lokale kontrollen

Mål-NAT endrar målet til pakken i førrutefasen, før kjernen vel mellom lokal levering og videresending. Så snart målet er ein LAN-vert, tek pakken videresendingsvegen. Inndatareglar for rutaren sin eigen socket vert aldri konsulterte, og difor står VPN-loggen tom medan klienten ventar 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 rekkjefølgja er heile mekanismen, og apparatgrensesnitt skjuler han bak avkryssingsboksar utan å endre han. Eigaren av målet avgjer framleis kva veg ein pakke tek.

Viss LAN-verten er det tiltenkte endepunktet, er videresendinga rett, og rutaren bør ikkje også lytte på den porten.

Hald éi tilordning og fjern den andre

List NAT-oppføringane for den porten og familien, og vel den som overlever:

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

Ei TCP-oppføring med same nummer er irrelevant for ein UDP-feil, og å handsame dei som eitt objekt fører til at feil regel vert sletta. Når den lokale socketen skal vinne, fjernar eller skriv eigaren av den motstridande tilordninga om nettopp den oppføringa, og det innkomande løyvet for rutaren sin eigen port blir ståande. Urelaterte videresendingar, administrasjonsvegen og ein kopi av regelsettet bør alle overleve endringa.

Viss VPN-et bur på ein separat vert, er videresendinga det rette objektet. Ei teneste i ein container eller virtuell maskin kan trenge ein publisert port sjølv når boksen vert kalla rutaren, så følg socketen og namnerommet hans, ikkje etiketten på kabinettet.

Stadfest eigaren utanfrå

Test kvar familie for seg, fordi ei IPv6-tilkopling som sluttar på rutaren ikkje seier noko om ei IPv4-tilkopling som ein gammal regel omdirigerer. Les loggen til tenesta som tek imot, for å sjå kva endepunkt som svara, og handsame suksessmeldinga til klienten som svakt prov. Det krevst ein ny flyt for ein meiningsfull test. Send ein sonde frå ein ekstern vert med nc -zvu 203.0.113.7 1194 og les loggen til vinnaren med journalctl -u openvpn@server -n 20. Lyttaren til rutaren loggar tilkoplinga sjølv, medan ein LAN-vert loggar ho i si eiga teneste.

Tilkoplingssporing held eksisterande flytar på den opphavlege tilordninga si, så ei etablert økt kan overleve regelen du nettopp retta.

Når det tiltenkte endepunktet svarar med dei vanlege identitetskontrollane sine, test ein privat ressurs bak tunnelen. Å nå den ytre lyttaren er berre første hopp; indre ruting og applikasjonsautorisasjon er separate utfall.