Păstrează sau aplică SNAT adreselor IP ale clienților VPN la marginea cloudului

Păstrarea adresei clientului VPN până la aplicație face ca fiecare linie de jurnal și fiecare intrare din lista de permisiuni să însemne același lucru. Rescrierea ei la marginea cloudului face tabela de rutare mai simplă și jurnalele mai puțin utile. Niciuna dintre cele două opțiuni nu este greșită în sine, iar argumentul care o decide rar are legătură cu performanța. Trei condiții o decid: dacă aplicația trebuie să știe ce persoană s-a conectat, dacă țesătura cloudului va accepta sursa pe care intenționați să o trimiteți și cine va accepta să își asume ruta de întoarcere după aceea.

Trei condiții o decid

Începeți cu cerința aplicației, nu cu diagrama rețelei. Dacă autorizarea sau auditul depind de adresa individuală a clientului, atunci păstrarea ei este o cerință funcțională, iar traducerea este o regresie. Dacă aplicația trebuie doar să știe că traficul a venit pe calea de acces la distanță, o adresă tradusă este suficientă și mult mai ieftin de operat.

A doua condiție este mecanică. O rețea virtuală nu se încrede automat într-un pachet care pretinde o adresă care nu a fost atribuită interfeței de trimitere. Majoritatea țesăturilor de cloud impun acest lucru, în moduri și sub nume diferite, iar un design care îl ignoră va părea corect pe o diagramă și va eșua silențios în producție.

A treia este organizațională. Păstrarea surselor înseamnă că tabela de rutare a subrețelei aplicației trebuie să indice înapoi spre gateway pentru prefixul clientului, iar fiecare echipă care adaugă o subrețea mai târziu trebuie să mențină acea rută consecventă. Este un cost mic o dată și un cost recurent în zeci de conturi. Decideți cine îl plătește înainte de a promite comportamentul.

O rută nu este permisiune de a falsifica

Adăugarea unei rute de întoarcere spune subrețelei dumneavoastră unde trebuie să meargă răspunsurile. Nu îi spune țesăturii că instanța care redirecționează acele pachete are voie să le emită cu o sursă străină. În AWS controlul relevant este verificarea sursei și a destinației, iar acesta este vizibil pentru fiecare instanță:

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

Dezactivați-o doar pentru instanța al cărei rol documentat este redirecționarea, și pentru nimic altceva. Fiecare VM de aplicație care lasă verificarea activă este o mașină mai puțin care poate fi folosită pentru a emite trafic cu o sursă împrumutată. Dacă platforma dumneavoastră nu este AWS, căutați setarea echivalentă anti-falsificare sau de adrese permise în loc să presupuneți că comportamentul se transferă.

O captură rapidă de pachete rezolvă întrebarea mai repede decât citirea consolei. Dacă răspunsurile pleacă și clientul nu le vede niciodată, țesătura este cea care aruncă sursa falsificată, iar aplicația nu eșuează.

Ce cumpără traducerea și cât costă

Rescrierea sursei la gateway elimină problema căii de întoarcere. Aplicația vede o adresă pe care știe deja cum să o atingă, iar prefixul clientului nu trebuie să apară niciodată într-o tabelă de rutare a cloudului. În Linux regula este o singură linie și merită să scrieți cea mai îngustă versiune pe care o puteți:

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

Observați ce înregistrează acum aplicația: 10.40.3.10 pentru fiecare utilizator, la fiecare conexiune, pentru totdeauna. Orice listă de adrese permise construită pe acea valoare acordă acum acces întregii populații de acces la distanță, iar orice analiză a unui incident trebuie să se întoarcă la gateway pentru a răspunde cine a fost.

Soluția nu este să renunțăm la traducere, ci să încetăm să ne prefacem că adresa este o identitate. Purtați identitatea clientului într-un câmp autentificat, înregistrați-o la gateway împreună cu tuplul tradus și lăsați aplicația să se alăture pe ea. Fără cheia de alăturare, traducerea transformă o problemă de rețea într-una criminalistică permanentă.

Releul este o altă interfață

Un proxy invers în fața aplicației ocolește complet întrebarea căii rutate. Proxy-ul își deschide propria conexiune backend, așa că prefixul clientului nu trebuie să fie niciodată rutabil în rețeaua virtuală, iar aplicația poate primi identitatea într-un antet pe care proxy-ul îl setează.

Acest antet este de încredere doar când backendul îl acceptă de la proxy și de la nimic altceva. În termeni nginx asta înseamnă să numiți explicit partenerul de încredere în loc să credeți orice sosește:

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

Orice client care poate ajunge direct la backend poate falsifica același antet, așa că backendul trebuie să fie inaccesibil în afară de proxy. Acesta este un fapt de firewall, nu o opinie de configurare, și exact această presupunere o sar oamenii când copiază fragmentul.

Releul schimbă și ceea ce cumpărați. Obțineți o identitate la nivel de aplicație și un loc natural unde să o înregistrați; renunțați la generalitate, pentru că fiecare protocol nou are nevoie de propriul suport de proxy. Pentru serviciile HTTP acel schimb este de obicei bun, iar pentru orice nu este HTTP de obicei nu este deloc disponibil.

Notați ce vede fiecare frontieră

Indiferent ce alegeți, revizuirea de design ar trebui să se încheie cu un singur tabel care numește adresa sursă și identitatea demonstrabilă la fiecare salt. Fără el, primul incident produce trei echipe care descriu fiecare un client diferit.

Apoi alegeți. Păstrați când autorizarea aplicației depinde într-adevăr de adresa clientului și puteți prelua ruta. Traduceți când nu este cazul și puteți purta identitatea în afara benzii, și folosiți îndrumările AWS pentru instanțele de redirecționare pentru setările de redirecționare specifice platformei. Apelați la un releu când serviciul vorbește HTTP și doriți ca identitatea să înceteze să fie o adresă.