AWS Client VPN sau un bastion pentru a ajunge la un VPC cu peering

Un singur endpoint Client VPN poate ajunge la un VPC care are peering cu VPC-ul asociat, și nu aveți nevoie de un bastion pentru a face asta legitim. Alegerea care merită făcută este unde traficul schimbă mâinile: o rută de endpoint care aterizează în subrețeaua de asociere și traversează conexiunea de peering, sau un host în VPC-ul cu peering care încheie sesiunea. Ambele căi funcționează și eșuează în locuri diferite, deci decizia este despre proprietate și audit, nu despre ce permite AWS. Iată cum aleg între ele, și cele patru intrări care fac calea rutată să funcționeze.

Două căi, un endpoint, proprietari diferiți

Pe calea rutată, traficul clientului ajunge la endpoint, este tradus în adresa interfeței de rețea Client VPN din subrețeaua de asociere și părăsește acea subrețea prin conexiunea de peering de la A la B. VPC B nu încheie nicio sesiune VPN; vede trafic obișnuit din VPC A, de aceea ruta sa de retur indică VPC A, nu pool-ul de clienți.

Pe calea prin bastion, clientul ajunge mai întâi la un host. Un bastion în A lasă în continuare ultimul salt să traverseze conexiunea de peering, așa că păstrați munca de peering și adăugați o sesiune. Un bastion în B are nevoie și el de o cale de la client, iar când acea cale este aceeași rută de endpoint, aveți designul rutat plus un salt. Bastionul elimină muncă doar când există deja, este deja aprobat, iar lucrul din spatele lui are nevoie de o graniță de sesiune, nu de una de rețea.

Patru intrări fac calea rutată să funcționeze

AWS documentează acest scenariu pe pagina Client VPN how-it-works, iar în practică se reduce la patru intrări deținute de două sau trei echipe. Intervalele sunt ilustrative; intervalul cu peering trebuie să fie unic, iar intervalul de retur trebuie să corespundă planului dumneavoastră.

Ruta și permisiunea sunt controale separate. O rută de endpoint corectă fără regula de autorizare potrivită nu îi dă nimic clientului; o regulă de autorizare pentru o destinație pe care endpointul nu o poate ruta îi dă o gaură neagră. Ambele trebuie să numească același interval.

Ruta endpointului indică o subrețea din propriul VPC al endpointului, niciodată conexiunea de peering. Tabelele de rute ale VPC indică conexiunea de peering, niciodată o instanță sau o interfață. Copierea unei valori între cele două se salvează fără reclamații și nu rutează nimic.

Deoarece subrețeaua de asociere traduce sursa clientului, B trebuie să ruteze înapoi la VPC A, nu la pool-ul de clienți. Trimiterea intervalului de clienți prin conexiunea de peering pare simetrică, trece de revizie și eșuează în tăcere pentru că B nu vede niciodată un pachet cu sursă de client.

Grupuri de securitate și ultimul metru de permisiune

Rutarea aduce pachetele în B; B încă decide. Pentru o conexiune de peering activă în aceeași regiune, un grup de securitate din B poate referi grupul aplicat asocierii Client VPN, ceea ce ține regula îngustă și rezistă la schimbările de adresă. Acolo unde o referință la grup nu este fezabilă, permiteți explicit intervalul subrețelei de asociere în loc să îl lărgiți la 0.0.0.0/0, ceea ce transformă o eroare de rutare într-un timeout neexplicat.

Apoi verificați ceea ce rutarea nu atinge niciodată: ACL-urile de rețea pe ambele subrețele, lista de permisiuni sau audiența tokenului aplicației, și DNS. Peering nu copiază zone găzduite private, așa că laptopul poate păstra o rută funcțională către o adresă pe care nu o poate rezolva, iar o conexiune de peering nu adaugă încredere unui certificat. Îndreptați endpointul către un resolver care răspunde pentru B, apoi confirmați că numele privat și certificatul se potrivesc.

Când bastionul este răspunsul onest

Păstrez trei declanșatoare pentru alegerea deliberată a unui bastion. VPC-ul cu peering aparține unei echipe care nu va adăuga o rută de retur pentru intervalul dumneavoastră sau nu va accepta o referință la grup. Accesul trebuie aprobat sau înregistrat pentru fiecare sesiune, iar aplicația nu poate duce asta singură. Sau ultimul salt trebuie să rămână în B pentru că serviciul se rezolvă doar acolo, iar identitatea lui TLS este fixată de un nume intern.

Nimic din toate acestea nu este o ocolire a faptului că peering nu este tranzitiv. Netranzitivitatea limitează ce pot face resursele din B: nu pot folosi A ca tranzit către un al treilea VPC cu care A are peering. Nu a însemnat niciodată că un utilizator VPN nu poate ajunge la un VPC cu peering direct, iar un bastion construit pentru a ocoli această citire greșită este un host care se patch-uiește fără motiv.

Eroarea inversă costă mai mult în timp: treceți fiecare echipă prin singurul bastion care există deja, apoi descoperiți că grupul lui de securitate, tabelul de rute și fereastra de patch sunt dependența de producție. Notați cărui declanșator îi servește hostul și retrageți-l când declanșatorul dispare.

Transit Gateway și mai multe asocieri schimbă aritmetica

Dacă endpointul este conectat direct la un Transit Gateway în loc de o subrețea, modelul se schimbă: clienții nu mai sunt traduși într-o adresă de interfață într-o subrețea de asociere, iar tabelele de rute ale gateway-ului trebuie să poarte intervalul de clienți plus conexiunea care duce la VPC-ul cu peering. Este mai curat la scară, dar munca se mută de la patru intrări la tabelele de rute ale gateway-ului.

Mai multe asocieri multiplică verificările. Ruta endpointului aparține endpointului, însă fiecare subrețea de asociere are nevoie de un tabel de rute cu un următor salt de peering real. O sesiune poate reuși printr-o asociere în timp ce alta nu are cale de retur, așa că testați fiecare.

Ordinea de verificare care găsește rapid ruptura

Executați-le în ordine; fiecare pas poate trece în timp ce următorul eșuează, iar un timeout al clientului aproape niciodată nu spune care s-a rupt.

1. Rezolvați numele aplicației de la client și verificați că adresa este în intervalul cu peering.
2. Conectați-vă, apoi citiți jurnalul de conexiuni al endpointului pentru asocierea care a încheiat sesiunea.
3. Pe acea subrețea de asociere, confirmați că tabelul de rute îndreaptă intervalul cu peering către o conexiune de peering activă.
4. Pe subrețeaua de resurse din B, confirmați o intrare de retur pentru intervalul interfeței și reguli de grup potrivite.
5. Testați o operație permisă și o resursă care trebuie să rămână inaccesibilă; a doua prinde resturile de depanare.
6. Reconectați-vă după orice schimbare a rutei split-tunnel, pentru că un tunel aflat în funcțiune nu va prelua un set nou de rute.

Două simptome merită reținute. Un SYN care ajunge la B fără răspuns este aproape întotdeauna ruta de retur lipsă. O conexiune care se finalizează și apoi se resetează este de obicei grupul, ACL-ul sau aplicația. Niciunul nu apare în jurnalul endpointului ca cauză, așa că păstrați cele patru intrări cu un proprietar lângă fiecare.

Dacă niciunul dintre cele trei declanșatoare nu se aplică, finalizați calea rutată și înregistrați cele patru intrări. Dacă unul se aplică, păstrați bastionul doar pentru acea graniță și lăsați ruta endpointului pentru serviciile care nu au nevoie de o sesiune în față.