Två VPN-klienter, två offentliga adresser: få SNAT att stämma

Två VPN-klienter kan gå ut genom två olika offentliga IPv4-adresser, och regeln som gör det är kortare än de flesta förväntar sig. Det som får den att fungera är inte iptables-syntaxen utan paketets tillstånd när det når egress-kedjan: källadressen där måste fortfarande kunna skilja klienterna. Om en tidigare masquerade redan har slagits samman båda på en adress kan ingen regel per klient återställa skillnaden. Avgör den frågan först och skriv sedan översättningen.

Vilken identitet överlever till gatewayen

Regeln matchar paketets källadress, inte ett VPN-användarnamn och inte namnet som en klientapplikation visar. Allt som översätter paketet tidigare på vägen avgör vad din regel fortfarande kan se. Kör nat-tabellen i ordning och hitta punkten där källan fortfarande är per klient.

iptables -t nat -S POSTROUTING

Läs listan uppifrån. En masquerade-regel nära toppen skriver om källan för varje matchande flöde, och poster per klient som placeras efter den matchar en adress som inte längre finns. När två LAN-enheter delar en tunnel och anländer som en enda inre adress måste designen ändras innan brandväggen gör det: håll deras källområden åtskilda eller ge var och en sin egen inre adress.

Knyt tilldelningen av den inre adressen till den autentiserade klienten. Att ge den adressen vidare till en annan enhet överför också egress-policyn, och källöversättning är inte i sig ett identitetsbevis.

Översättning kan inte hitta på en adress

Varje offentlig adress måste tilldelas eller routas till denna egress-punkt, och svaren måste hitta vägen tillbaka. En regel som skickar trafik från en adress som ingen routar tillbaka till släpps i den bortre änden eller besvaras till en värd som aldrig bad om det. En molnleverantörsinstans har vanligtvis sin offentliga adress översatt till en privat gränssnittsadress innan paketet lämnar den, så SNAT-källan måste vara den adress som leverantören accepterar, inte värdet som konsolen visar. Läs leverantörens adressmodell och följ den i stället för att kopiera det offentliga värdet i varje paket.

I praktiken innebär det att kontrollera det routade prefixet i leverantörens konsol innan du rör brandväggen, och att använda den privata gränssnittsadressen som översättningskälla när mappningen är ett-till-ett. Adresserna i exemplen nedan kommer från dokumentationsområdena, så det första som måste bytas ut är adresstexten själv.

Infoga före den generiska masqueraden

Bekräfta egress-gränssnittet och den aktuella kedjan innan du lägger till något. Den första avgör vilka paket regeln kan matcha, och den andra visar vad som redan står framför den.

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

Det första kommandot namnger gränssnittet som ett paket till internet faktiskt lämnar genom. Det andra skriver ut kedjan med radnummer. Den generiska masquerade-posten är raden du måste hålla dig ovanför.

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 två reglerna ovan matchar en inre adress var, begränsar matchningen till egress-gränssnittet och sätter källan uttryckligen. Infoga i stället för att lägga till: på position 1 utvärderas de före masquerade-raden. Ordningen mellan de två spelar ingen roll eftersom deras källor skiljer sig. Ersätt ens3 med det route-kommandot rapporterade, och håll andra brandväggshanterare borta från samma krokar, eftersom två verktyg som skriver en tabell är den vanliga orsaken till att en korrekt regel inte har effekt.

Bevisa källan med ett nytt flöde

Stateful NAT binder en översättning när ett flöde börjar och återanvänder den för senare paket, så en session som öppnades före ändringen behåller sin gamla källa efter ändringen. Bara en nyligen startad anslutning bevisar regeln.

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

Läs svarriktningen för den posten: destinationen är adressen som den bortre änden ser som källan. Jämför den med den offentliga adress du avsåg, och behandla en post med den gamla adressen som bevis på ett flöde som startade för tidigt, inte på en trasig regel. Be klienten öppna en ny anslutning och upprepa sedan frågan. Att tömma hela spårningstabellen för att tvinga fram testet avbryter alla andra sessioner på gatewayen.

Översättning väljer fortfarande inte rutten, släpper inte igenom flödet genom filtret och publicerar inte en inkommande tjänst. En felaktig rutt och en saknad tillåtelseregel fortsätter att misslyckas efter en perfekt SNAT-regel. Kontrollera även IPv6 och varje sekundär egress-väg, och notera sedan paren inre-till-offentlig i brandväggens dokumentation så att nästa ändring börjar från mappningen i stället för regeltexten.