AWS Client VPN conectat, dar fără acces la internet: verificarea rutelor

AWS Client VPN conectat fără acces la internet? Verificați rutele clientului, autorizarea endpointului, ieșirea subrețelei și DNS în această ordine.

Sunteți conectat la endpointul AWS Client VPN, subrețeaua privată răspunde, și totuși fiecare pagină publică se termină în timeout. Această combinație reduce problema la unul dintre cele trei obiecte din partea administrată: ruta pe care clientul o instalează, ruta endpointului împreună cu regula sa de autorizare, sau următorul salt al subrețelei asociate. Le verific în această ordine, pentru că fiecare eșec arată diferit din partea clientului. Acest ghid acoperă endpointul administrat asociat cu un VPC, nu un server OpenVPN pe o instanță EC2 și nici o conexiune Cloud WAN sau Transit Gateway.

Începeți cu ceea ce clientul rutează de fapt

O stare conectată dovedește sesiunea TLS și alocarea CIDR clientului, nimic mai mult. Întrebați sistemul de operare încotro ar merge o adresă publică în timp ce tunelul este activ. În Linux, ip route get 1.1.1.1 ar trebui să numească interfața tunelului; în macOS, netstat -rn -f inet | head -5 arată intrarea implicită; în Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 afișează interfața aleasă și următorul salt.

Apoi citiți indicatorul split-tunnel, pentru că el decide dacă rutele publicate de endpoint sunt singurele destinații pe care clientul le trimite în tunel:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Când SplitTunnel este true, o destinație publică folosește tunelul doar dacă endpointul publică o rută care o acoperă, așa că o 0.0.0.0/0 lipsă lasă acel trafic pe interfața locală. Când este false, clientul captează traficul, dar endpointul tot trebuie să îl ruteze și să îl autorizeze; altfel pachetele intră în tunel și se opresc acolo. Reconectați clientul după modificarea oricăreia dintre cele două setări, pentru că rutele și serverele DNS sunt livrate la momentul conectării, iar un client care rulează poate păstra setul vechi.

Citiți ruta endpointului și regula de autorizare separat

Sunt două obiecte, iar crearea unuia nu îl creează pe celălalt. Listați rutele endpointului și căutați o rută implicită a cărei țintă este o subrețea asociată:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Fiecare rută are exact o subrețea țintă, deci trei asocieri au nevoie de câte o rută implicită corespunzătoare. AWS documentează această cerință de acoperire, iar simptomul practic al unei lipsuri este un utilizator care lucrează dintr-o subrețea și se blochează din alta, ceea ce se citește ca o defecțiune intermitentă în loc de o rută lipsă. Documentația oficială a scenariului Client VPN descrie aranjamentul cu subrețea publică căruia îi aparțin aceste rute.

Autorizarea este al doilea obiect. Când nicio regulă nu acoperă destinația publică, tunelul transportă pachetul și serviciul îl aruncă, așa că resursele private continuă să funcționeze, iar internetul nu:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

O regulă pentru CIDR-ul VPC nu spune nimic despre 0.0.0.0/0. Adăugarea părților lipsă pentru un tunel complet înseamnă o rută pe fiecare subrețea asociată plus o regulă de autorizare pe care o puteți audita mai târziu:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all acordă destinația fiecărui client al endpointului, așa că păstrați-o doar cât timp tunelul trebuie să fie complet; o regulă legată de un grup de director este preferabilă când aveți grupuri la care să o legați.

Urmați pachetul în afara subrețelei asociate

Ruta endpointului decide că AWS predă pachetul acelei subrețele. Nu decide următorul salt de după ea, care trăiește în tabelul de rute VPC al subrețelei:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

O rută implicită utilizabilă indică un internet gateway pentru o subrețea publică, sau un NAT gateway pentru una privată, iar o stare blackhole înseamnă că ținta a fost ștearsă și calea moare acum în tăcere. Acestea sunt alte tabele decât lista de rute a endpointului, iar repararea uneia nu o repară pe cealaltă.

Pe acest salt stau două filtre. Grupul de securitate aplicat asocierii de rețea țintă trebuie să permită traficul de ieșire către destinația publică, iar orice ACL de rețea aplicabil trebuie să permită cererea și traficul de retur pe porturi efemere. Un grup de securitate de asociere restrictiv este o cauză frecventă pentru care accesul privat funcționează, iar cel public nu.

Alegeți primul strat după simptom în loc să le schimbați pe toate trei deodată:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

Separați eșecul DNS de o rută moartă

Rezolvarea numelor eșuează altfel decât forwardingul, iar tunelul complet face diferența importantă pentru că acum se ajunge la resolverul împins prin tunel. Dacă endpointul specifică servere DNS ale VPC, adresele lor au nevoie de acoperire de rută și autorizare ca orice altă destinație. Întrebați resolverul direct ca să vedeți care eșec este: dig +short example.com @10.0.0.2, sau nslookup example.com 10.0.0.2 în Windows.

Când un URL numeric răspunde și unul cu nume nu, opriți editarea rutei implicite și lucrați la DNS. O cerere către o adresă IP nu dovedește nimic despre un host virtual cu nume și certificatul lui, așa că păstrați un test cu nume în verificarea finală.

Timpul ajută. O conexiune TCP care nu primește răspuns în câteva secunde indică rutarea sau un filtru, în timp ce o cerere care atârnă în căutarea numelui indică resolverul. Schimbarea rutei implicite cât timp resolverul este inaccesibil transformă de obicei un eșec în două.

Reveniți curat și apoi verificați calea de ieșire

Ambele obiecte au fost aditive, deci revenirea este ștergere, nu reparare:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Reconectați-vă și confirmați pe ce cale iese traficul. Comparați adresa publică observată cu adresa IP elastică a NAT gateway-ului, sau cu internet gateway-ul pe care intenționați să îl folosiți, și verificați că o resursă privată încă răspunde în aceeași sesiune.

Încheiați cu o listă scurtă și tratați ultimul punct ca parte a schimbării, nu ca documentație:

  • O 0.0.0.0/0 rută de endpoint pentru fiecare subrețea asociată.
  • O regulă de autorizare care acoperă 0.0.0.0/0 pentru clienții pe care vreți să îi deserviți.
  • O rută implicită VPC care nu este în starea blackhole pe fiecare subrețea asociată.
  • Ieșirea grupului de securitate al asocierii, plus traficul de retur ACL.
  • Adrese ale resolverului rutate și autorizate, verificate cu o cerere cu nume.
  • O revenire înregistrată pentru rută și regulă.

O notă de domeniu: aceasta este o cale IPv4. Un client cu stivă dublă păstrează conectivitatea IPv6 pe care o are deja, deci o rută implicită IPv6 este o decizie separată cu propria autorizare, nu un efect secundar al acesteia.

Articole similare