Bør du bruke SNAT på ei portvideresending til eit VPN-subnett?

Videresending av ei port til ein vert som ligg bak rutaren sin eigen VPN-klient, feilar på ein måte som ser ut som eit brannmurproblem, fordi førespurnaden tydeleg kjem fram. Tenesta loggar ei tilkopling, klienten ventar, og ingenting kjem tilbake. Destinasjonsomsetjinga gjorde jobben sin; returpakken er den delen som forsvann. Éin selektiv kjeld-NAT-regel på rutaren fiksar det, og den interessante delen er å avgjere kor smal den regelen kan vere.

Kvifor svaret tek ein annan veg

Ei portvideresending skriv om kvar ein pakke skal, aldri kvar han kom frå. Adressa til internettklienten blir verande i kjeldafeltet heile vegen gjennom tunnelen, så den eksterne tenesta ser ein framand og svarar på den einaste måten ho kjenner: gjennom sin eigen standardgateway. Den gatewayen er VPN-konsentratoren på den andre sida, som ikkje har noka rute tilbake til ei vilkårleg offentleg adresse.

Sjå eit opptak på tunnelgrensesnittet, og asymmetrien er tydeleg: førespurnadspakkar ut, ingenting inn. Videresendingskjeda tillét flyten, og tunnelen bar han, så droppet skjer etter at den eksterne verten allereie har valt ein returveg.

Ein kjelderegel som er smal nok til å stole på

Gjer rutaren til kjelda som den eksterne verten svarar til. I dette oppsettet er WAN-adressa 203.0.113.24, LAN er 192.168.88.0/24, tunneladressa til rutaren er 172.20.5.1, og tenesta svarar på 172.20.5.40:8443. Regelen nedanfor matchar pakken etter destinasjonsomsetjing, og difor nemner han den omsette adressa i staden for den offentlege. Ingenting i han er avhengig av adressa til klienten, 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

Kvart treff i den linja finst for å halde omskrivinga lokal for éi teneste på éin tunnel. Fjern grensesnittet eller porten, og du skriv om meir trafikk enn problemet krev, og det er slik ei målretta retting blir eit mysterium for neste person.

Når ein blanket masquerade er det ærlege valet

Viss rutaren videresender mange tenester til det same VPN-subnettet, blir ein regel per teneste ei liste som ingen vedlikeheld. Å maskere alt som forlèt tunnelgrensesnittet er enklare og føreseieleg, på kostnad av å skjule den opphavlege klienten for kvar vert på den andre sida. Vel det når loggane der borte ikkje blir brukte til attribusjon; hald på den smale regelen når dei blir det.

Dei to alternativa feilar òg ulikt. Ein manglande smal regel øydelegg éi teneste; ein brei masquerade som matchar for mykje kan stille skrive om trafikk som allereie verka, inkludert rutaren sine eigne utgåande samband.

Sjekk teljarane før du publiserer

Reglar som aldri matchar ser identiske ut med reglar som verkar, heilt til du tel pakkar. Les tabellen på nytt med bytteteljarar før nokon klient koplar til, og kopla deretter til frå eit nettverk som ikkje er LAN og les han igjen. To avlesingar er det som gjer ei gjetting til eit faktum. Publiser videresendinga først etter at den andre flyttar seg.

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

Ein nullteljar på kjelderegelen etter ei ekte tilkopling betyr at treffet er feil, vanlegvis fordi destinasjonen eller porten ikkje matchar pakken etter omsetjing. Viss teljaren stig, men klienten framleis timar ut, er returvegen reparert og noko anna droppar svaret, så sjå neste gong på videresendingspolicyen på den andre sida. Hårnålsåtgang innanfrå LAN er eit eige problem og treng sin eigen regel, ikkje ein breiare versjon av denne.