Behald eller SNAT IP-adressene til VPN-klientar ved skygrensa

Å behalde adressa til VPN-klienten heilt fram til applikasjonen gjer at kvar logglinje og kvar oppføring på løyvelista tyder det same. Å skrive henne om ved skygrensa gjer rutetabellen enklare og loggane mindre nyttige. Ingen av vala er feil i seg sjølv, og argumentet som avgjer det handlar sjeldan om yting. Tre vilkår avgjer: om applikasjonen må vite kva menneske som kopla til, om skystoffet godtek kjelda du vil sende, og kven som er villig til å ta ansvaret for returvegen etterpå.

Tre vilkår avgjer

Start med kravet til applikasjonen, ikkje med nettverksdiagrammet. Viss autorisasjon eller revisjon avheng av den einskilde klientadressa, er bevaring av henne eit funksjonelt krav, og omsetjing er ein regresjon. Viss applikasjonen berre treng å vite at trafikken kom via fjernåtkomstvegen, er ei omsett adresse tilstrekkeleg og mykje billegare å drifte.

Det andre vilkåret er mekanisk. Eit virtuelt nettverk stolar ikkje automatisk på ein pakke som hevdar ei adresse som ikkje er tildelt det sendande grensesnittet. Dei fleste skystoffa handhevar det, på ulike måtar og under ulike namn, og eit design som ignorerer det vil sjå rett ut på eit diagram og droppe stille i produksjon.

Det tredje er organisatorisk. Bevaring av kjelder tyder at rutetabellen til applikasjonssubnettet må peike tilbake mot gatewayen for klientprefikset, og kvart team som legg til eit subnett seinare må halde den ruta konsistent. Det er ein liten kostnad éin gong, og ein tilbakevendande kostnad over dusinvis av kontoar. Bestem kven som betaler han før du lovar åtferda.

Ei rute er ikkje løyve til å spoofe

Å leggje til ei returrute fortel subnettet ditt kvar svara skal gå. Det fortel ikkje veven at instansen som videresender pakkane har lov til å sende dei ut med ei framand kjelde. På AWS er den relevante kontrollen kjelde- og målkontroll, og han er synleg 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å han berre av for instansen der den dokumenterte jobben er videresending, og ikkje for noko anna. Kvar applikasjons-VM som held kontrollen på, er éi maskin mindre som kan brukast til å sende trafikk med ei lånt kjelde. Viss plattforma di ikkje er AWS, sjå etter den tilsvarande anti-spoofing- eller tillatne adresseinnstillinga i staden for å anta at åtferda følgjer med.

Ein rask pakkefangst avgjer spørsmålet raskare enn å lese konsollen. Viss svar går ut og klienten aldri ser dei, er det veven som kastar den forfalska kjelda, og ikkje applikasjonen som feilar.

Kva omsetjing kjøper, og kva ho kostar

Å skrive om kjelda ved gatewayen fjernar returvegproblemet. Applikasjonen ser éi adresse han allereie veit korleis han skal nå, og klientprefikset treng aldri å dukke opp i ein skybasert rutetabell. På Linux er regelen éi linje, og det er verdt å skrive den smalaste 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 kva applikasjonen no registrerer: 10.40.3.10 for kvar brukar, på kvar tilkopling, for alltid. Kvar adresseløyveliste bygd på den verdien gir no tilgang til heile fjernåtkomstpopulasjonen, og kvar hendingsgjennomgang må gå tilbake til gatewayen for å svare på kven dette var.

Løysinga er ikkje å gje opp omsetjing, ho er å slutte å late som adressa er ein identitet. Bér klientidentiteten i eit autentisert felt, logg han ved gatewayen saman med den omsette tupelen, og la applikasjonen kopie seg på han. Utan samankoplingnøkkelen gjer omsetjing eit nettverksproblem om til eit permanent etterforskingsproblem.

Reléet er eit anna grensesnitt

Ein omvend proxy framfor applikasjonen omgår spørsmålet om den ruta vegen heilt. Proxyen opnar si eiga backend-tilkopling, så klientprefikset treng aldri å vere rutbart inne i det virtuelle nettverket, og applikasjonen kan ta imot identitet i ein header proxyen set.

Den headeren er berre påliteleg når backend godtek han frå proxyen og frå ingenting anna. I nginx-termar tyder det å namngje den betrudde parten eksplisitt i staden for å tru på kva som helst som kjem:

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

Kvar klient som kan nå backend direkte kan forfalske den same headeren, så backend må vere utilgjengeleg utanom gjennom proxyen. Det er eit brannmur-faktum, ikkje ei konfigureringsmeining, og det er føresetnaden folk hoppar over når dei kopierer utdraget.

Reléet endrar òg kva du kjøper. Du får ein identitet på applikasjonsnivå og ein naturleg stad å logge han; du gjev avkall på allmenngyldigheit, fordi kvar ny protokoll treng si eiga proxy-støtte. For HTTP-tenester er den handelen vanlegvis god, og for alt som ikkje er HTTP er han vanlegvis ikkje tilgjengeleg i det heile.

Skriv ned kva kvar grense ser

Uansett kva du vel, bør designgjennomgangen enda med éin tabell som namngjev kjeldadressa og den bevisbare identiteten ved kvart hopp. Utan han produserer den første hendinga tre team som kvar skildrar ein annan klient.

Vel då. Behald når autorisasjonen til applikasjonen verkeleg avheng av klientadressa og du kan ta på deg ruta. Omset når han ikkje gjer det og du kan bére identitet utanfor bandet, og bruk AWS-rettleiinga for videresendingsinstansar for dei plattformspesifikke videresendingsinnstillingane. Grip til eit relé når tenesta snakkar HTTP og du vil at identitet skal slutte å vere ei adresse.