Bevar eller SNAT VPN-klienters IP-adresser ved cloudgrænsen

At bevare VPN-klientens adresse helt frem til applikationen gør, at hver loglinje og hver post på tilladelseslisten betyder det samme. At overskrive den ved cloudkanten gør rutetabellen enklere og loggene mindre nyttige. Ingen af de to valg er forkerte i sig selv, og argumentet, der afgør det, handler sjældent om ydeevne. Tre betingelser afgør det: om applikationen skal vide, hvilket menneske der koblede sig på, om cloudstrukturen accepterer den kilde, du vil sende, og hvem der bagefter vil påtage sig returruten.

Tre betingelser afgør det

Begynd med applikationens krav, ikke med netværksdiagrammet. Hvis autorisation eller revision afhænger af den enkelte klientadresse, er bevaring af den et funktionelt krav, og oversættelse er en regression. Hvis applikationen kun skal vide, at trafikken ankom via fjernadgangsstien, er en oversat adresse tilstrækkelig og meget billigere at drive.

Den anden betingelse er mekanisk. Et virtuelt netværk stoler ikke automatisk på en pakke, der hævder en adresse, som ikke er tildelt det sendende interface. De fleste cloudstrukturer håndhæver det, på forskellige måder og under forskellige navne, og et design, der ignorerer det, vil se korrekt ud på et diagram og droppe lydløst i produktion.

Den tredje er organisatorisk. At bevare kilder betyder, at applikationssubnettets rutetabel skal pege tilbage mod gatewayen for klientpræfikset, og hvert team, der senere tilføjer et subnet, skal holde den rute konsistent. Det er en lille udgift én gang og en tilbagevendende udgift på tværs af snesevis af konti. Beslut, hvem der betaler den, før du lover adfærden.

En rute er ikke tilladelse til at spoofe

At tilføje en returrute fortæller dit subnet, hvor svar skal hen. Det fortæller ikke strukturen, at den instans, der videresender de pakker, har lov til at sende dem med en fremmed kilde. På AWS er den relevante kontrol kilde- og destinationskontrol, og den er synlig for hver instans:

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

Slå det kun fra for den instans, hvis dokumenterede arbejde er videresendelse, og ikke for noget andet. Hver applikations-VM, der beholder kontrollen slået til, er én maskine mindre, der kan bruges til at sende trafik med en lånt kilde. Hvis din platform ikke er AWS, så led efter den tilsvarende anti-spoofing- eller allowed-address-indstilling i stedet for at antage, at adfærden følger med.

En hurtig pakkefangst afgør spørgsmålet hurtigere end at læse konsollen. Hvis svar går ud, og klienten aldrig ser dem, er det strukturen, der kasserer den forfalskede kilde, og ikke applikationen, der fejler.

Hvad oversættelse køber, og hvad den koster

At overskrive kilden ved gatewayen fjerner returvejsproblemet. Applikationen ser én adresse, den allerede ved hvordan den skal nå, og klientpræfikset skal aldrig optræde i en cloudrutetabel. På Linux er reglen én linje, og det er værd at skrive den smalleste version, du kan:

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

Læg mærke til, hvad applikationen nu registrerer: 10.40.3.10 for hver bruger, på hver forbindelse, for evigt. Enhver adressetilladelsesliste bygget på den værdi giver nu adgang for hele fjernadgangspopulationen, og enhver hændelsesgennemgang må gå tilbage til gatewayen for at svare på, hvem det var.

Løsningen er ikke at opgive oversættelse, den er at holde op med at lade som om adressen er en identitet. Bær klientidentiteten i et autentificeret felt, log den ved gatewayen sammen med den oversatte tuple, og lad applikationen joine på det. Uden join-nøglen gør oversættelse et netværksproblem til et permanent forensisk et.

Relayet er et andet interface

En omvendt proxy foran applikationen omgår spørgsmålet om den rutede sti helt. Proxyen åbner sin egen backend-forbindelse, så klientpræfikset behøver aldrig være rutbart i det virtuelle netværk, og applikationen kan modtage identitet i et headerfelt, som proxyen sætter.

Det headerfelt er kun troværdigt, når backenden accepterer det fra proxyen og fra intet andet. I nginx-termer betyder det at navngive den betroede peer eksplicit i stedet for at tro på, hvad der end ankommer:

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

Enhver klient, der kan nå backenden direkte, kan forfalske det samme headerfelt, så backenden skal være utilgængelig undtagen gennem proxyen. Det er en firewall-kendsgerning, ikke en konfigurationsmening, og det er den antagelse, folk springer over, når de kopierer uddraget.

Relayet ændrer også, hvad du køber. Du får en identitet på applikationsniveau og et naturligt sted at logge den; du giver afkald på generalitet, fordi hver ny protokol kræver sin egen proxy-understøttelse. For HTTP-tjenester er den handel som regel god, og for alt, der ikke er HTTP, er den som regel slet ikke tilgængelig.

Skriv ned, hvad hver grænse ser

Uanset hvad du vælger, bør designgennemgangen slutte med én tabel, der navngiver kildeadressen og den beviselige identitet ved hvert hop. Uden den producerer den første hændelse tre teams, der hver beskriver en forskellig klient.

Vælg så. Bevar, når applikationens autorisation virkelig afhænger af klientadressen, og du kan påtage dig ruten. Oversæt, når den ikke gør, og du kan bære identitet uden for båndet, og brug AWS-vejledningen til videresendelsesinstanser til de platformspecifikke videresendelsesindstillinger. Grib til et relay, når tjenesten taler HTTP, og du vil have identitet til at holde op med at være en adresse.