AWS Client VPN prisijungta, bet nėra interneto: maršrutų patikra

AWS Client VPN prisijungta, bet nėra interneto prieigos? Patikrinkite kliento maršrutus, endpoint autorizaciją, potinklio išėjimą ir DNS šia tvarka.

Esate prisijungę prie AWS Client VPN endpoint, privatus potinklis atsako, o vis dėlto kiekvienas viešas puslapis baigiasi skirtuoju laiku. Šis derinys susiaurina problemą iki vieno iš trijų objektų valdomoje pusėje: maršruto, kurį įdiegia klientas, endpoint maršruto kartu su jo autorizacijos taisykle, arba susieto potinklio kito šuolio. Tikrinu juos šia tvarka, nes kiekviena klaida iš kliento pusės atrodo kitaip. Šis vadovas apima su VPC susietą valdomą endpoint, o ne OpenVPN serverį EC2 instancijoje ir ne Cloud WAN ar Transit Gateway prisijungimą.

Pradėkite nuo to, ką klientas iš tikrųjų maršrutizuoja

Prisijungta būsena įrodo TLS sesiją ir klientui priskirtą CIDR, nieko daugiau. Paklauskite operacinės sistemos, kur eitų viešas adresas, kol tunelis pakeltas. Linux atveju ip route get 1.1.1.1 turėtų nurodyti tunelio sąsają; macOS atveju netstat -rn -f inet | head -5 rodo numatytąjį įrašą; Windows atveju Find-NetRoute -RemoteIPAddress 1.1.1.1 išveda pasirinktą sąsają ir kitą šuolį.

Tada perskaitykite split-tunnel vėliavėlę, nes ji nusprendžia, ar endpoint paskelbti maršrutai yra vienintelės paskirties vietos, kurias klientas siunčia į tunelį:

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

Kai SplitTunnel yra true, vieša paskirties vieta tunelį naudoja tik tada, kai endpoint paskelbia ją apimantį maršrutą, todėl trūkstamas 0.0.0.0/0 palieka tą srautą vietinėje sąsajoje. Kai jis false, klientas srautą pagauna, bet endpoint vis tiek turi jį maršrutizuoti ir autorizuoti; priešingu atveju paketai patenka į tunelį ir ten sustoja. Pakeitę bet kurį iš dviejų nustatymų, prijunkite klientą iš naujo, nes maršrutai ir DNS serveriai pateikiami prisijungimo metu, o veikiantis klientas gali išlaikyti seną rinkinį.

Skaitykite endpoint maršrutą ir autorizacijos taisyklę atskirai

Tai du objektai, ir vieno sukūrimas nesukuria kito. Išvardykite endpoint maršrutus ir ieškokite numatytojo maršruto, kurio tikslas yra susietas potinklis:

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

Kiekvienas maršrutas turi tiksliai vieną tikslinį potinklį, todėl trims susiejimams reikia atitinkamo numatytojo maršruto kiekvienam. AWS dokumentuoja šį aprėpties reikalavimą, o praktinis spragos simptomas yra naudotojas, kuris dirba iš vieno potinklio ir stringa iš kito, ir tai skaitoma kaip protarpinė klaida, o ne trūkstamas maršrutas. Oficiali Client VPN scenarijaus dokumentacija aprašo viešo potinklio išdėstymą, kuriam priklauso šie maršrutai.

Autorizacija yra antrasis objektas. Kai jokia taisyklė neapima viešos paskirties vietos, tunelis neša paketą, o paslauga jį atmeta, todėl privatūs ištekliai veikia toliau, o internetas ne:

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

VPC CIDR taisyklė nieko nesako apie 0.0.0.0/0. Viso tunelio trūkstamų dalių pridėjimas reiškia vieną maršrutą kiekvienam susietam potinkliui ir autorizacijos taisyklę, kurią vėliau galėsite audituoti:

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 suteikia paskirties vietą kiekvienam endpoint klientui, todėl laikykite ją tik tol, kol tunelis turi būti visas; prie katalogo grupės susieta taisyklė yra geresnė, kai turite grupių, prie kurių susieti.

Stebėkite paketą iš susieto potinklio

Endpoint maršrutas nusprendžia, kad AWS perduoda paketą tam potinkliui. Jis nenusprendžia kito šuolio už jo, kuris gyvena paties potinklio VPC maršrutų lentelėje:

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

Tinkamas numatytasis maršrutas rodo į interneto šliuzą viešam potinkliui arba į NAT šliuzą privačiam, o būsena blackhole reiškia, kad tikslas ištrintas ir kelias dabar tyliai miršta. Tai kitos lentelės nei endpoint maršrutų sąrašas, ir vienos taisymas netaiso kitos.

Šiame šuolyje yra du filtrai. Tiksliniam tinklo susiejimui pritaikyta saugos grupė turi leisti išeinantį srautą viešos paskirties vietos link, o bet kuri taikoma tinklo ACL turi leisti užklausą ir grįžtamąjį srautą efemeriškuose portuose. Ribojanti susiejimo saugos grupė yra dažna priežastis, kodėl privati prieiga veikia, o vieša ne.

Pasirinkite pirmąjį sluoksnį pagal simptomą, o ne keiskite visus tris iš karto:

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

Atskirkite DNS klaidą nuo negyvo maršruto

Vardų skyrimas nepavyksta kitaip nei persiuntimas, o visas tunelis šį skirtumą daro svarbų, nes stumiamas rezolveris dabar pasiekiamas per tunelį. Jei endpoint nurodo VPC DNS serverius, jų adresams reikia maršruto aprėpties ir autorizacijos kaip bet kuriai kitai paskirties vietai. Pasiteiraukite rezolverio tiesiogiai, kad pamatytumėte, kuri klaida yra: dig +short example.com @10.0.0.2, arba nslookup example.com 10.0.0.2 Windows atveju.

Kai skaitmeninis URL atsako, o vardinis ne, nustokite redaguoti numatytąjį maršrutą ir dirbkite su DNS. Užklausa IP adresui nieko neįrodo apie vardinį virtualų hostą ir jo sertifikatą, todėl paskutinėje patikroje palikite vieną vardinį testą.

Laikas padeda. TCP ryšys, kuris per kelias sekundes negauna atsakymo, rodo maršrutizavimą arba filtrą, o užklausa, kuri stringa vardų paieškoje, rodo rezolverį. Numatomojo maršruto keitimas, kol rezolveris nepasiekiamas, dažnai vieną klaidą paverčia dviem.

Grąžinkite tvarkingai, tada patikrinkite išėjimo kelią

Abu objektai buvo papildomi, todėl grąžinimas yra trynimas, o ne taisymas:

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

Prisijunkite iš naujo ir patvirtinkite, kokiu keliu srautas išeina. Palyginkite stebimą viešą adresą su NAT šliuzo elastiniu IP adresu arba su interneto šliuzu, kurį ketinote naudoti, ir patikrinkite, ar privatus išteklius vis dar atsako toje pačioje sesijoje.

Užbaikite trumpu sąrašu ir paskutinį punktą laikykite pakeitimo dalimi, o ne dokumentacija:

  • Vienas 0.0.0.0/0 endpoint maršrutas kiekvienam susietam potinkliui.
  • Autorizacijos taisyklė, apimanti 0.0.0.0/0 klientams, kuriems norite aptarnauti.
  • VPC numatytasis maršrutas, ne blackhole būsenos, kiekviename susietame potinklyje.
  • Susiejimo saugos grupės išėjimas ir ACL grįžtamasis srautas.
  • Rezolverio adresai maršrutizuoti ir autorizuoti, patikrinti vardine užklausa.
  • Užfiksuotas grąžinimas maršrutui ir taisyklei.

Viena apimties pastaba: tai IPv4 kelias. Dvigubo steko klientas išlaiko jau turimą IPv6 ryšį, todėl IPv6 numatytasis maršrutas yra atskiras sprendimas su savo autorizacija, o ne šio šalutinis poveikis.

Susiję straipsniai