Tunel complet Access Server pe EC2: de ce o singură casetă nu este suficientă

Dezactivarea verificării sursei și destinației pe o instanță EC2 este răspunsul cel mai repetat la întrebările despre ieșirea în internet a Access Server și, singură, nu face nimic pentru clienții dvs. Verificarea este o constrângere de forwarding din AWS: face instanța să accepte pachete a căror sursă sau destinație nu este propria adresă. Nu îi spune clientului Access Server să trimită traficul de internet prin tunel, nu creează o rută în amonte și nu adaugă NAT. Mitul este că bifa este funcția în sine.

Ce controlează de fapt verificarea

Fiecare interfață de rețea EC2 aruncă traficul care nu îi este adresat, cu excepția cazului în care instanța acționează ca router, dispozitiv NAT sau gateway VPN și dezactivați acea verificare. Dezactivarea ei acordă permisiunea de a forwarda. Permisiunea nu este configurație: instanța are în continuare nevoie de o rută către un gateway de internet sau un dispozitiv NAT, tabelul de rute al VPC are nevoie în continuare de intrarea corespunzătoare, grupurile de securitate trebuie să permită în continuare fluxul, iar serverul trebuie să traducă sau să ruteze traficul de retur.

Verificați valoarea curentă cu aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck înainte de a schimba ceva. Dacă o modificați în consolă, modificați-o pentru că instanța forwardează pentru alții, nu pentru că un client nu ajunge la internet.

Politica de rutare a clientului aparține Access Server

În Access Server 3, deschideți Access Controls și găsiți secțiunea Internet Access and DNS. Selectorul Internet Gateway oferă tunel complet sau tunel divizat; tunelul complet îi spune clientului să ruteze traficul implicit în VPN, tunelul divizat lasă traficul de internet pe calea locală a clientului. Salvați și aplicați prin fluxul de lucru al produsului, apoi reconectați un client de test, deoarece politica este livrată în momentul conexiunii.

Versiunile mai vechi folosesc alte meniuri, iar unele build-uri Community de OpenVPN nu au un control echivalent. Verificați versiunea majoră instalată înainte de a căuta un ecran care nu există. Apoi confirmați ce a primit clientul: un profil de tunel complet ar trebui să instaleze o rută implicită prin tunel, iar un profil de tunel divizat nu ar trebui.

Urmăriți pachetul după tunel

După ce clientul trimite traficul de internet în tunel, serverul trebuie să îl forwardeze și de obicei să îl traducă. Access Server își gestionează propriile reguli NAT și de rutare, așa că citiți configurația efectivă în loc să adăugați reguli Community OpenVPN la fișierele generate; regulile negestionate sunt suprascrise sau intră în conflict la următoarea actualizare a produsului. sudo iptables -t nat -L -n -v sau echivalentul nftables arată ce se traduce de fapt.

Partea AWS este o cale separată. O instanță într-o subrețea publică ajunge direct la un gateway de internet și își păstrează adresa publică sau IP-ul elastic. O instanță într-o subrețea privată are nevoie de o rută către un gateway NAT sau o instanță NAT, iar dispozitivul NAT are nevoie de propria rută către gateway-ul de internet. Atașarea unui gateway de internet la VPC nu oferă singură nicio adresă publică de retur unei surse private, de aceea aceeași configurare Access Server funcționează într-o subrețea și eșuează silențios în alta.

Verificați tabelul de rute asociat subrețelei instanței, nu doar tabelul principal al VPC. Asocierile de subrețea au prioritate față de tabelul principal, iar o asociere învechită este o cauză comună pentru care o configurație funcțională se oprește după o reconstrucție.

Țineți ieșirea IP și DNS separate

Testați mai întâi un literal de adresă, apoi un nume, din aceeași aplicație client. Dacă curl -4 https://checkip.amazonaws.com returnează o adresă publică dar numele de gazdă eșuează, tunelul și calea NAT funcționează, iar problema este DNS: resolverul trimis, starea resolverului clientului sau un grup de securitate care blochează resolverul. Setările DNS ale Access Server sunt în aceeași zonă Internet Access, dar călătoresc pe o cale de cod diferită.

Comparați adresa returnată cu ieșirea pe care o intenționați. Dacă este adresa publică a instanței, traficul este tradus de instanță; dacă este o adresă de gateway NAT, se folosește calea subrețelei private. Ambele pot fi corecte. Ce nu puteți concluziona este că un browser de pe server dovedește forwardingul pentru client.

Nu lăsați o casetă să închidă investigația

IPv6 este o decizie separată. O politică de tunel complet pentru IPv4 nu spune nimic despre dacă IPv6 este transportat, blocat sau scurs, iar un client cu două stive poate continua să folosească calea IPv6 locală în timp ce IPv4 merge prin tunel. Testați familia de adrese care vă interesează cu adevărat și decideți explicit dacă cealaltă ar trebui dezactivată.

În final, testați starea deconectată. Selectarea tunelului complet descrie politica de rutare cât timp sunteți conectat, nu ce se întâmplă când tunelul cade. Dacă cerința este ca niciun trafic să nu scape în afara VPN, aceasta este o chestiune de kill-switch și firewall și are nevoie de propriul test, nu de o deducție din tabelul de rute.