To VPN-klienter, to offentlige adresser: få SNAT til å stemme

To VPN-klienter kan gå ut gjennom to forskjellige offentlige IPv4-adresser, og regelen som gjør det er kortere enn folk flest forventer. Det som får den til å virke er ikke iptables-syntaksen, men tilstanden til pakken når den når egress-kjeden: kildeadressen der må fortsatt kunne skille klientene. Hvis en tidligere masquerade allerede har slått begge sammen på én adresse, kan ingen regel per klient gjenopprette forskjellen. Avgjør det spørsmålet først, og skriv deretter oversettelsen.

Hvilken identitet overlever til gatewayen

Regelen matcher pakkens kildeadresse, ikke et VPN-brukernavn og ikke navnet en klientapplikasjon viser. Alt som oversetter pakken tidligere på veien bestemmer hva regelen din fortsatt kan se. Kjør nat-tabellen i rekkefølge og finn punktet der kilden fortsatt er per klient.

iptables -t nat -S POSTROUTING

Les listen ovenfra. En masquerade-regel nær toppen skriver om kilden for hver samsvarende strøm, og oppføringer per klient som plasseres etter den matcher en adresse som ikke finnes lenger. Når to LAN-enheter deler én tunnel og ankommer som én indre adresse, må designet endres før brannmuren: hold kildeområdene deres adskilt eller gi hver enhet sin egen indre adresse.

Knytt tildelingen av den indre adressen til den autentiserte klienten. Å gi den adressen videre til en annen enhet overfører også egress-policyen, og kildeoversettelse er ikke i seg selv et identitetsbevis.

Oversettelse kan ikke finne opp en adresse

Hver offentlig adresse må tildeles eller rutes til dette egress-punktet, og svarene må finne veien tilbake dit. En regel som sender trafikk fra en adresse ingen ruter tilbake til, droppes i den fjerne enden eller besvares til en vert som aldri ba om det. En sky-leverandør-instans har vanligvis sin offentlige adresse oversatt til en privat grensesnittadresse før pakken forlater den, så SNAT-kilden må være adressen leverandøren godtar, ikke verdien konsollen viser. Les leverandørens adressemodell og følg den i stedet for å kopiere den offentlige verdien inn i hver pakke.

I praksis betyr det å kontrollere det rutede prefikset i leverandørens konsoll før du berører brannmuren, og å bruke den private grensesnittadressen som oversettelseskilde når mappingen er en-til-en. Adressene i eksemplene nedenfor kommer fra dokumentasjonsområdene, så det første som må erstattes er adresseteksten selv.

Sett inn før den generiske masqueraden

Bekreft egress-grensesnittet og den gjeldende kjeden før du legger til noe. Den første avgjør hvilke pakker regelen kan matche, og den andre viser hva som allerede står foran den.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Den første kommandoen navngir grensesnittet en pakke til internett faktisk forlater gjennom. Den andre skriver ut kjeden med linjenumre. Den generiske masquerade-oppføringen er linjen du må holde deg over.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

De to reglene ovenfor matcher én indre adresse hver, begrenser matchingen til egress-grensesnittet og setter kilden eksplisitt. Sett inn i stedet for å legge til: på posisjon 1 vurderes de før masquerade-linjen. Rekkefølgen mellom de to spiller ingen rolle fordi kildene deres er forskjellige. Erstatt ens3 med det route-kommandoen rapporterte, og hold andre brannmur-behandlere borte fra de samme krokene, siden to verktøy som skriver én tabell er den vanlige grunnen til at en korrekt regel ikke har effekt.

Bevis kilden med en ny strøm

Stateful NAT binder en oversettelse når en strøm begynner og gjenbruker den for senere pakker, så en sesjon som ble åpnet før endringen beholder sin gamle kilde etter endringen. Bare en nylig startet tilkobling beviser regelen.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Les svarretningen til den oppføringen: destinasjonen er adressen den fjerne enden ser som kilden. Sammenlign den med den offentlige adressen du mente, og behandle en oppføring med den gamle adressen som bevis på en strøm som startet for tidlig, ikke på en ødelagt regel. Be klienten åpne en ny tilkobling, og gjenta deretter spørringen. Å tømme hele sporingstabellen for å tvinge testen avbryter alle andre sesjoner på gatewayen.

Oversettelse velger fortsatt ikke ruten, slipper ikke strømmen gjennom filteret og publiserer ikke en inngående tjeneste. En feil rute og en manglende tillatelsesregel fortsetter å feile etter en perfekt SNAT-regel. Sjekk også IPv6 og enhver sekundær egress-vei, og noter deretter indre-til-offentlige-parene i brannmurens dokumentasjon slik at neste endring starter fra mappingen i stedet for regelteksten.