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

To VPN-klienter kan forlade netværket gennem to forskellige offentlige IPv4-adresser, og reglen, der gør det, er kortere, end de fleste forventer. Det, der får det til at virke, er ikke iptables-syntaksen, men pakkens tilstand, når den når egress-kæden: kildeadressen der skal stadig kunne skelne klienterne. Hvis en tidligere masquerade allerede har slået dem begge sammen på én adresse, kan ingen regel per klient genskabe forskellen. Afklar det spørgsmål først, og skriv derefter oversættelsen.

Hvilken identitet overlever til gatewayen

Reglen matcher pakkens kildeadresse, ikke et VPN-brugernavn og ikke det navn, en klientapplikation viser. Alt, der oversætter pakken tidligere på vejen, bestemmer, hvad din regel stadig kan se. Kør nat-tabellen i rækkefølge, og find det punkt, hvor kilden stadig er per klient.

iptables -t nat -S POSTROUTING

Læs den liste fra toppen. En masquerade-regel nær toppen omskriver kilden for hver matchende strøm, og poster per klient, der er placeret efter den, matcher en adresse, der ikke findes længere. Når to LAN-enheder deler én tunnel og ankommer som én indre adresse, skal designet ændres, før firewallen gør det: hold deres kildeområder adskilt, eller giv hver enhed sin egen indre adresse.

Knyt tildelingen af den indre adresse til den autentificerede klient. At give den adresse videre til en anden enhed overlader også egress-politikken, og kildeoversættelse er ikke i sig selv et identitetsbevis.

Oversættelse kan ikke opfinde en adresse

Hver offentlig adresse skal tildeles eller routes til dette egress-punkt, og svarene skal finde vej tilbage til det. En regel, der sender trafik fra en adresse, som ingen routes tilbage til, droppes i den fjerne ende eller besvares til en vært, der aldrig bad om det. En cloud-udbyder-instans har normalt sin offentlige adresse oversat til en privat interface-adresse, før pakken forlader den, så SNAT-kilden skal være den adresse, udbyderen accepterer, ikke den værdi, konsollen viser. Læs udbyderens adressemodel, og følg den i stedet for at kopiere den offentlige værdi ind i hver pakke.

I praksis betyder det at kontrollere det routed præfiks i udbyderens konsol, før du rører firewallen, og at bruge den private interface-adresse som oversættelseskilde, når mappingen er en-til-en. Adresserne i eksemplerne nedenfor kommer fra dokumentationsområderne, så det første, der skal erstattes, er selve adresseteksten.

Indsæt før den generiske masquerade

Bekræft egress-interfacet og den aktuelle kæde, før du tilføjer noget. Den første afgør, hvilke pakker reglen kan matche, og den anden viser, hvad der allerede står foran den.

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

Den første kommando angiver det interface, som en pakke til internettet faktisk forlader gennem. Den anden udskriver kæden med linjenumre. Den generiske masquerade-post er den linje, du skal blive 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 regler ovenfor matcher hver én indre adresse, begrænser matchningen til egress-interfacet og sætter kilden eksplicit. Indsæt i stedet for at tilføje: på position 1 evalueres de før masquerade-linjen. Rækkefølgen mellem de to er ligegyldig, fordi deres kilder er forskellige. Erstat ens3 med det, route-kommandoen rapporterede, og hold andre firewall-managere væk fra de samme hooks, da to værktøjer, der skriver én tabel, er den sædvanlige grund til, at en korrekt regel ikke har nogen effekt.

Bevis kilden med en ny strøm

Stateful NAT binder en oversættelse, når en strøm begynder, og genbruger den til senere pakker, så en session, der blev åbnet før ændringen, beholder sin gamle kilde efter ændringen. Kun en nyligt startet forbindelse beviser reglen.

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

Læs svarretningen af den post: dens destination er den adresse, den fjerne endpoint ser som kilden. Sammenlign den med den offentlige adresse, du havde tænkt dig, og betragt en post med den gamle adresse som bevis på en strøm, der startede for tidligt, snarere end på en ødelagt regel. Bed klienten om at åbne en ny forbindelse, og gentag derefter forespørgslen. At tømme hele sporingstabellen for at tvinge testen afbryder alle andre sessioner på gatewayen.

Oversættelse vælger stadig ikke ruten, lukker ikke strømmen gennem filteret og publicerer ikke en indgående tjeneste. En forkert rute og en manglende tilladelsesregel bliver ved med at fejle efter en perfekt SNAT-regel. Kontroller også IPv6 og enhver sekundær egress-vej, og noter derefter indre-til-offentlige-parrene i firewallens dokumentation, så den næste ændring starter fra mappingen i stedet for fra regelteksten.