AWS Client VPN savienots, bet nav interneta: maršrutu pārbaude

AWS Client VPN savienots bez piekļuves internetam? Pārbaudiet klienta maršrutus, galapunkta autorizāciju, apakštīkla izeju un DNS šādā secībā.

Jūs esat savienots ar AWS Client VPN galapunktu, privātais apakštīkls atbild, un tomēr katra publiskā lapa beidzas ar taimautu. Šī kombinācija sašaurina problēmu līdz vienam no trim objektiem pārvaldītajā pusē: maršrutam, ko klients instalē, galapunkta maršrutam kopā ar tā autorizācijas noteikumu, vai saistītā apakštīkla nākamajam lēcienam. Es tos pārbaudu šādā secībā, jo katra kļūda no klienta puses izskatās citādi. Šī rokasgrāmata attiecas uz ar VPC saistīto pārvaldīto galapunktu, nevis uz OpenVPN serveri EC2 instancē un nevis uz Cloud WAN vai Transit Gateway savienojumu.

Sāciet ar to, ko klients faktiski maršrutē

Savienots statuss pierāda TLS sesiju un klientam piešķirto CIDR, neko vairāk. Pajautājiet operētājsistēmai, kur aizietu publiska adrese, kamēr tunelis ir uzcelts. Linux tas ip route get 1.1.1.1 būtu jānosauc tuneļa saskarne; macOS netstat -rn -f inet | head -5 parāda noklusējuma ierakstu; Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 izdrukā izvēlēto saskarni un nākamo lēcienu.

Pēc tam izlasiet split-tunnel karodziņu, jo tas nosaka, vai galapunkta publicētie maršruti ir vienīgie galamērķi, ko klients sūta tunelī:

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

Kad SplitTunnel ir true, publisks galamērķis tuneli izmanto tikai tad, ja galapunkts publicē to aptverošu maršrutu, tāpēc trūkstošs 0.0.0.0/0 atstāj šo datplūsmu vietējā saskarnē. Kad tas ir false, klients datplūsmu pārtver, bet galapunktam tā vēl jāmaršrutē un jāautorizē; pretējā gadījumā paketes nonāk tunelī un tur apstājas. Pēc jebkura no diviem iestatījumiem maiņas pievienojiet klientu no jauna, jo maršruti un DNS serveri tiek piegādāti savienošanās brīdī, un darbojošs klients var saglabāt veco kopu.

Lasiet galapunkta maršrutu un autorizācijas noteikumu atsevišķi

Tie ir divi objekti, un viena izveide neizveido otru. Uzskaitiet galapunkta maršrutus un meklējiet noklusējuma maršrutu, kura mērķis ir saistīts apakštīkls:

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

Katram maršrutam ir tieši viens mērķa apakštīkls, tāpēc trim saistījumiem vajadzīgs atbilstošs noklusējuma maršruts katram. AWS dokumentē šo pārklājuma prasību, un trūkuma praktiskais simptoms ir lietotājs, kurš strādā no viena apakštīkla un iestrēgst no cita, kas tiek lasīts kā periodiska kļūme, nevis trūkstošs maršruts. Oficiālā Client VPN scenārija dokumentācija apraksta publiskā apakštīkla izkārtojumu, kuram pieder šie maršruti.

Autorizācija ir otrais objekts. Kad neviens noteikums neaptver publisko galamērķi, tunelis pārvadā paketi un pakalpojums to izmet, tāpēc privātie resursi turpina darboties, bet internets ne:

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

Noteikums VPC CIDR neko nepasaka par 0.0.0.0/0. Trūkstošo daļu pievienošana pilnam tunelim nozīmē vienu maršrutu katram saistītajam apakštīklam un autorizācijas noteikumu, ko vēlāk varat revidēt:

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 piešķir galamērķi katram galapunkta klientam, tāpēc turiet to tikai tik ilgi, kamēr tunelim jābūt pilnam; noteikums, kas piesaistīts direktorija grupai, ir labāks, ja jums ir grupas, kam piesaistīt.

Sekojiet paketei ārpus saistītā apakštīkla

Galapunkta maršruts nosaka, ka AWS nodod paketi šim apakštīklam. Tas nenosaka nākamo lēcienu aiz tā, kas atrodas paša apakštīkla VPC maršrutu tabulā:

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

Izmantojams noklusējuma maršruts norāda uz interneta vārteju publiskam apakštīklam vai uz NAT vārteju privātam, un statuss blackhole nozīmē, ka mērķis ir izdzēsts un ceļš tagad klusi mirst. Šīs ir citas tabulas nekā galapunkta maršrutu saraksts, un vienas labošana nelabo otru.

Šajā lēcienā sēž divi filtri. Mērķa tīkla saistījumam piemērotai drošības grupai jāatļauj izejošā datplūsma uz publisko galamērķi, un jebkuram piemērojamam tīkla ACL jāatļauj pieprasījums un atgriezeniskā datplūsma efemērajos portos. Ierobežojoša saistījuma drošības grupa ir biežs iemesls, kāpēc privātā piekļuve darbojas, bet publiskā ne.

Izvēlieties pirmo slāni pēc simptoma, nevis mainiet visus trīs uzreiz:

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

Atdaliet DNS kļūmi no miruša maršruta

Vārdu izšķiršana neizdodas citādi nekā pārsūtīšana, un pilns tunelis šo atšķirību padara svarīgu, jo uzspiestais risinātājs tagad tiek sasniegts caur tuneli. Ja galapunkts norāda VPC DNS serverus, to adresēm vajadzīgs maršruta pārklājums un autorizācija kā jebkuram citam galamērķim. Pajautājiet risinātājam tieši, lai redzētu, kura kļūme ir: dig +short example.com @10.0.0.2, vai nslookup example.com 10.0.0.2 Windows.

Kad skaitlisks URL atbild, bet nosaukts ne, pārtrauciet noklusējuma maršruta rediģēšanu un strādājiet ar DNS. Pieprasījums uz IP adresi neko nepierāda par nosauktu virtuālo hostu un tā sertifikātu, tāpēc pēdējā pārbaudē paturiet vienu nosauktu testu.

Laiks palīdz. TCP savienojums, kas dažu sekunžu laikā nesaņem atbildi, norāda uz maršrutēšanu vai filtru, bet pieprasījums, kas karājas vārdu meklēšanā, norāda uz risinātāju. Noklusējuma maršruta maiņa, kamēr risinātājs nav sasniedzams, bieži vienu kļūmi pārvērš divās.

Atritiniet tīri un pēc tam pārbaudiet izejas ceļu

Abi objekti bija papildinoši, tāpēc atritināšana ir dzēšana, nevis labošana:

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

Pievienojieties no jauna un apstipriniet, pa kuru ceļu datplūsma iziet. Salīdziniet novēroto publisko adresi ar NAT vārtejas elastīgo IP adresi vai ar interneta vārteju, ko bijāt iecerējis izmantot, un pārbaudiet, vai privātais resurs joprojām atbild tajā pašā sesijā.

Pabeidziet ar īsu sarakstu un pēdējo punktu uzskatiet par izmaiņu daļu, nevis dokumentāciju:

  • Viens 0.0.0.0/0 galapunkta maršruts katram saistītajam apakštīklam.
  • Autorizācijas noteikums, kas aptver 0.0.0.0/0 klientiem, kurus vēlaties apkalpot.
  • VPC noklusējuma maršruts, kas nav blackhole statusā, katrā saistītajā apakštīklā.
  • Saistījuma drošības grupas izeja un ACL atgriezeniskā datplūsma.
  • Risinātāja adreses maršrutētas un autorizētas, pārbaudītas ar nosauktu pieprasījumu.
  • Fiksēta atritināšana maršrutam un noteikumam.

Viena apjoma piezīme: tas ir IPv4 ceļš. Divkāršā steka klients saglabā jau esošo IPv6 savienojumu, tāpēc IPv6 noklusējuma maršruts ir atsevišķs lēmums ar savu autorizāciju, nevis šī blakusefekts.

Saistītie raksti