AWS Client VPN povezan, a vendar brez interneta: preverjanje poti

AWS Client VPN povezan brez dostopa do interneta? Preverite poti odjemalca, avtorizacijo končne točke, izhod podomrežja in DNS v tem vrstnem redu.

Povezani ste s končno točko AWS Client VPN, zasebno podomrežje odgovarja, pa vendar se vsaka javna stran konča s potekom časa. Ta kombinacija zoži težavo na enega od treh objektov na upravljani strani: pot, ki jo odjemalec namesti, pot končne točke skupaj z njenim pravilom avtorizacije, ali naslednji skok povezanega podomrežja. Preverjam jih v tem vrstnem redu, ker je vsaka napaka z vidika odjemalca videti drugačna. Ta vodnik zajema upravljano končno točko, povezano z VPC, ne strežnika OpenVPN na instanci EC2 in ne povezave Cloud WAN ali Transit Gateway.

Začnite s tem, kar odjemalec dejansko usmerja

Povezano stanje dokazuje sejo TLS in dodelitev CIDR odjemalcu, nič več. Vprašajte operacijski sistem, kam bi šel javni naslov, medtem ko je tunel aktiven. V Linuxu naj ip route get 1.1.1.1 navede vmesnik tunela; v macOS netstat -rn -f inet | head -5 prikaže privzeti vnos; v Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 izpiše izbrani vmesnik in naslednji skok.

Potem preberite zastavico razdeljenega tunela, ker odloča, ali so objavljene poti končne točke edini cilji, ki jih odjemalec pošlje v tunel:

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

Ko je SplitTunnel true, javni cilj uporabi tunel le, kadar končna točka objavi pot, ki ga pokriva, zato manjkajoča 0.0.0.0/0 pusti ta promet na lokalnem vmesniku. Ko je false, odjemalec promet prestreže, a končna točka ga mora še vedno usmeriti in avtorizirati; sicer paketi vstopijo v tunel in se tam ustavijo. Po spremembi katere koli od obeh nastavitev odjemalca znova povežite, ker se poti in strežniki DNS dostavijo ob povezavi in lahko delujoč odjemalec obdrži staro množico.

Berite pot končne točke in pravilo avtorizacije ločeno

To sta dva objekta in ustvarjanje enega ne ustvari drugega. Naštejte poti končne točke in poiščite privzeto pot, katere cilj je povezano podomrežje:

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

Vsaka pot ima natanko eno ciljno podomrežje, zato tri povezave potrebujejo ustrezno privzeto pot za vsako. AWS dokumentira to zahtevo po pokritosti, praktični simptom vrzeli pa je uporabnik, ki dela iz enega podomrežja in se iz drugega zatakne, kar se bere kot občasna napaka namesto manjkajoče poti. Uradna dokumentacija scenarija Client VPN opisuje ureditev z javnim podomrežjem, ki ji te poti pripadajo.

Avtorizacija je drugi objekt. Ko nobeno pravilo ne pokriva javnega cilja, tunel paket prenese in storitev ga zavrže, zato zasebni viri delujejo naprej, internet pa ne:

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

Pravilo za CIDR VPC ne pove ničesar o 0.0.0.0/0. Dodajanje manjkajočih delov za polni tunel pomeni eno pot na povezano podomrežje plus pravilo avtorizacije, ki ga lahko pozneje pregledate:

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 dodeli cilj vsakemu odjemalcu končne točke, zato ga imejte le toliko časa, kolikor mora biti tunel poln; pravilo, vezano na skupino imenika, je boljše, ko imate skupine za vezavo.

Sledite paketu iz povezanega podomrežja

Pot končne točke odloči, da AWS paket izroči temu podomrežju. Ne odloči o naslednjem skoku za njim, ki živi v lastni tabeli poti VPC tega podomrežja:

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

Uporabna privzeta pot kaže na internetna vrata za javno podomrežje ali na NAT-vrata za zasebno, stanje blackhole pa pomeni, da je bil cilj izbrisan in da pot zdaj tiho umira. To so druge tabele kot seznam poti končne točke in popravilo ene ne popravi druge.

Na tem skoku sedita dva filtra. Varnostna skupina, uporabljena na povezavi ciljnega omrežja, mora dovoliti odhodni promet proti javnemu cilju, vsak veljaven omrežni ACL pa mora dovoliti zahtevo in povratni promet na efemernih vratih. Restriktivna varnostna skupina povezave je pogost vzrok, da zasebni dostop deluje, javni pa ne.

Izberite prvo plast glede na simptom, namesto da bi spremenili vse tri hkrati:

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

Ločite napako DNS od mrtve poti

Razreševanje imen odpove drugače kot posredovanje, polni tunel pa naredi to razliko pomembno, ker se do vsiljenega razreševalnika zdaj pride skozi tunel. Če končna točka navaja strežnike DNS v VPC, njihovi naslovi potrebujejo pokritost s potjo in avtorizacijo kot vsak drug cilj. Vprašajte razreševalnik neposredno, da vidite, katera napaka je: dig +short example.com @10.0.0.2, ali nslookup example.com 10.0.0.2 v Windows.

Ko številčni URL odgovori in imenski ne, prenehajte urejati privzeto pot in se lotite DNS. Zahteva na naslov IP ne dokaže ničesar o imenovanem virtualnem gostitelju in njegovem potrdilu, zato v končnem preverjanju obdržite en imenski test.

Čas pomaga. Povezava TCP, ki v nekaj sekundah ne dobi odgovora, kaže na usmerjanje ali filter, medtem ko zahteva, ki visi v iskanju imena, kaže na razreševalnik. Spreminjanje privzete poti, ko je razreševalnik nedosegljiv, običajno spremeni eno napako v dve.

Vrnite se čisto nazaj in nato preverite izhodno pot

Oba objekta sta bila dodajajoča, zato je vrnitev brisanje in ne popravilo:

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

Znova se povežite in potrdite, po kateri poti promet odhaja. Primerjajte opaženi javni naslov z elastičnim naslovom IP prehoda NAT ali z internetnimi vrati, ki ste jih nameravali uporabiti, in preverite, ali zasebni vir še vedno odgovarja v isti seji.

Končajte s kratkim seznamom in zadnjo postavko obravnavajte kot del spremembe in ne kot dokumentacijo:

  • Ena 0.0.0.0/0 pot končne točke za vsako povezano podomrežje.
  • Pravilo avtorizacije, ki pokriva 0.0.0.0/0 za odjemalce, ki jim želite služiti.
  • Privzeta pot VPC, ki ni v stanju blackhole, na vsakem povezanem podomrežju.
  • Izhod varnostne skupine povezave plus povratni promet ACL.
  • Naslovi razreševalnika usmerjeni in avtorizirani, preverjeni z imensko zahtevo.
  • Zabeležena vrnitev za pot in pravilo.

Ena opomba o obsegu: to je pot IPv4. Odjemalec z dvojnim skladom obdrži povezljivost IPv6, ki jo že ima, zato je privzeta pot IPv6 ločena odločitev z lastno avtorizacijo in ne stranski učinek te.

Sorodni članki