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

AWS Client VPN tilkopla utan internettilgang? Kontroller klientrutene, autorisasjonen til endepunktet, utgangen frå subnettet og DNS i den rekkjefølgja.

Du er tilkopla AWS Client VPN-endepunktet, det private subnettet svarar, og likevel går kvar offentleg side ut på tid. Den kombinasjonen snevrar problemet inn til ein av tre objekt på den styrte sida: ruta klienten installerer, ruta til endepunktet saman med autorisasjonsregelen, eller neste hopp i det tilknytte subnettet. Eg kontrollerer dei i den rekkjefølgja fordi kvar feil ser annleis ut frå klienten. Denne rettleiaren dekkjer det VPC-tilknytte styrte endepunktet, ikkje ein OpenVPN-server på ein EC2-instans og ikkje ei Cloud WAN- eller Transit Gateway-tilkopling.

Start med det klienten faktisk rutar

Ein tilkopla tilstand beviser TLS-økta og CIDR-tildelinga til klienten, ikkje noko meir. Spør operativsystemet kvar ein offentleg adresse ville gå medan tunnelen er oppe. På Linux skal ip route get 1.1.1.1 namngje tunellgrensesnittet; på macOS viser netstat -rn -f inet | head -5 standardoppføringa; på Windows skriv Find-NetRoute -RemoteIPAddress 1.1.1.1 ut det valde grensesnittet og neste hopp.

Les deretter split-tunnel-flaggja, fordi ho avgjer om dei publiserte rutene til endepunktet er dei einaste måla 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, brukar eit offentleg mål tunnelen berre når endepunktet publiserer ei rute som dekkjer det, så ei manglande 0.0.0.0/0 lèt den trafikken bli på det lokale grensesnittet. Når ho er false, fangar klienten trafikken, men endepunktet må framleis rute og autorisere han; elles går pakkane inn i tunnelen og stoppar der. Kopla klienten til på nytt etter å ha endra kvar av dei to innstillingane, fordi ruter og DNS-tenarar blir leverte ved tilkopling, og ein køyrande klient kan halde på det gamle settet sitt.

Les ruta til endepunktet og autorisasjonsregelen kvar for seg

Det er to objekt, og opprettinga av det eine opprettar ikkje det andre. List rutene til endepunktet og sjå etter ei standardrute der målet er eit tilknytt subnett:

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

Kvar rute har nøyaktig eitt målsubnett, så tre tilknytingar treng kvar si tilsvarande standardrute. AWS dokumenterer dette dekkjanskravet, og det praktiske symptomet på eit hol er ein brukar som arbeider frå eitt subnett og stoppar frå eit anna, noko som blir lese som ein periodisk feil i staden for ei manglande rute. Den offisielle Client VPN-scenariedokumentasjonen skildrar det offentlege subnett-oppsettet som desse rutene høyrer til.

Autorisasjon er det andre objektet. Når ingen regel dekkjer det offentlege målet, ber tunnelen pakken og tenesta kastar han, så private ressursar held fram med å verke medan internett ikkje gjer det:

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

Ein regel for VPC-CIDR seier ingenting om 0.0.0.0/0. Å leggje til dei manglande delane for ein full tunnel tyder éi rute per tilknytt subnett pluss ein autorisasjonsregel du kan revidere seinare:

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 målet til kvar klient på endepunktet, så hald han berre medan tunnelen skal vere full; ein regel bunden til ein kataloggruppe er å føretrekkje når du har grupper å binde til.

Fylg pakken ut av det tilknytte subnettet

Ruta til endepunktet avgjer at AWS gir pakken til det subnettet. Ho avgjer ikkje neste hopp etter det, som bur i den eigne VPC-rutetabellen til subnettet:

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

Ei brukbar standardrute peikar på ein internettgateway for eit offentleg subnett, eller på ein NAT-gateway for eit privat, og ein tilstand av blackhole tyder at målet er sletta og stien døyr no stille. Dette er andre tabellar enn rutelista til endepunktet, og reparasjon av den eine reparerer ikkje den andre.

Det sit to filter på dette hoppet. Tryggingsgruppa som er brukt på mål-nettverkstilknytinga, må tillate utgåande trafikk mot det offentlege målet, og kvar aktuell nettverks-ACL må tillate førespurnaden og returtrafikken på efemære portar. Ei restriktiv tilknytingstryggingsgruppe er ein vanleg grunn til at privat tilgang verkar medan offentleg ikkje gjer det.

Vel det første laget ut frå symptomet i staden for å endre alle tre på ein gong:

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 frå ei død rute

Namneoppslag feilar annleis enn vidaresending, og full tunnel gjer skilnaden viktig fordi den påtvinga resolvaren no blir nådd gjennom tunnelen. Viss endepunktet oppgir VPC-DNS-tenarar, treng adressene deira rutetekking og autorisasjon som kvar annan destinasjon. Spør resolvaren direkte for å sjå kva feil du har: dig +short example.com @10.0.0.2, eller nslookup example.com 10.0.0.2 på Windows.

Når ein numerisk URL svarar og ein namngjeven ikkje gjer det, slutt å redigere standardruta og arbeid med DNS. Ein førespurnad til ei IP-adresse beviser ingenting om ein namngjeven virtuell vert og sertifikatet hans, så hald éin namngjeven test i den avsluttande kontrollen.

Timing hjelper. Ei TCP-tilkopling som ikkje får svar innan nokre sekund, peikar på ruting eller eit filter, medan ein førespurnad som heng i namneoppslaget, peikar på resolvaren. Å endre standardruta medan resolvaren er utilgjengeleg, gjer ofte éin feil til to.

Rull reint tilbake, og stadfest deretter utgangsstien

Begge objekta var additive, så tilbakerulling er sletting og ikkje 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

Kopla til på nytt, og stadfest deretter kva veg trafikken forlèt. Samanlikn den observerte offentlege adressa med den elastiske IP-adressa til NAT-gatewayen eller med internettgatewayen du hadde tenkt å bruke, og kontroller at ein privat ressurs framleis svarar i same økta.

Avslutt med ei kort liste, og handsam det siste punktet som ein del av endringa i staden for som dokumentasjon:

  • Éi 0.0.0.0/0 endepunktrute for kvart tilknytt subnett.
  • Ein autorisasjonsregel som dekkjer 0.0.0.0/0 for klientane du vil tene.
  • Ei VPC-standardrute som ikkje er blackhole, på kvart tilknytt subnett.
  • Utgåande trafikk frå tilknytingstryggingsgruppa pluss ACL-returtrafikk.
  • Resolveradresser ruta og autoriserte, stadfesta med ein namngjeven førespurnad.
  • Ei registrert tilbakerulling for ruta og regelen.

Ei merknad om omfang: dette er ein IPv4-sti. Ein dual-stack-klient held på IPv6-tilkoplinga han allereie har, så ei IPv6-standardrute er ei eiga avgjerd med sin eigen autorisasjon og ikkje ein biverknad av denne.

Relaterte artiklar