AWS Client VPN: autentificarea reușește, dar subrețeaua rămâne inaccesibilă

Clientul dumneavoastră afișează Connected, certificatul este valid, iar pagina de intranet se termină în continuare în timeout. Acest decalaj aproape niciodată nu este autentificare. AWS Client VPN autorizează destinațiile separat de autentificare, iar cele două cauze obișnuite sunt o valoare de grup care nu corespunde celei trimise de furnizorul de identitate și o regulă de destinație mai specifică ce învinge regula largă. Ambele sunt vizibile în configurația endpointului când știi unde să te uiți.

Autentificarea a reușit; regula nu se potrivea

Autentificarea răspunde cine este utilizatorul. Regulile de autorizare răspund la ce prefixe de rețea poate ajunge acea identitate. Un utilizator poate trece de prima și poate eșua la a doua, iar clientul nu-ți dă mult mai mult decât o conexiune care rămâne activă în timp ce fiecare cerere se termină în timeout.

Începeți prin a confirma că endpointul are o regulă de autorizare a cărei destinație conține adresa care eșuează. Dacă nu există o regulă potrivită, conexiunea se comportă corect; lipsește politica.

De unde vine de fapt valoarea grupului

În Active Directory, câmpul access-group conține SID-ul grupului, nu numele său afișat. În federația SAML, conține ID-ul sau numele grupului pe care atributul de grup SAML configurat îl poartă efectiv. Copiați valoarea din assertion sau din căutarea în director, nu de pe o pagină wiki.

Un grup IAM este un alt plan de control. Permisiunea de a administra un endpoint Client VPN nu transformă un grup IAM în grupul VPN al unui utilizator, iar lipirea unui nume de grup IAM în câmpul access-group nu îl traduce într-un SID de AD sau într-o valoare de atribut SAML.

Un grup cu nume similar într-un alt director nu dovedește nimic. Verificați metoda de autentificare a endpointului și apartenența sau assertion-ul utilizatorului în același sistem.

Câștigă prefixul cel mai lung, inclusiv 0.0.0.0/0

Autorizarea este evaluată după cea mai lungă potrivire de prefix, iar regula pentru toate destinațiile este evaluată ultima, nu prima. Adăugați o regulă 10.46.0.0/16 pentru Engineering și o regulă 0.0.0.0/0 pentru toți, iar un utilizator din afara Engineering tot nu poate ajunge la 10.46.20.10 prin regula largă.

Aici o corectare poate merge prost. Ștergerea regulii înguste restaurează accesul utilizatorului și acordă acea subrețea fiecărei identități acoperite de regula largă. Construiți matricea grup-la-rețea înainte de a șterge ceva și notați ce grupuri ar trebui să ajungă la ce interval. Aceste reguli doar permit; nu există o intrare de refuz ca să decupați o excepție dintr-o permisiune largă.

Modificările au nevoie și de o conexiune nouă pentru a fi judecate corect. Reconectați clientul după editarea regulilor, apoi testați din nou.

Separați autorizarea de calea datelor

O regulă care se potrivește nu este o rută. Endpointul are nevoie de o subrețea asociată și de o intrare în tabela de rutare pentru destinație, iar grupul de securitate al resursei țintă trebuie să accepte traficul. Traficul de retur și DNS trebuie și ele să funcționeze.

Testați un utilizator care ar trebui să reușească și unul care ar trebui să rămână exclus. Ambii se pot autentifica în timp ce doar unul ajunge la subrețea, iar acea diferență este dovada pe care o vrei.

Dacă o adresă IP funcționează, dar un nume de gazdă nu, uită-te la resolver înainte de a atinge autorizarea. Dacă nicio rută nu acoperă adresa, corectează asocierea sau tabela de rutare. Dacă pachetul ajunge și serviciul îl refuză, politica acelui serviciu este următoarea oprire. Lărgirea matricei de autorizare la toți utilizatorii ascunde care dintre acele straturi era de fapt stricat.

Înainte de a închide tichetul, notează sursa identității, valoarea exactă a grupului, prefixele de destinație și ruta care transportă traficul. Acea notă transformă următorul raport de conectat dar fără acces într-o comparație de două minute în loc de încă o rundă de presupuneri.