Bør du anvende SNAT på en portvideresendelse til et VPN-undernet?

Videresendelse af en port til en vært, der ligger bag routerens egen VPN-klient, fejler på en måde, der ligner et firewallproblem, fordi anmodningen tydeligt ankommer. Tjenesten logger en forbindelse, klienten venter, og der kommer intet tilbage. Destinationsoversættelsen gjorde sit arbejde; returpakken er den del, der forsvandt. Én selektiv kilde-NAT-regel på routeren retter det, og det interessante er at beslutte, hvor snæver den regel kan være.

Hvorfor svaret tager en anden vej

En portvideresendelse omskriver, hvor en pakke skal hen, aldrig hvor den kom fra. Internetklientens adresse bliver i kildefeltet hele vejen gennem tunnelen, så den eksterne tjeneste ser en fremmed og svarer på den eneste måde, den kender: gennem sin egen standardgateway. Den gateway er VPN-koncentratoren på den anden side, som ikke har nogen rute tilbage til en vilkårlig offentlig adresse.

Se en optagelse på tunnelinterfacet, og asymmetrien er tydelig: anmodningspakker ud, intet ind. Videresendelseskæden tillod flowet, og tunnelen bar det, så tabet sker, efter at den eksterne vært allerede har valgt en returvej.

En kilderegel, der er snæver nok til at stole på

Gør routeren til den kilde, som den eksterne vært svarer til. I dette layout er WAN-adressen 203.0.113.24, LAN er 192.168.88.0/24, routerens tunneladresse er 172.20.5.1, og tjenesten svarer på 172.20.5.40:8443. Reglen nedenfor matcher pakken efter destinationsoversættelse, og derfor nævner den den oversatte adresse i stedet for den offentlige. Intet i den afhænger af klientens adresse, og det er netop pointen.

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 linje findes for at holde omskrivningen lokal for én tjeneste på én tunnel. Fjern interfacet eller porten, og du omskriver mere trafik, end problemet kræver, og det er sådan en målrettet rettelse bliver et mysterium for den næste person.

Hvornår en blanket masquerade er det ærlige valg

Hvis routeren videresender mange tjenester til det samme VPN-undernet, bliver en regel for hver tjeneste en liste, som ingen vedligeholder. At maskere alt, der forlader tunnelinterfacet, er enklere og forudsigeligt, på bekostning af at skjule den oprindelige klient for hver vært på den anden side. Vælg det, når loggene derovre ikke bruges til attribuering; behold den snævre regel, når de gør.

De to muligheder fejler også forskelligt. En manglende snæver regel ødelægger én tjeneste; en bred masquerade, der matcher for meget, kan stille omskrive trafik, der allerede virkede, inklusive routerens egne udgående forbindelser.

Tjek tællerne, før du offentliggør

Regler, der aldrig matcher, ser identiske ud med regler, der virker, indtil du tæller pakker. Læs tabellen igen med bytetællere, før nogen klient opretter forbindelse, og opret derefter forbindelse fra et netværk, der ikke er LAN, og læs den igen. To aflæsninger er det, der gør en gætte til et faktum. Offentliggør videresendelsen først, efter den anden flytter sig.

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

En nultæller på kildereglen efter en rigtig forbindelse betyder, at matchet er forkert, normalt fordi destinationen eller porten ikke matcher pakken efter oversættelse. Hvis tælleren stiger, men klienten stadig timer ud, er returvejen repareret, og noget andet dropper svaret, så se næste gang på videresendelsespolitikken på den anden side. Hårnålsadgang indefra LAN er et separat problem og kræver sin egen regel, ikke en bredere version af denne.