AWS Client VPN ferbûn mar gjin ynternet: kontrôle fan rûtes

AWS Client VPN ferbûn sûnder ynternet? Kontrolearje de rûtes fan de klant, de autorisaasje fan it einpunt, de útgong fan it subnet en DNS yn dy folchoarder.

Do bist ferbûn mei it einpunt fan AWS Client VPN, it privee subnet antwurdet, en dochs rinne alle iepenbiere siden op tiid út. Dy kombinaasje beheint it probleem ta ien fan trije objekten oan de behearde kant: de rûte dy’t de klant ynstallearret, de rûte fan it einpunt tegearre mei syn autorisaasjeregel, of de folgjende hop fan it keppele subnet. Ik kontrolearje se yn dy folchoarder, om’t elke fout fan de klant ôf oars liket. Dizze hantlieding giet oer it behearde einpunt dat oan in VPC keppele is, net oer in OpenVPN-tsjinner op in EC2-ynstânsje en net oer in Cloud WAN- of Transit Gateway-oansluting.

Begjin mei wat de klant feitlik rûtet

In ferbûne steat bewiist de TLS-sesje en de CIDR-tawizing oan de klant, mear net. Freegje it bestjoeringssysteem wêr’t in iepenbier adres hinne soe wylst de tunnel oan stiet. Op Linux soe ip route get 1.1.1.1 de tunnelinterface neame moatte; op macOS lit netstat -rn -f inet | head -5 de standertynfier sjen; op Windows prints Find-NetRoute -RemoteIPAddress 1.1.1.1 de keazen interface en de folgjende hop.

Lês dan de split-tunnel-flagge, want dy beslút oft de publisearre rûtes fan it einpunt de iennige bestimmings binne dy’t de klant de tunnel yn stjoert:

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

As SplitTunnel wier is, brûkt in iepenbiere bestimming de tunnel allinne as it einpunt in rûte publisearret dy’t dy bestimt, dus in ûntbrekkende 0.0.0.0/0 lit dat ferkear op de lokale interface. As it falsk is, fangt de klant it ferkear, mar it einpunt moat it noch altyd rûte en autorisearje; oars komme pakketten de tunnel yn en stopje dêr. Ferbynje de klant op ‘e nij nei’t do ien fan beide ynstellingen feroare hast, want rûtes en DNS-tsjinners wurde by ferbining levere en in rinnende klant kin syn âlde set hâlde.

Lês de rûte fan it einpunt en de autorisaasjeregel apart

Dat binne twa objekten, en it meitsjen fan ien makket de oare net. List de rûtes fan it einpunt op en sykje in standertrûte wêrfan’t it doel in keppele subnet is:

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

Elke rûte hat krekt ien doelsubnet, dus trije keppelings hawwe elk in byhearrende standertrûte nedich. AWS dokumintearret dizze dekkingsfoardering, en it praktyksymptoom fan in gat is in brûker dy’t fan it iene subnet wurket en by it oare fêstrint, wat lêzen wurdt as in tuskenskoftsflater yn stee fan in ûntbrekkende rûte. De offisjele dokumintaasje fan it Client VPN-senario beskriuwt de opstelling mei in iepenbier subnet dêr’t dizze rûtes by hearre.

Autorisaasje is it twadde objekt. As gjin regel de iepenbiere bestimmings dekt, draacht de tunnel it pakket en smyt de tsjinst it fuort, dus privee boarnen bliuwe wurkje wylst it ynternet dat net docht:

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

In regel foar it CIDR fan de VPC seit neat oer 0.0.0.0/0. De ûntbrekkende stikken foar in folsleine tunnel tafoegje betsjut ien rûte per keppele subnet plus in autorisaasjeregel dy’t do letter kontrolearje kinst:

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 jout de bestimmings oan elke klant fan it einpunt, dus hâld it allinne salang’t de tunnel folslein wêze moat; in regel dy’t oan in mapgroep bûn is, hat de foarkar as do groepen hast om oan te binen.

Folgje it pakket it keppele subnet út

De rûte fan it einpunt beslút dat AWS it pakket oan dat subnet jout. It beslút net de folgjende hop dêrnei, dy’t yn ‘e eigen VPC-rûtetabel fan it subnet sit:

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

In brûkbere standertrûte wiist nei in ynternetgateway foar in iepenbier subnet, of nei in NAT-gateway foar in privee ien, en in steat blackhole betsjut dat it doel fuortsmiten is en it paad no stil stjert. Dat binne oare tabellen as de rûtelist fan it einpunt, en ien reparearje reparearret de oare net.

Op dizze hop sitte twa filters. De befeiligingsgroep dy’t op ‘e netwurkkeppeling fan it doel tapast is, moat útgeand ferkear nei de iepenbiere bestimmings tastean, en elk tapasslik netwurk-ACL moat it fersyk en it weromferkear op efemere poarten tastean. In beheinende befeiligingsgroep fan ‘e keppeling is in faak foarkommende reden dat privee tagong wurket en iepenbiere net.

Kies de earste laach op grûn fan it symptoom yn stee fan alle trije tagelyk te feroarjen:

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

Skied DNS-flaters fan in deade rûte

Namme-oplossing falt oars as trochstjoering, en in folsleine tunnel makket it ferskil wichtich om’t de trochdrukte resolver no troch de tunnel berikt wurdt. As it einpunt VPC-DNS-tsjinners oanjout, hawwe har adressen rûtedekking en autorisaasje nedich lykas elke oare bestimmings. Freegje de resolver direkt om te sjen hokker flater do hast: dig +short example.com @10.0.0.2, of nslookup example.com 10.0.0.2 op Windows.

As in nûmerike URL antwurdet en in neamde net, stopje dan mei it bewurkjen fan ‘e standertrûte en wurkje oan DNS. In fersyk nei in IP-adres bewiist neat oer in neamd firtueel host en syn sertifikaat, dus hâld ien neamd test yn ‘e ein kontrôle.

Timing helpt. In TCP-ferbining dy’t yn in pear sekonden gjin antwurd krijt, wiist op rûtering of in filter, wylst in fersyk dat yn ‘e nammesyktocht hinget op ‘e resolver wiist. De standertrûte feroarje wylst de resolver net berikber is, makket meastentiids ien flater twa.

Draai skjin werom en kontrolearje dan it útgongspaad

Beide objekten wiene tafoegjend, dus weromdraaie is fuortsmite en net reparearje:

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

Ferbynje op ‘e nij en befêstigje hokker paad it ferkear ferlit. Ferlykje it waarnommen iepenbiere adres mei it elastyske IP-adres fan ‘e NAT-gateway, of mei de ynternetgateway dy’t do brûke woe, en kontrolearje dat in privee boarne noch yn deselde sesje antwurdet.

Einigje mei in koarte list en behannelje it lêste item as diel fan ‘e feroaring en net as dokumintaasje:

  • Ien 0.0.0.0/0 einpuntrûte foar elk keppele subnet.
  • In autorisaasjeregel dy’t 0.0.0.0/0 dekt foar de klanten dy’t do betsjinje wolst.
  • In VPC-standertrûte dy’t net yn ‘e steat blackhole is, op elk keppele subnet.
  • Útgong fan ‘e befeiligingsgroep fan ‘e keppeling, plus ACL-weromferkear.
  • Resolveradressen rûte en autorisearre, ferifiearre mei in neamd fersyk.
  • In fêstleine weromdraai foar de rûte en de regel.

Ien nota oer it berik: dit is in IPv4-paad. In dual-stack-klant hâldt de IPv6-ferbining dy’t hy al hat, dus in IPv6-standertrûte is in aparte beslissing mei eigen autorisaasje en net in by-effekt fan dizze.

Relatearre artikelen