Acces intermitent cu AWS Client VPN: auditați fiecare subrețea asociată

Un utilizator se conectează, deschide aplicația internă și primește un răspuns; un coleg de pe același punct final primește un timeout de pe un laptop identic, în aceeași rețea Wi-Fi. Acest tipar este semnătura unui punct final client VPN cu mai multe subrețele asociate, unde căile nu sunt echivalente. Parcurg asta de la consolă spre exterior, pentru că două file decid dacă restul investigației merită. Nimic din configurația clientului nu explică asta.

Începeți de la punctul final și listați asocierile

În consola VPC, deschideți Client VPN endpoints, alegeți punctul final și citiți fila Associations. Fiecare asociere este o subrețea într-o zonă de disponibilitate, iar clientul aterizează pe cea pe care o alege serviciul când se construiește conexiunea. Notați ID-urile subrețelelor și tabelul de rute pe care fiecare îl folosește efectiv, pentru că aceste două liste sunt comparația pe care urmează să o faceți.

Dacă punctul final arată o singură asociere, această teorie este greșită, iar clientul este suspectul mai bun.

Comparați tabelul de rute al punctului final cu fiecare asociere

Deschideți fila Route table pe același punct final. Fiecare CIDR de destinație are acolo o țintă, iar la un client VPN ținta este o asociere, nu o poartă. AWS cere o intrare de destinație pentru fiecare subrețea asociată, așa că o rută care vizează doar una dintre ele face accesul dependent de locul unde a aterizat sesiunea. Verificați destinația care vă interesează cu adevărat, apoi regula ei de autorizare, pentru că ruta oferă calea, iar regula decide cine o poate folosi.

După ce tabulați ambele straturi, defecțiunea este greu de ratat.

Al doilea rând este întreaga eroare în majoritatea tichetelor. Ruta punctului final există, așa că nimeni nu se uită mai departe, iar pachetul moare un hop mai târziu în interiorul VPC-ului.

Urmați fiecare subrețea până la tabelul ei de rute efectiv

O subrețea fără asociere explicită la un tabel de rute moștenește tabelul principal al VPC-ului. Citiți tabelul care este efectiv în vigoare, nu pe cel al cărui nume pare corect, și comparați destinația și ținta, nu eticheta din rând.

Ghidul AWS despre accesul intermitent descrie asta ca acoperire a rutelor între asocieri, care este modelul corect. Punctul final duce pachetul la o subrețea, iar tabelul acelei subrețele trebuie încă să știe unde se află rețeaua aplicației.

Corectați rândul lipsă în tabelul care îl deține. Copierea unui tabel de rute întreg dintr-o subrețea funcțională copiază și alegerile de internet, aparat și izolare care nu au fost niciodată menite pentru aceasta, iar acest schimb este de obicei mai rău decât întreruperea cu care ați început.

Verificați regulile de autorizare, apoi calea de întoarcere

Regulile de autorizare sunt pe destinație și pe grup și sunt evaluate separat de rute. O destinație cu rute peste tot dar fără regulă pentru grupul utilizatorului se comportă ca o gaură neagră cu un tabel de rute care pare sănătos.

Calea de întoarcere merită aceeași atenție. O conexiune peering are nevoie de o rută în VPC-ul aplicației care să indice înapoi spre CIDR-ul clientului, de reguli ale grupurilor de securitate care să permită traficul la ambele capete și de ACL de rețea care să nu îl arunce. Accesibilitatea într-o singură direcție, când ping funcționează iar strângerea de mână TCP nu, indică de obicei un ACL sau un grup de securitate, nu VPN-ul.

Grupurile de securitate ale punctului final se află pe interfețele de rețea elastice ale asocierii, așa că o regulă care permite portul aplicației din CIDR-ul clientului trebuie atașată asocierii, nu doar instanței.

Verificați cu o reconectare, nu cu o cerere norocoasă

Cu split tunnel, rutele punctului final sunt trimise când conexiunea este stabilită, așa că un set de rute modificat nu ajunge niciodată la un client care rămâne conectat. Deconectați-vă și reconectați-vă prin clientul acceptat, apoi confirmați că rutele noi sunt prezente pe mașină.

În final, corelați jurnalul conexiunilor cu adresa primită de client și repetați testul de suficiente ori încât să atingeți mai mult de o asociere. O singură cerere reușită după o corecție demonstrează că o cale funcționează, iar tichetul era despre cealaltă.