Behold eller SNAT IP-adressene til VPN-klienter ved skygrensen

Å beholde VPN-klientens adresse helt frem til applikasjonen gjør at hver logglinje og hver oppføring på tillatelseslisten betyr det samme. Å skrive den om ved skygrensen gjør rutetabellen enklere og loggene mindre nyttige. Ingen av valgene er feil i seg selv, og argumentet som avgjør det handler sjelden om ytelse. Tre betingelser avgjør: om applikasjonen må vite hvilket menneske som koblet til, om skystoffet godtar kilden du vil sende, og hvem som er villig til å ta ansvaret for returveien etterpå.

Tre betingelser avgjør

Start med applikasjonens krav, ikke med nettverksdiagrammet. Hvis autorisasjon eller revisjon avhenger av den enkelte klientadressen, er bevaring av den et funksjonelt krav, og oversettelse er en regresjon. Hvis applikasjonen bare trenger å vite at trafikken kom via fjernadgangsveien, er en oversatt adresse tilstrekkelig og mye billigere å drifte.

Den andre betingelsen er mekanisk. Et virtuelt nettverk stoler ikke automatisk på en pakke som hevder en adresse som ikke er tildelt det sendende grensesnittet. De fleste skystoffer håndhever det, på ulike måter og under ulike navn, og et design som ignorerer det vil se riktig ut på et diagram og droppe stille i produksjon.

Den tredje er organisatorisk. Bevaring av kilder betyr at rutetabellen til applikasjonssubnettet må peke tilbake mot gatewayen for klientprefikset, og hvert team som legger til et subnett senere må holde den ruten konsistent. Det er en liten kostnad én gang, og en tilbakevendende kostnad over dusinvis av kontoer. Bestem hvem som betaler den før du lover oppførselen.

En rute er ikke tillatelse til å spoofe

Å legge til en returrute forteller subnettet ditt hvor svarene skal gå. Det forteller ikke veven at instansen som videresender pakkene har lov til å sende dem ut med en fremmed kilde. På AWS er den relevante kontrollen kilde- og destinasjonskontroll, og den er synlig per 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å den bare av for instansen hvis dokumenterte jobb er videresending, og ikke for noe annet. Hver applikasjons-VM som beholder kontrollen på, er én maskin mindre som kan brukes til å sende trafikk med en lånt kilde. Hvis plattformen din ikke er AWS, se etter den tilsvarende anti-spoofing- eller tillatte adresseinnstillingen i stedet for å anta at oppførselen følger med.

En rask pakkefangst avgjør spørsmålet raskere enn å lese konsollen. Hvis svar går ut og klienten aldri ser dem, er det veven som forkaster den forfalskede kilden, og ikke applikasjonen som feiler.

Hva oversettelse kjøper, og hva den koster

Å skrive om kilden ved gatewayen fjerner returveisproblemet. Applikasjonen ser én adresse den allerede vet hvordan den skal nå, og klientprefikset trenger aldri å dukke opp i en skybasert rutetabell. På Linux er regelen én linje, og det er verdt å skrive den smaleste versjonen 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

Legg merke til hva applikasjonen nå registrerer: 10.40.3.10 for hver bruker, på hver tilkobling, for alltid. Enhver adressetillatelsesliste bygget på den verdien gir nå tilgang til hele fjernadgangspopulasjonen, og enhver hendelsesgjennomgang må gå tilbake til gatewayen for å svare på hvem dette var.

Løsningen er ikke å oppgi oversettelse, den er å slutte å late som adressen er en identitet. Bær klientidentiteten i et autentisert felt, logg den ved gatewayen sammen med den oversatte tupelen, og la applikasjonen koble seg på den. Uten sammenkoblingsnøkkelen gjør oversettelse et nettverksproblem om til et permanent etterforskningsproblem.

Reléet er et annet grensesnitt

En omvendt proxy foran applikasjonen omgår spørsmålet om den rutede veien helt. Proxyen åpner sin egen backend-tilkobling, så klientprefikset trenger aldri å være rutbart inne i det virtuelle nettverket, og applikasjonen kan motta identitet i en header proxyen setter.

Den headeren er bare pålitelig når backend godtar den fra proxyen og fra ingenting annet. I nginx-termer betyr det å navngi den betrodde parten eksplisitt i stedet for å tro på hva som helst som kommer:

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

Enhver klient som kan nå backend direkte kan forfalske den samme headeren, så backend må være utilgjengelig unntatt gjennom proxyen. Det er et brannmur-faktum, ikke en konfigurasjonsmening, og det er antakelsen folk hopper over når de kopierer utdraget.

Reléet endrer også hva du kjøper. Du får en identitet på applikasjonsnivå og et naturlig sted å logge den; du gir avkall på allmenngyldighet, fordi hver ny protokoll trenger sin egen proxy-støtte. For HTTP-tjenester er den handelen vanligvis god, og for alt som ikke er HTTP er den vanligvis ikke tilgjengelig i det hele tatt.

Skriv ned hva hver grense ser

Uansett hva du velger, bør designgjennomgangen ende med én tabell som navngir kildeadressen og den bevisbare identiteten ved hvert hopp. Uten den produserer den første hendelsen tre team som hver beskriver en forskjellig klient.

Velg så. Behold når applikasjonens autorisasjon virkelig avhenger av klientadressen og du kan ta på deg ruten. Oversett når den ikke gjør det og du kan bære identitet utenfor båndet, og bruk AWS-veiledningen for videresendingsinstanser for de plattformspesifikke videresendingsinnstillingene. Grip til et relé når tjenesten snakker HTTP og du vil at identitet skal slutte å være en adresse.