AWS Client VPN on ühendatud, kuid internetiühendus puudub: marsruutide kontroll

AWS Client VPN on ühendatud, aga internetiühendust pole? Kontrollige kliendi marsruute, lõpp-punkti autoriseerimist, alamvõrgu väljundit ja DNS-i selles järjekorras.

Olete ühendatud AWS Client VPN-i lõpp-punktiga, privaatne alamvõrk vastab, ja ikkagi lõpeb iga avalik leht ajutõrkeajaga. See kombinatsioon kitsendab probleemi ühele kolmest haldatava poole objektil: marsruut, mille klient paigaldab, lõpp-punkti marsruut koos selle autoriseerimisreegliga, või seotud alamvõrgu järgmine hüpe. Kontrollin neid selles järjekorras, sest iga tõrge näeb kliendi poolelt erinev välja. See juhend hõlmab VPC-ga seotud hallatavat lõpp-punkti, mitte OpenVPN-i serverit EC2 eksemplaril ja mitte Cloud WAN ega Transit Gateway ühendust.

Alustage sellest, mida klient tegelikult marsruudib

Ühendatud olek tõestab TLS-seansi ja kliendile antud CIDR-i, mitte midagi enamat. Küsige operatsioonisüsteemilt, kuhu avalik aadress läheks, kui tunnel on üleval. Linuxis peaks ip route get 1.1.1.1 nimetama tunneli liidese; macOS-is näitab netstat -rn -f inet | head -5 vaikekirjet; Windowsis prindib Find-NetRoute -RemoteIPAddress 1.1.1.1 valitud liidese ja järgmise hüppe.

Seejärel lugege split-tunnel lippu, sest see otsustab, kas lõpp-punkti avaldatud marsruudid on ainsad sihtkohad, mille klient tunnelisse saadab:

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

Kui SplitTunnel on true, kasutab avalik sihtkoht tunnelit ainult siis, kui lõpp-punkt avaldab marsruudi, mis seda katab, nii et puuduv 0.0.0.0/0 jätab selle liikluse kohalikule liidesele. Kui see on false, püüab klient liikluse kinni, kuid lõpp-punkt peab selle ikkagi marsruutima ja autoriseerima; muidu sisenevad paketid tunnelisse ja peatuvad seal. Ühendage klient uuesti pärast kummagi seade muutmist, sest marsruudid ja DNS-serverid antakse ühendamise hetkel ning töötav klient võib vana komplekti alles hoida.

Lugege lõpp-punkti marsruuti ja autoriseerimisreeglit eraldi

Need on kaks objekti ja ühe loomine ei loo teist. Loetlege lõpp-punkti marsruudid ja otsige vaikemarsruuti, mille siht on seotud alamvõrk:

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

Igal marsruudil on täpselt üks sihtalamvõrk, seega kolm seost vajavad igaühe jaoks vastavat vaikemarsruuti. AWS dokumenteerib selle katvusnõude ja lünga praktiline sümptom on kasutaja, kes töötab ühest alamvõrgust ja takerdub teisest, mis loetakse katkendliku rikkena, mitte puuduva marsruudina. Ametlik Client VPN-i stsenaariumi dokumentatsioon kirjeldab avaliku alamvõrgu paigutust, kuhu need marsruudid kuuluvad.

Autoriseerimine on teine objekt. Kui ükski reegel avalikku sihtkohta ei kata, kannab tunnel paketi kohale ja teenus viskab selle ära, nii et privaatsed ressursid töötavad edasi, internet aga mitte:

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

VPC CIDR-i reegel ei ütle 0.0.0.0/0 kohta midagi. Täistunneli jaoks puuduvate osade lisamine tähendab ühte marsruuti iga seotud alamvõrgu kohta pluss autoriseerimisreegel, mida saate hiljem auditeerida:

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 annab sihtkoha igale lõpp-punkti kliendile, seega hoidke seda ainult seni, kuni tunnel peab olema täis; kataloogigrupiga seotud reegel on eelistatavam, kui teil on gruppe, millega siduda.

Jälgige paketti seotud alamvõrgust välja

Lõpp-punkti marsruut otsustab, et AWS annab paketi sellele alamvõrgule. See ei otsusta järgmist hüpet sellest edasi, mis elab alamvõrgu enda VPC marsruutitabelis:

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

Kasutatav vaikemarsruut osutab avaliku alamvõrgu jaoks internetilüüsile või privaatse jaoks NAT-lüüsile, ja olek blackhole tähendab, et sihtkoht kustutati ja tee sureb nüüd vaikselt. Need on erinevad tabelid lõpp-punkti marsruudiloendist ja ühe parandamine ei paranda teist.

Sellel hüppel istub kaks filtrit. Sihtvõrgu seosele rakendatud turbegrupp peab lubama väljuvat liiklust avaliku sihtkoha suunas ja mis tahes kohaldatav võrgu-ACL peab lubama päringu ja tagasiliikluse efemeersetel portidel. Piirav seose turbegrupp on tavaline põhjus, miks privaatne juurdepääs töötab, avalik aga mitte.

Valige esimene kiht sümptomi järgi, selle asemel et muuta kõiki kolme korraga:

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

Eraldage DNS-i tõrge surnud marsruudist

Nimelahendus nurjub teisiti kui edastamine ja täistunnel muudab selle vahe oluliseks, sest surutud resolverini jõutakse nüüd tunneli kaudu. Kui lõpp-punkt määrab VPC DNS-serverid, vajavad nende aadressid marsruudikatvust ja autoriseerimist nagu iga teine sihtkoht. Küsige resolverilt otse, milline tõrge teil on: dig +short example.com @10.0.0.2, või nslookup example.com 10.0.0.2 Windowsis.

Kui numbriline URL vastab ja nimega URL mitte, lõpetage vaikemarsruudi muutmine ja tegelege DNS-iga. Päring IP-aadressile ei tõesta nimega virtuaalse hosti ja selle sertifikaadi kohta midagi, seega jätke lõppkontrolli üks nimega test.

Ajastus aitab. TCP-ühendus, mis ei saa mõne sekundi jooksul vastust, osutab marsruutimisele või filtril, samal ajal kui nimeotsingus rippuma jääv päring osutab resolverile. Vaikemarsruudi muutmine, kui resolver on kättesaamatu, muudab tavaliselt ühe tõrke kaheks.

Võtke muudatused puhtalt tagasi ja seejärel kontrollige väljundteed

Mõlemad objektid olid lisavad, seega tagasivõtmine on kustutamine, mitte parandus:

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

Ühendage uuesti ja kinnitage, millist teed liiklus väljub. Võrrelge vaadeldud avalikku aadressi NAT-lüüsi elastse IP-aadressiga või internetilüüsiga, mida kavatsesite kasutada, ja kontrollige, kas privaatne ressurss vastab endiselt samas seansis.

Lõpetage lühikese loendiga ja käsitlege viimast punkti muudatuse osana, mitte dokumentatsioonina:

  • Üks 0.0.0.0/0 lõpp-punkti marsruut iga seotud alamvõrgu jaoks.
  • Autoriseerimisreegel, mis katab 0.0.0.0/0 nende klientide jaoks, keda soovite teenindada.
  • VPC vaikemarsruut, mis ei ole olekus blackhole, igas seotud alamvõrgus.
  • Seose turbegrupi väljund, pluss ACL-i tagasiliiklus.
  • Resolveri aadressid marsruuditud ja autoriseeritud, kontrollitud nimega päringuga.
  • Salvestatud tagasivõtmine marsruudi ja reegli jaoks.

Üks ulatuse märkus: see on IPv4 tee. Kahe virna klient hoiab alles IPv6-ühenduvuse, mis tal juba on, seega IPv6 vaikemarsruut on eraldi otsus oma autoriseerimisega, mitte selle kõrvalmõju.

Seotud artiklid