Bør du bruke SNAT på en portvideresending til et VPN-subnett?

Videresending av en port til en vert som ligger bak ruterens egen VPN-klient feiler på en måte som ser ut som et brannmurproblem, fordi forespørselen tydelig kommer frem. Tjenesten logger en tilkobling, klienten venter, og ingenting kommer tilbake. Destinasjonsoversettelsen gjorde jobben sin; returpakken er den delen som forsvant. Én selektiv kilde-NAT-regel på ruteren fikser det, og den interessante delen er å avgjøre hvor smal den regelen kan være.

Hvorfor svaret tar en annen vei

En portvideresending skriver om hvor en pakke skal, aldri hvor den kom fra. Internettklientens adresse blir i kildefeltet hele veien gjennom tunnelen, så den eksterne tjenesten ser en fremmed og svarer på den eneste måten den kjenner: gjennom sin egen standardgateway. Den gatewayen er VPN-konsentratoren på den andre siden, som ikke har noen rute tilbake til en vilkårlig offentlig adresse.

Se et opptak på tunnelgrensesnittet, og asymmetrien er tydelig: forespørselspakker ut, ingenting inn. Videresendingskjeden tillot flyten, og tunnelen bar den, så droppet skjer etter at den eksterne verten allerede har valgt en returvei.

En kilderegel som er smal nok til å stole på

Gjør ruteren til kilden som den eksterne verten svarer til. I dette oppsettet er WAN-adressen 203.0.113.24, LAN er 192.168.88.0/24, ruterens tunneladresse er 172.20.5.1, og tjenesten svarer på 172.20.5.40:8443. Regelen nedenfor matcher pakken etter destinasjonsoversettelse, og derfor navngir den den oversatte adressen i stedet for den offentlige. Ingenting i den avhenger av klientens adresse, og det er nettopp poenget.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Hver match i den linjen finnes for å holde omskrivingen lokal for én tjeneste på én tunnel. Fjern grensesnittet eller porten, og du skriver om mer trafikk enn problemet krever, og det er slik en målrettet rettelse blir et mysterium for neste person.

Når en blanket masquerade er det ærlige valget

Hvis ruteren videresender mange tjenester til det samme VPN-subnettet, blir en regel per tjeneste en liste som ingen vedlikeholder. Å maskere alt som forlater tunnelgrensesnittet er enklere og forutsigbart, på bekostning av å skjule den opprinnelige klienten for hver vert på den andre siden. Velg det når loggene der borte ikke brukes til attribusjon; behold den smale regelen når de brukes.

De to alternativene feiler også ulikt. En manglende smal regel ødelegger én tjeneste; en bred masquerade som matcher for mye kan stille skrive om trafikk som allerede virket, inkludert ruterens egne utgående forbindelser.

Sjekk tellerne før du publiserer

Regler som aldri matcher ser identiske ut med regler som virker, helt til du teller pakker. Les tabellen på nytt med byttetellere før noen klient kobler til, og koble deretter til fra et nettverk som ikke er LAN og les den igjen. To avlesninger er det som gjør en gjetning til et faktum. Publiser videresendingen først etter at den andre flytter seg.

iptables -t nat -L POSTROUTING -v -n --line-numbers

En nullteller på kildereglen etter en ekte tilkobling betyr at matchen er feil, vanligvis fordi destinasjonen eller porten ikke matcher pakken etter oversettelse. Hvis telleren stiger, men klienten fortsatt timer ut, er returveien reparert og noe annet dropper svaret, så se neste gang på videresendingspolicyen på den andre siden. Hårnålsadgang innenfra LAN er et eget problem og trenger sin egen regel, ikke en bredere versjon av denne.