LAN în spatele unei sesiuni AWS Client VPN: ce se redirecționează

Laptopul se conectează la punctul final AWS Client VPN, ajunge în subrețeaua privată și totul pare sănătos. Desktopul din același LAN nu ajunge nicăieri, deși gazda Linux are și o interfață de punte și ambele mașini sunt pe același cablu. Nimic nu este configurat greșit în tunel; piesa lipsă este rutarea, iar puntea este o pistă falsă.

Extinderea unei sesiuni Client VPN la un LAN este un rol de poartă. Nu este un segment Ethernet întins într-un serviciu gestionat.

Gazda funcționează, iar LAN-ul nu

Interfața de tunel de pe mașina Linux are o adresă în CIDR-ul clientului Client VPN, iar punctul final a împins rute pentru intervalele VPC. O cerere făcută pe acea mașină este trafic generat local: alege o rută, iese prin tunel și primește un răspuns. Acea cale nu atinge niciodată codul de redirecționare, interfața LAN sau vreo regulă de firewall care guvernează tranzitul.

Traficul de la un alt dispozitiv din LAN este un flux diferit. Ajunge pe interfața LAN, are nevoie de o rută care indică în tunel, are nevoie de redirecționare activată, are nevoie de un firewall care să îl permită și are nevoie ca răspunsul să se întoarcă prin aceeași gazdă. Patru cerințe, iar testul care funcționează pe laptop nu demonstrează niciuna. De pe desktop defectul pare bizar: tunelul este activ, acreditările sunt valide, iar destinația pur și simplu nu răspunde niciodată. Defectul este local în calea de redirecționare a porții, nu în serviciu.

Nu orice client poate fi o poartă

AWS afirmă că aplicația sa desktop Client VPN nu acceptă redirecționarea IP, iar alți clienți ar putea. Această restricție decide arhitectura înainte de a fi tastată vreo comandă. Dacă singurul client disponibil este aplicația desktop oficială, o poartă Linux care redirecționează pentru LAN nu este o configurație pe care o puteți termina, iar nicio cantitate de masquerading nu va schimba asta.

Clientul de înlocuire trebuie să se potrivească și cu metoda de autentificare a punctului final și cu politica pe care intenționați să o aplicați. Punctele finale bazate pe certificate, pe director și pe SAML nu acceptă aceleași configurații de client, iar un client terț care se autentifică dar ignoră rutele împinse nu este o îmbunătățire.

Tratați alegerea clientului ca parte a revizuirii de design. Ea determină dacă modelul de redirecționare LAN este disponibil deloc și determină ce identitate vede punctul final pentru fiecare dispozitiv din spatele porții. Înregistrați clientul și configurația punctului final față de care a fost testat. O schimbare de client șase luni mai târziu poate elimina în tăcere capacitatea pe care designul o presupunea.

Direcționați LAN-ul spre tunel și traduceți-l

Cu un client acceptat la locul lui, restul este muncă obișnuită de poartă. Dispozitivele LAN au nevoie de o rută pentru intervalul VPC care indică gazda Linux, iar gazda are nevoie de redirecționare activată. Dacă doriți ca VPC-ul să vadă traficul ca clientul conectat și nu ca o adresă LAN arbitrară, traduceți sursa la ieșire.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Limitați regula la interfața de tunel și la intervalul VPC, ca mai sus, în loc să faceți masquerading pentru tot ce redirecționează gazda. Regula mai îngustă este mai ușor de gândit și nu schimbă în tăcere traficul care trebuia să își păstreze adresa de sursă originală.

Lăsați ruta LAN să vină automat dacă puteți: o opțiune DHCP, un anunț de router sau o rută statică împinsă de ceea ce gestionează LAN-ul. O rută care există doar pe o singură mașină de test va face designul să pară stricat în momentul în care altcineva îl încearcă.

Și răspunsul are nevoie de o cale

Odată ce cererea ajunge la VPC, răspunsul trebuie să se întoarcă prin aceleași stări de traducere și să găsească ruta LAN pe poartă. Acea parte funcționează de obicei când regula de masquerading este la locul ei, pentru că maparea trăiește pe gazda care a făcut-o. Se rupe când partea VPC are o rută care trimite răspunsul în altă parte, și de aceea contează atât ruta CIDR a clientului, cât și asocierea de subrețea la punctul final.

Uitați-vă la contoare, nu doar la ping. O regulă de masquerading cu zero pachete vă spune că cererea nu a ajuns niciodată la interfața de tunel, ceea ce indică înapoi la ruta LAN sau la tabela de rutare a clientului însuși. O regulă cu pachete dar fără răspunsuri indică partea VPC, regulile de autorizare sau un grup de securitate care nu acceptă sursa tradusă. Citiți ambele direcții înainte de a schimba ceva, pentru că o numărătoare care crește doar pe o parte este o cale cu sens unic, nu una lentă.

Amintiți-vă că punctul final este un serviciu gestionat. Nu există fișier de configurare a serverului de editat și nicio directivă client-config de adăugat, așa că instrucțiunile scrise pentru un server OpenVPN autogestionat cu rute personalizate de subrețea de client nu se transferă. În AWS pârghiile sunt asocierea de subrețea, regulile de autorizare și tabelele de rutare ale VPC-ului.

Identitatea partajată este partea la care politica trebuie să răspundă

Fiecare dispozitiv din spatele porții folosește sesiunea VPN a porții. Regulile de autorizare ale punctului final acordă acces unui utilizator sau unui grup, iar din punctul de vedere al serviciului există exact un utilizator pe acea sesiune. Redirecționarea locală nu multiplică acea identitate în autentificare per dispozitiv și nu extinde verificările de postură a dispozitivului la imprimanta din colț.

Asta poate fi acceptabil, sau poate fi motivul pentru care designul este respins. Depinde de ce presupun resursele VPC despre cine apelează. O identitate partajată care se potrivește modelului de autorizare este în regulă; una care transformă în tăcere o singură sesiune autentificată în acces la tot LAN-ul este o constatare care așteaptă să fie scrisă.

Dacă cerința este într-adevăr conectarea unui întreg amplasament la un VPC, comparați un design acceptat amplasament-la-amplasament înainte de a extinde un client de acces la distanță. Semantica diferă, iar o sesiune de client cu NAT este un substitut slab pentru o legătură de amplasament când VPC-ul trebuie să inițieze conexiuni în LAN.

Decideți clientul, ruta, traducerea și povestea identității în această ordine. Fiecare îl constrânge pe următorul, iar ordinea explică de ce gazda funcționează în timp ce LAN-ul nu.