Behoud of SNAT de IP's van VPN-clients aan de cloudgrens

Het adres van de VPN-client helemaal tot de applicatie bewaren maakt dat elke logregel en elke vermelding in de toelatingslijst hetzelfde betekenen. Het aan de cloudgrens herschrijven maakt de routetabel eenvoudiger en de logs minder bruikbaar. Geen van beide keuzes is op zichzelf fout, en het argument dat de keuze bepaalt gaat zelden over prestaties. Drie voorwaarden beslissen het: of de applicatie moet weten welk mens verbonden was, of de cloudfabric de bron accepteert die je wilt versturen, en wie daarna de verantwoordelijkheid voor de retourroute op zich neemt.

Drie voorwaarden beslissen het

Begin bij de eis van de applicatie, niet bij het netwerkdiagram. Als autorisatie of audit afhangt van het individuele clientadres, dan is het bewaren daarvan een functionele eis en is vertaling een regressie. Als de applicatie alleen hoeft te weten dat het verkeer via het pad voor externe toegang binnenkwam, volstaat een vertaald adres en is dat veel goedkoper in beheer.

De tweede voorwaarde is mechanisch. Een virtueel netwerk vertrouwt niet automatisch een pakket dat een adres beweert dat niet aan de verzendende interface is toegewezen. De meeste cloudfabrics dwingen dat af, op verschillende manieren en onder verschillende namen, en een ontwerp dat dit negeert ziet er in een diagram correct uit en verdwijnt in productie geruisloos.

De derde is organisatorisch. Bronnen bewaren betekent dat de routetabel van het applicatiesubnet voor het clientprefix terug moet wijzen naar de gateway, en elk team dat later een subnet toevoegt moet die route consistent houden. Dat is één keer een kleine kostenpost, en een terugkerende over tientallen accounts. Beslis wie die betaalt voordat je het gedrag belooft.

Een route is geen toestemming om te spoofen

Een retourroute toevoegen vertelt je subnet waar antwoorden naartoe moeten. Het vertelt de fabric niet dat de instance die die pakketten doorstuurt ze met een vreemde bron mag uitsturen. Op AWS is de relevante controle bron- en bestemmingscontrole, en die is per instance zichtbaar:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Schakel die alleen uit voor de instance waarvan het gedocumenteerde werk doorsturen is, en voor niets anders. Elke applicatie-VM die de controle aan laat staan is één machine minder die kan worden gebruikt om verkeer met een geleende bron uit te sturen. Als je platform geen AWS is, zoek dan de equivalente anti-spoofing- of toegestane-adresinstelling in plaats van aan te nemen dat het gedrag overkomt.

Een snelle packet capture beslecht de vraag sneller dan de console lezen. Als antwoorden vertrekken en de client ze nooit ziet, is het de fabric die de vervalste bron weggooit, en niet de applicatie die faalt.

Wat vertaling koopt, en wat het kost

De bron bij de gateway herschrijven haalt het terugwegprobleem weg. De applicatie ziet één adres dat ze al weet te bereiken, en het clientprefix hoeft nooit in een cloud-routetabel te verschijnen. Op Linux is de regel één regel, en het loont de moeite de smalste versie te schrijven die je kunt:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Let op wat de applicatie nu vastlegt: 10.40.3.10 voor elke gebruiker, bij elke verbinding, voor altijd. Elke adrestoelatingslijst die op die waarde is gebouwd geeft nu toegang aan de hele populatie voor externe toegang, en elk incidentonderzoek moet terug naar de gateway om te antwoorden wie dit was.

De oplossing is niet vertaling opgeven, maar ophouden te doen alsof het adres een identiteit is. Draag de identiteit van de client in een geauthenticeerd veld, log die bij de gateway samen met het vertaalde tuple, en laat de applicatie daarop joinen. Zonder de joinsleutel verandert vertaling een netwerkprobleem in een permanent forensisch probleem.

De relay is een andere interface

Een reverse proxy voor de applicatie omzeilt de vraag naar het gerouteerde pad volledig. De proxy opent zijn eigen backendverbinding, zodat het clientprefix nooit routeerbaar hoeft te zijn binnen het virtuele netwerk, en de applicatie kan identiteit ontvangen in een header die de proxy zet.

Die header is alleen betrouwbaar wanneer de backend hem van de proxy accepteert en van niets anders. In nginx-termen betekent dat de vertrouwde peer expliciet benoemen in plaats van te geloven wat er ook binnenkomt:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Elke client die de backend rechtstreeks kan bereiken kan dezelfde header vervalsen, dus de backend moet onbereikbaar zijn behalve via de proxy. Dat is een firewallfeit, geen configuratiemening, en het is de aanname die mensen overslaan wanneer ze het fragment kopiëren.

De relay verandert ook wat je koopt. Je krijgt een identiteit op applicatieniveau en een natuurlijke plek om die te loggen; je geeft algemeenheid op, omdat elk nieuw protocol zijn eigen proxyondersteuning nodig heeft. Voor HTTP-diensten is die ruil meestal goed, en voor alles wat geen HTTP is is die meestal helemaal niet beschikbaar.

Schrijf op wat elke grens ziet

Wat je ook kiest, de ontwerpreview zou moeten eindigen met één tabel die op elke hop het bronadres en de aantoonbare identiteit benoemt. Zonder die tabel levert het eerste incident drie teams op die elk een andere client beschrijven.

Kies dan. Behoud wanneer de autorisatie van de applicatie echt van het clientadres afhangt en je de route kunt dragen. Vertaal wanneer dat niet zo is en je identiteit buiten de band kunt dragen, en gebruik de AWS-richtlijnen voor doorstuurinstances voor de platformspecifieke doorstuurknoppen. Grijp naar een relay wanneer de dienst HTTP spreekt en je wilt dat identiteit ophoudt een adres te zijn.