Twee VPN-clients, twee openbare adressen: laat SNAT kloppen

Twee VPN-clients kunnen via twee verschillende openbare IPv4-adressen naar buiten gaan, en de regel die dat doet is korter dan de meeste mensen verwachten. Wat het laat werken is niet de iptables-syntaxis, maar de toestand van het pakket wanneer het de egress-keten bereikt: het bronadres daar moet de clients nog steeds kunnen onderscheiden. Als een eerdere masquerade beide al op één adres heeft samengevoegd, kan geen regel per client het onderscheid herstellen. Los die vraag eerst op en schrijf daarna de vertaling.

Welke identiteit de gateway bereikt

De regel matcht het bronadres van het pakket, niet een VPN-gebruikersnaam en niet de naam die een clientapplicatie toont. Alles wat het pakket eerder op het pad vertaalt, bepaalt wat uw regel nog kan zien. Voer de nat-tabel in volgorde uit en vind het punt waar de bron nog per client is.

iptables -t nat -S POSTROUTING

Lees die lijst van bovenaf. Een masquerade-regel bovenaan herschrijft de bron voor elke overeenkomende stroom, en vermeldingen per client die erna zijn geplaatst, matchen een adres dat niet meer bestaat. Wanneer twee LAN-apparaten één tunnel delen en als één intern adres aankomen, moet het ontwerp veranderen voordat de firewall dat doet: houd hun bronbereiken gescheiden of geef elk zijn eigen interne adres.

Koppel de toewijzing van het interne adres aan de geauthenticeerde client. Die adres aan een ander apparaat geven, draagt ook het egress-beleid over, en brontranslatie is op zichzelf geen identiteitsbewijs.

Translatie kan geen adres verzinnen

Elk openbaar adres moet aan dit egress-punt zijn toegewezen of ernaartoe zijn gerouteerd, en de antwoorden moeten de weg terug vinden. Een regel die verkeer vanaf een adres stuurt waar niemand naartoe terugrouteert, wordt aan de andere kant weggegooid of aan een host beantwoord die er nooit om vroeg. Een cloudprovider-instantie heeft zijn openbare adres meestal al naar een privé-interfaceadres vertaald voordat het pakket vertrekt, dus de SNAT-bron moet het adres zijn dat de provider accepteert, niet de waarde die de console toont. Lees het adresmodel van de provider en volg het in plaats van de openbare waarde in elk pakket te kopiëren.

In de praktijk betekent dat het gerouteerde prefix in de console van de provider controleren voordat u de firewall aanraakt, en het privé-interfaceadres als translatiebron gebruiken wanneer de mapping een-op-een is. De adressen in de voorbeelden hieronder komen uit de documentatiebereiken, dus het eerste dat moet worden vervangen is de adrestekst zelf.

Voeg in vóór de generieke masquerade

Bevestig de egress-interface en de huidige keten voordat u iets toevoegt. De eerste bepaalt welke pakketten de regel kan matchen, en de tweede toont wat er al voor staat.

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

Het eerste commando noemt de interface waar een pakket naar het internet daadwerkelijk door uitgaat. Het tweede drukt de keten af met regelnummers. De generieke masquerade-vermelding is de regel waar u boven moet blijven.

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 twee regels hierboven matchen elk één intern adres, beperken de match tot de egress-interface en stellen de bron expliciet in. Voeg in in plaats van toe: op positie 1 worden ze vóór de masquerade-regel geëvalueerd. De volgorde tussen de twee maakt niet uit omdat hun bronnen verschillen. Vervang ens3 door wat het route-commando rapporteerde, en houd andere firewall-beheerders van dezelfde hooks, omdat twee tools die één tabel schrijven de gebruikelijke reden is dat een correcte regel geen effect heeft.

Bewijs de bron met een nieuwe stroom

Stateful NAT bindt een translatie wanneer een stroom begint en hergebruikt die voor latere pakketten, dus een sessie die vóór de wijziging is geopend, behoudt na de wijziging zijn oude bron. Alleen een nieuw gestarte verbinding bewijst de regel.

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

Lees de antwoordrichting van die vermelding: de bestemming is het adres dat het externe eindpunt als bron ziet. Vergelijk het met het openbare adres dat u bedoelde, en behandel een vermelding met het oude adres als bewijs van een stroom die te vroeg begon, niet van een kapotte regel. Vraag de client een nieuwe verbinding te openen en herhaal daarna de query. De hele trackingtabel legen om de test af te dwingen onderbreekt elke andere sessie op de gateway.

Translatie kiest nog steeds niet de route, laat de stroom niet door het filter en publiceert geen inkomende dienst. Een verkeerde route en een ontbrekende toestemmingsregel blijven falen na een perfecte SNAT-regel. Controleer ook IPv6 en elk secundair egress-pad, en noteer daarna de paren intern-naar-openbaar in de documentatie van de firewall, zodat de volgende wijziging bij de mapping begint en niet bij de regeltekst.