AWS Client VPN tilkoblet, men ingen internettilgang: kontroll av ruter

AWS Client VPN tilkoblet uten internettilgang? Kontroller klientrutene, endepunktets autorisasjon, subnettets utgang og DNS i den rekkefølgen.

Du er koblet til AWS Client VPN-endepunktet, det private subnettet svarer, og likevel går hver offentlig side ut på tid. Den kombinasjonen snevrer problemet inn til en av tre objekter på den administrerte siden: ruten klienten installerer, endepunktets rute sammen med autorisasjonsregelen, eller det tilknyttede subnettets neste hopp. Jeg kontrollerer dem i den rekkefølgen fordi hver feil ser annerledes ut fra klienten. Denne veiledningen dekker det VPC-tilknyttede administrerte endepunktet, ikke en OpenVPN-server på en EC2-instans og ikke en Cloud WAN- eller Transit Gateway-tilkobling.

Start med det klienten faktisk ruter

En tilkoblet tilstand beviser TLS-økten og klientens CIDR-tildeling, ikke noe mer. Spør operativsystemet hvor en offentlig adresse ville gå mens tunnelen er oppe. På Linux skal ip route get 1.1.1.1 navngi tunellgrensesnittet; på macOS viser netstat -rn -f inet | head -5 standardoppføringen; på Windows skriver Find-NetRoute -RemoteIPAddress 1.1.1.1 ut det valgte grensesnittet og neste hopp.

Les deretter split-tunnel-flagget, fordi det avgjør om endepunktets publiserte ruter er de eneste destinasjonene klienten sender inn i tunnelen:

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

Når SplitTunnel er true, bruker en offentlig destinasjon tunnelen bare når endepunktet publiserer en rute som dekker den, så en manglende 0.0.0.0/0 lar den trafikken bli på det lokale grensesnittet. Når den er false, fanger klienten trafikken, men endepunktet må fortsatt rute og autorisere den; ellers går pakkene inn i tunnelen og stopper der. Koble klienten til på nytt etter å ha endret hver av de to innstillingene, fordi ruter og DNS-servere leveres ved tilkobling, og en kjørende klient kan beholde sitt gamle sett.

Les endepunktets rute og autorisasjonsregelen hver for seg

Det er to objekter, og opprettelsen av det ene oppretter ikke det andre. List endepunktets ruter og se etter en standardrute der målet er et tilknyttet subnett:

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

Hver rute har nøyaktig ett målsubnett, så tre tilknytninger trenger hver sin tilsvarende standardrute. AWS dokumenterer dette dekningskravet, og det praktiske symptomet på et hull er en bruker som arbeider fra ett subnett og stopper fra et annet, noe som leses som en periodisk feil i stedet for en manglende rute. Den offisielle Client VPN-scenariedokumentasjonen beskriver det offentlige subnett-oppsettet som disse rutene hører til.

Autorisasjon er det andre objektet. Når ingen regel dekker den offentlige destinasjonen, bærer tunnelen pakken og tjenesten forkaster den, så private ressurser fortsetter å virke mens internett ikke gjør det:

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

En regel for VPC-CIDR sier ingenting om 0.0.0.0/0. Å legge til de manglende delene for en full tunnel betyr én rute per tilknyttet subnett pluss en autorisasjonsregel 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 gir destinasjonen til hver klient på endepunktet, så behold den bare mens tunnelen skal være full; en regel bundet til en kataloggruppe er å foretrekke når du har grupper å binde til.

Følg pakken ut av det tilknyttede subnettet

Endepunktets rute avgjør at AWS gir pakken til det subnettet. Den avgjør ikke neste hopp etter det, som bor i subnettets egen VPC-rutetabell:

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

En brukbar standardrute peker på en internettgateway for et offentlig subnett, eller på en NAT-gateway for et privat, og en tilstand av blackhole betyr at målet er slettet og stien dør nå stille. Dette er andre tabeller enn endepunktets ruteliste, og reparasjon av den ene reparerer ikke den andre.

Det sitter to filtre på dette hoppet. Sikkerhetsgruppen som er brukt på mål-nettverkstilknytningen, må tillate utgående trafikk mot den offentlige destinasjonen, og enhver aktuell nettverks-ACL må tillate forespørselen og returtrafikken på efemære porter. En restriktiv tilknytningssikkerhetsgruppe er en vanlig grunn til at privat tilgang virker mens offentlig ikke gjør det.

Velg det første laget ut fra symptomet i stedet for å endre 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

Skil DNS-feil fra en død rute

Navneoppslag feiler annerledes enn videresending, og full tunnel gjør forskjellen viktig fordi den påtvungne resolveren nås gjennom tunnelen. Hvis endepunktet angir VPC-DNS-servere, trenger adressene deres rutetekning og autorisasjon som enhver annen destinasjon. Spør resolveren direkte for å se hvilken feil 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 navngitt ikke gjør det, slutt å redigere standardruten og arbeid med DNS. En forespørsel til en IP-adresse beviser ingenting om en navngitt virtuell vert og sertifikatet dens, så behold én navngitt test i den avsluttende kontrollen.

Timing hjelper. En TCP-forbindelse som ikke får svar innen noen sekunder, peker på ruting eller et filter, mens en forespørsel som henger i navneoppslaget, peker på resolveren. Å endre standardruten mens resolveren er utilgjengelig, gjør ofte én feil til to.

Rull rent tilbake, og bekreft deretter utgangsstien

Begge objektene var additive, så tilbakerulling er sletting og ikke reparasjon:

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

Koble til på nytt, og bekreft deretter hvilken vei trafikken forlater. Sammenlign den observerte offentlige adressen med NAT-gatewayens elastiske IP-adresse eller med internettgatewayen du hadde tenkt å bruke, og kontroller at en privat ressurs fortsatt svarer i samme økt.

Avslutt med en kort liste, og behandle det siste punktet som en del av endringen i stedet for som dokumentasjon:

  • Én 0.0.0.0/0 endepunktrute for hvert tilknyttet subnett.
  • En autorisasjonsregel som dekker 0.0.0.0/0 for klientene du vil betjene.
  • En VPC-standardrute som ikke er blackhole, på hvert tilknyttet subnett.
  • Utgående trafikk fra tilknytningssikkerhetsgruppen pluss ACL-returtrafikk.
  • Resolveradresser rutet og autorisert, bekreftet med en navngitt forespørsel.
  • En registrert tilbakerulling for ruten og regelen.

En merknad om omfang: dette er en IPv4-sti. En dual-stack-klient beholder IPv6-tilkoblingen den allerede har, så en IPv6-standardrute er en egen beslutning med sin egen autorisasjon og ikke en bivirkning av denne.

Relaterte artikler