Naka-connect ang AWS Client VPN pero walang internet: pagsusuri ng ruta

Naka-connect ka sa endpoint ng AWS Client VPN, sumasagot ang pribadong subnet, at nag-time out pa rin ang bawat pampublikong pahina. Ang kombinasyong iyon ay nagpapaliit ng problema sa isa sa tatlong bagay sa pinamamahalaang panig: ang rutang inilalagay ng kliyente, ang ruta ng endpoint kasama ang tuntunin nito sa awtorisasyon, o ang susunod na pagtalon ng kaugnay na subnet. Sinusuri ko sila sa ganoong pagkakasunod-sunod dahil iba ang itsura ng bawat kabiguan mula sa kliyente. Saklaw ng gabay na ito ang pinamamahalaang endpoint na kaugnay ng VPC, hindi isang OpenVPN server sa EC2 instance at hindi koneksyon sa Cloud WAN o Transit Gateway.

Magsimula sa aktuwal na irinuruta ng kliyente

Ang naka-connect na estado ay nagpapatunay ng TLS session at paglalaan ng CIDR sa kliyente, wala nang iba. Tanungin ang operating system kung saan pupunta ang pampublikong address habang aktibo ang tunnel. Sa Linux, ip route get 1.1.1.1 dapat pangalanan ang interface ng tunnel; sa macOS, netstat -rn -f inet | head -5 ipinapakita ang default na entry; sa Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 ipinapasa ang napiling interface at susunod na pagtalon.

Pagkatapos basahin ang split-tunnel flag, dahil ito ang nagpapasya kung ang mga rutang inilathala ng endpoint ang tanging destinasyon na ipinapadala ng kliyente sa tunnel:

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

Kapag SplitTunnel ay true, gumagamit ng tunnel ang pampublikong destinasyon kapag naglathala ang endpoint ng rutang sumasakop dito, kaya ang kulang na 0.0.0.0/0 ay nag-iiwan ng trapikong iyon sa lokal na interface. Kapag false, hinuhuli ng kliyente ang trapiko, pero kailangan pa ring iruta at awtorisahin ito ng endpoint; kung hindi, pumapasok ang mga packet sa tunnel at humihinto doon. Ikonekta muli ang kliyente pagkatapos baguhin ang alinman sa dalawang setting, dahil ang ruta at DNS server ay inihahatid sa oras ng koneksyon at maaaring itago ng tumatakbong kliyente ang lumang set.

Basahin nang hiwalay ang ruta ng endpoint at ang tuntunin sa awtorisasyon

Dalawang bagay ito, at ang paggawa ng isa ay hindi gumagawa ng isa pa. Ilista ang mga ruta ng endpoint at hanapin ang default na ruta na ang target ay kaugnay na subnet:

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

Bawat ruta ay may eksaktong isang target na subnet, kaya tatlong kaugnayan ang nangangailangan ng tugmang default na ruta bawat isa. Dinodokumento ng AWS ang pangangailangang ito sa saklaw, at ang praktikal na sintomas ng puwang ay isang user na nagtatrabaho mula sa isang subnet at natigil mula sa iba, na binabasa bilang paminsan-minsang kabiguan sa halip na kulang na ruta. Ang opisyal na dokumentasyon ng senaryo ng Client VPN ay naglalarawan ng kaayusang pampublikong subnet kung saan nabibilang ang mga rutang ito.

Ang awtorisasyon ang ikalawang bagay. Kapag walang tuntuning sumasakop sa pampublikong destinasyon, dinadala ng tunnel ang packet at itinatapon ito ng serbisyo, kaya patuloy na gumagana ang pribadong resource habang hindi gumagana ang internet:

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

Ang tuntunin para sa CIDR ng VPC ay walang sinasabi tungkol sa 0.0.0.0/0. Ang pagdaragdag ng kulang na bahagi para sa buong tunnel ay nangangahulugan ng isang ruta sa bawat kaugnay na subnet at isang tuntunin sa awtorisasyon na maaari mong i-audit mamaya:

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 ay nagbibigay ng destinasyon sa bawat kliyente ng endpoint, kaya itago lamang ito habang dapat buo ang tunnel; mas mainam ang tuntuning nakatali sa isang pangkat ng direktoryo kapag may mga pangkat kang maikakabit.

Subaybayan ang packet palabas ng kaugnay na subnet

Ang ruta ng endpoint ang nagpapasya na ibinibigay ng AWS ang packet sa subnet na iyon. Hindi nito pinapasya ang susunod na pagtalon pagkatapos, na nasa sariling talahanayan ng ruta ng VPC ng subnet:

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

Ang magagamit na default na ruta ay tumuturo sa isang internet gateway para sa pampublikong subnet, o sa isang NAT gateway para sa pribado, at ang status na blackhole ay nangangahulugang tinanggal ang target at tahimik nang namamatay ang landas. Iba ito sa listahan ng ruta ng endpoint, at ang pag-aayos ng isa ay hindi nag-aayos ng isa pa.

Dalawang filter ang nakaupo sa pagtalon na ito. Ang security group na inilapat sa kaugnayan ng network ng target ay dapat pumayag sa palabas na trapiko patungo sa pampublikong destinasyon, at anumang naaangkop na network ACL ay dapat pumayag sa kahilingan at sa pabalik na trapiko sa mga ephemeral port. Ang mahigpit na security group ng kaugnayan ay karaniwang dahilan kung bakit gumagana ang pribadong access pero hindi ang pampubliko.

Piliin ang unang sapin mula sa sintomas sa halip na palitan ang tatlo nang sabay:

Ihiwalay ang kabiguan ng DNS mula sa patay na ruta

Ang paglutas ng pangalan ay nabigo nang iba kaysa sa pagpapasa, at ginagawang mahalaga ng buong tunnel ang pagkakaibang iyon dahil naaabot na ngayon ang itinulak na resolver sa pamamagitan ng tunnel. Kung tinukoy ng endpoint ang mga DNS server ng VPC, kailangan din ng kanilang address ang saklaw ng ruta at awtorisasyon tulad ng anumang destinasyon. Tanungin nang direkta ang resolver para makita kung aling kabiguan ang mayroon ka: dig +short example.com @10.0.0.2, o nslookup example.com 10.0.0.2 sa Windows.

Kapag sumagot ang numeric na URL at hindi ang may pangalan, itigil ang pag-edit sa default na ruta at magtrabaho sa DNS. Ang kahilingan sa isang IP address ay walang pinapatunay tungkol sa pinangalanang virtual host at sa sertipiko nito, kaya magtabi ng isang pinangalanang pagsubok sa huling pagsusuri.

Nakakatulong ang oras. Ang koneksyong TCP na walang sagot sa loob ng ilang segundo ay tumuturo sa routing o filter, habang ang kahilingang nakabitin sa paghahanap ng pangalan ay tumuturo sa resolver. Ang pagpapalit ng default na ruta habang hindi maabot ang resolver ay kadalasang gumagawa ng isang kabiguan na maging dalawa.

Mag-rollback nang malinis, pagkatapos i-verify ang landas ng labasan

Ang dalawang bagay ay additive, kaya ang rollback ay pagbura at hindi pag-aayos:

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

Ikonekta muli at kumpirmahin kung saang landas lumalabas ang trapiko. Ihambing ang naobserbahang pampublikong address sa elastic IP address ng NAT gateway, o sa internet gateway na balak mong gamitin, at tiyaking sumasagot pa rin ang pribadong resource sa parehong session.

Tapusin sa maikling listahan, at ituring ang huling item bilang bahagi ng pagbabago at hindi dokumentasyon:

• Isang 0.0.0.0/0 ruta ng endpoint para sa bawat kaugnay na subnet.
• Isang tuntunin sa awtorisasyon na sumasakop sa 0.0.0.0/0 para sa mga kliyenteng gusto mong pagsilbihan.
• Isang default na ruta ng VPC na wala sa status na blackhole sa bawat kaugnay na subnet.
• Labasan ng security group ng kaugnayan, kasama ang pabalik na trapiko ng ACL.
• Ang mga address ng resolver ay naruta at awtorisado, na-verify sa pinangalanang kahilingan.
• Isang naitalang rollback para sa ruta at tuntunin.

Isang tala sa saklaw: ito ay landas na IPv4. Pinapanatili ng dual-stack na kliyente ang IPv6 connectivity na mayroon na siya, kaya ang default na rutang IPv6 ay hiwalay na desisyon na may sariling awtorisasyon at hindi side effect nito.