AWS Client VPN forbundet, men ingen internetadgang: kontrol af ruter

AWS Client VPN forbundet uden internetadgang? Kontroller klientruter, endpoint-autorisation, subnet-udgang og DNS i den rækkefølge.

Du er forbundet til AWS Client VPN-endpointet, det private subnet svarer, og alligevel timer hver offentlig side ud. Den kombination indsnævrer problemet til en af tre objekter på den administrerede side: ruten klienten installerer, endpointets rute sammen med dens autorisationsregel, eller det tilknyttede subnets næste hop. Jeg kontrollerer dem i den rækkefølge, fordi hver fejl ser forskellig ud fra klienten. Denne vejledning dækker det VPC-tilknyttede administrerede endpoint, ikke en OpenVPN-server på en EC2-instans og ikke en Cloud WAN- eller Transit Gateway-tilslutning.

Start med hvad klienten faktisk router

En forbundet tilstand beviser TLS-sessionen og klientens CIDR-tildeling, intet mere. Spørg operativsystemet, hvor en offentlig adresse ville gå hen, mens tunnelen er oppe. På Linux skal ip route get 1.1.1.1 navngive tunnelinterfacet; på macOS viser netstat -rn -f inet | head -5 standardposten; på Windows udskriver Find-NetRoute -RemoteIPAddress 1.1.1.1 det valgte interface og næste hop.

Læs derefter split-tunnel-flaget, fordi det afgør, om endpointets publicerede ruter er de eneste destinationer, klienten sender ind i tunnelen:

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

Når SplitTunnel er true, bruger en offentlig destination kun tunnelen, når endpointet publicerer en rute, der dækker den, så en manglende 0.0.0.0/0 lader den trafik blive på det lokale interface. Når den er false, fanger klienten trafikken, men endpointet skal stadig route og autorisere den; ellers går pakkerne ind i tunnelen og stopper der. Genopret klienten efter ændring af hver af de to indstillinger, fordi ruter og DNS-servere leveres ved forbindelsestidspunktet, og en kørende klient kan beholde sit gamle sæt.

Læs endpointets rute og autorisationsreglen hver for sig

Det er to objekter, og oprettelsen af det ene opretter ikke det andet. List endpointets ruter, og se efter en standardrute, hvis mål er et tilknyttet subnet:

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

Hver rute har præcis ét målsubnet, så tre tilknytninger har hver brug for en tilsvarende standardrute. AWS dokumenterer dette dækningskrav, og det praktiske symptom på et hul er en bruger, der arbejder fra ét subnet og går i stå fra et andet, hvilket læses som en periodisk fejl i stedet for en manglende rute. Den officielle Client VPN-scenariedokumentation beskriver det offentlige subnet-arrangement, som disse ruter hører til.

Autorisation er det andet objekt. Når ingen regel dækker den offentlige destination, bærer tunnelen pakken, og tjenesten kasserer den, så private ressourcer bliver ved med at virke, mens internettet ikke gør:

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

En regel for VPC-CIDR siger intet om 0.0.0.0/0. At tilføje de manglende dele for en fuld tunnel betyder én rute pr. tilknyttet subnet plus en autorisationsregel, du kan revidere senere:

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 giver destinationen til hver klient på endpointet, så behold den kun, mens tunnelen skal være fuld; en regel bundet til en kataloggruppe er at foretrække, når du har grupper at binde til.

Følg pakken ud af det tilknyttede subnet

Endpointets rute afgør, at AWS giver pakken til det subnet. Den afgør ikke det næste hop derefter, som bor i subnets egen VPC-rutetabel:

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

En brugbar standardrute peger på en internetgateway for et offentligt subnet eller på en NAT-gateway for et privat, og en tilstand af blackhole betyder, at målet er slettet, og stien dør nu stille. Det er andre tabeller end endpointets ruteliste, og reparation af den ene reparerer ikke den anden.

Der sidder to filtre på dette hop. Den sikkerhedsgruppe, der er anvendt på målnetværkstilknytningen, skal tillade udgående trafik mod den offentlige destination, og enhver relevant netværks-ACL skal tillade anmodningen og returtrafikken på efemære porte. En restriktiv tilknytningssikkerhedsgruppe er en hyppig grund til, at privat adgang virker, mens offentlig ikke gør.

Vælg det første lag ud fra symptomet i stedet for at ændre alle tre på én gang:

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

Adskil DNS-fejl fra en død rute

Navneopløsning fejler anderledes end videresendelse, og fuld tunnel gør forskellen vigtig, fordi den skubbede resolver nu nås gennem tunnelen. Hvis endpointet angiver VPC-DNS-servere, har deres adresser brug for rutedækning og autorisation som enhver anden destination. Spørg resolveren direkte for at se, hvilken fejl du har: dig +short example.com @10.0.0.2, eller nslookup example.com 10.0.0.2 på Windows.

Når en numerisk URL svarer, og en navngivet ikke gør, skal du stoppe med at redigere standardruten og arbejde på DNS. En anmodning til en IP-adresse beviser intet om en navngivet virtuel vært og dens certifikat, så behold én navngivet test i den afsluttende kontrol.

Timing hjælper. En TCP-forbindelse, der ikke får svar inden for få sekunder, peger på routing eller et filter, mens en anmodning, der hænger i navneopslaget, peger på resolveren. At ændre standardruten, mens resolveren er utilgængelig, plejer at gøre én fejl til to.

Rul rent tilbage, og bekræft derefter udgangsstien

Begge objekter var additive, så tilbagerulning er sletning og ikke reparation:

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

Genopret forbindelsen, og bekræft derefter, hvilken vej trafikken forlader. Sammenlign den observerede offentlige adresse med NAT-gatewayens elastiske IP-adresse eller med den internetgateway, du havde tænkt dig at bruge, og kontroller, at en privat ressource stadig svarer i samme session.

Afslut med en kort liste, og behandl det sidste punkt som en del af ændringen i stedet for som dokumentation:

  • Én 0.0.0.0/0 endpointrute for hvert tilknyttet subnet.
  • En autorisationsregel, der dækker 0.0.0.0/0 for de klienter, du vil betjene.
  • En VPC-standardrute, der ikke er blackhole, på hvert tilknyttet subnet.
  • Udgående trafik fra tilknytningssikkerhedsgruppen plus ACL-returtrafik.
  • Resolveradresser routet og autoriseret, bekræftet med en navngivet anmodning.
  • En registreret tilbagerulning for ruten og reglen.

En bemærkning om omfang: dette er en IPv4-sti. En dual-stack-klient beholder den IPv6-forbindelse, den allerede har, så en IPv6-standardrute er en separat beslutning med sin egen autorisation og ikke en bivirkning af denne.

Relaterede artikler