De ce EC2 nu poate ajunge la laptopul tău AWS Client VPN
Client VPN traduce sursele IPv4 ale clientului în interfața endpointului. De aceea răspunsul funcționează, iar o conexiune nouă din EC2 nu.
Un laptop conectat prin AWS Client VPN ajunge la o aplicație EC2 fără probleme. Apoi încerci invers, din EC2 către adresa atribuită clientului, iar conexiunea se blochează sau este refuzată. Această asimetrie este rareori o regulă lipsă de grup de securitate. Pe un endpoint Client VPN asociat cu subrețele VPC, AWS traduce sursele IPv4 ale clientului în interfața de rețea a endpointului, așa că nu există nicio adresă VPC de intrare care să reprezinte laptopul tău.
Începe cu ce arată captura
Fă o captură pe gazda EC2 în timp ce clientul se conectează și citește adresa sursă pe care aplicația o vede efectiv. Dacă este interfața endpointului din partea VPC și nu o adresă din pool-ul de clienți, traducerea este confirmată înainte de a schimba o singură regulă.
Pool-ul de clienți este un interval de alocare, nu o subrețea cu rută de retur. Exact la această distincție greșesc cele mai multe astfel de investigații.
Traducerea care explică asimetria
Trei fluxuri sunt confundate între ele, și doar unul dintre ele este cel pe care oamenii îl testează.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Descrierea componentelor Client VPN spune clar că sursele IPv4 ale clientului sunt traduse în interfața endpointului, ceea ce este suficient pentru a vedea de ce rândul din mijloc nu are cu ce să se potrivească.
O conexiune nouă are nevoie de o rută, de un pas de rezolvare a adresei și de o decizie de autorizare. Starea de traducere din sesiunea altcuiva nu oferă niciuna dintre cele trei.
De ce un răspuns nu este o conexiune nouă
Un răspuns TCP este potrivit cu o intrare existentă, de aceea calea de retur funcționează fără nicio regulă de intrare. Un SYN nou de pe gazda EC2 nu are nicio intrare cu care să se potrivească, așa că devine o încercare de ieșire obișnuită către o destinație la care VPC nu știe cum să ajungă.
De aceea este înșelător și să descrii asta ca trafic care merge doar într-o singură direcție. Traficul de retur curge continuu în aceste sesiuni. Partea fără cale este inițierea.
Ce încă rupe o sesiune care ar trebui să funcționeze
Grupurile de securitate, ACL-urile de rețea și firewall-ul laptopului însuși contează toate pentru conexiunile care ar trebui să reușească. Un ping eșuat spune cel mai puțin, pentru că politica ICMP este adesea separată de politica TCP care te interesează.
Scrie aceste reguli în funcție de sursa tradusă, nu de adresa clientului. Regulile legate de adresa care nu apare niciodată în rețea sunt cea mai frecventă defecțiune auto-provocată din acest design.
Când VPC trebuie într-adevăr să înceapă conversația
Dacă un serviciu trebuie să notifice o stație de lucru, inversează direcția și lasă clientul să mențină un canal de ieșire persistent la care serviciul răspunde. Dacă o întreagă rețea la distanță trebuie să fie accesibilă din VPC, alege o arhitectură care își publică prefixele și politica de acces în loc să presupui că Client VPN face deja asta. Accesul client-la-client este un al treilea caz, mai îngust, cu propriile obiecte de rută și autorizare. Niciunul dintre acestea nu este doar o bifă pe endpointul existent.
Păstrează onest și domeniul explicației IPv4. Documentația AWS actuală separă IPv6, unde acea traducere nu se aplică, și alte modele de conectare care rutează diferit.
Testează în trei pași etichetați: clientul deschide o sesiune permisă, serviciul din VPC răspunde acelei sesiuni, iar o gazdă din VPC deschide o sesiune nouă către client. Faptul că primele două reușesc, iar a treia eșuează este forma așteptată a acestui design, nu un defect de urmărit cu reguli de firewall.