AWS Client VPN cu tunel divizat: ce rute ar trebui publicate

Consola oferă un comutator pentru tunelul divizat, așa că decizia pare o casetă de bifare. Nu este. Ce ajunge efectiv la client este setul de rute publicate al punctului final, iar acea listă decide ce prefixe private folosesc tunelul, dacă traficul general de internet rămâne local sau iese prin AWS și cu ce resolver mai poate vorbi clientul. Trei întrebări rezolvă proiectarea, și fiecare poate primi un răspuns prost în timp ce conexiunea reușește totuși.

Un indicator de tunel divizat nu este o listă de destinații

AWS descrie tunelul divizat ca adăugarea rutelor punctului final în tabela de rute a clientului la stabilirea conexiunii. O rută către VPC-ul privat limitează tunelul la acea destinație; restul urmează calea obișnuită a clientului. O rută implicită este o instrucțiune diferită cu efect diferit, de aceea documentația tunelului divizat avertizează împotriva publicării 0.0.0.0/0 pe un punct final configurat pentru acest mod: de obicei rupe conectivitatea în loc să o extindă. Tabela de rute a punctului final este politica, iar tabela de rute a clientului este rezultatul pe care îl puteți inspecta.

Citiți tabela de rute a punctului final și rutele instalate ale clientului împreună. Eticheta descrie o intenție; rutele descriu ce se întâmplă.

Prima decizie: traficul general de internet ar trebui să rămână local?

Dacă navigarea trebuie să folosească conexiunea proprie a utilizatorului, publicați doar destinațiile private de care are nevoie munca și opriți-vă acolo. Nu adăugați o rută de internet pentru că un tutorial de tunel complet includea una și nu presupuneți că ruta suplimentară îmbunătățește securitatea. Schimbă calea, nu adaugă o politică și de obicei costă o latență pe care nu ați bugetat-o.

Dacă traficul de internet trebuie să iasă prin AWS, construiți arhitectura documentată de acces la internet: ruta punctului final, regulile de autorizare, calea subrețelei asociate, politica de securitate și o ieșire superioară funcțională. O rută implicită singură nu oferă nimic din toate acestea.

A doua decizie: ce prefixe private și autorizate de cine?

Publicați cel mai mic set de destinații care deservește încărcarea reală și verificați că fiecare subrețea asociată poate ruta către ele. Ținta rutei punctului final și rutarea VPC a subrețelei sunt straturi diferite, iar o rută care există într-unul nu este dovadă despre celălalt. Autorizarea este din nou separată: o destinație poate fi accesibilă și totuși refuzată pentru că grupul clientului nu are o regulă care o permite.

Testarea unei singure sesiuni reușite dovedește o singură cale. Verificați fiecare subrețea asociată, pentru că o asociere de subrețea adăugată mai târziu este exact locul unde se află de obicei ruta lipsă.

Când o destinație trebuie să fie accesibilă după nume, observați că următoarea întrebare este rezolvarea numelor, nu ruta.

A treia decizie: ce resolver urmează tunelul?

Un client poate primi un server DNS accesibil doar prin VPN, iar acel resolver funcționează doar dacă adresa lui este ea însăși într-o rută autorizată. Verificați ambele jumătăți: adresa resolverului urmează o rută publicată, iar serverul răspunde numelor pe care le cere aplicația. O cerere care reușește după adresă, dar eșuează după numele gazdei, indică denumirea, nu rutarea, iar depanarea tunelului în acest caz irosește după-amiaza.

Numele publice ar trebui să se rezolve ca înainte de conexiune, ceea ce este încă un motiv să fiți precizi cu privire la ce publicați.

Schimbați setul de rute, apoi verificați ambele lumi

AWS documentează că schimbarea rutelor pe un punct final de tunel divizat resetează conexiunile clienților. Planificați schimbarea având asta în minte: aplicați-o, reconectați-vă prin clientul acceptat și citiți din nou rutele instalate în loc să vă bazați pe starea aplicată înainte de editare. Starea aplicată învechită este cel mai frecvent motiv pentru care o schimbare corectă pare stricată.

Acceptați proiectarea doar când o resursă privată și o destinație publică se comportă conform intenției, după nume și după adresă, în familiile de adrese pe care le susțineți cu adevărat. Un tunel care autentifică nu este același lucru cu un tunel care împarte corect.

Scrieți lista de rute în runbook lângă raționament, astfel încât următoarea persoană să poată distinge o excludere intenționată de una uitată.