AWS Client VPN konektita sed sen interreta aliro: kontrolo de vojoj

Ĉu AWS Client VPN konektita sen interreta aliro? Kontrolu klientajn vojojn, rajtigon de la finpunkto, eliron de la subreto kaj DNS en tiu ordo.

Vi estas konektita al la finpunkto de AWS Client VPN, la privata subreto respondas, kaj tamen ĉiu publika paĝo finiĝas per tempolimo. Tiu kombino mallarĝigas la problemon al unu el tri objektoj ĉe la administrata flanko: la vojo, kiun la kliento instalas, la vojo de la finpunkto kune kun ĝia rajtiga regulo, aŭ la sekva salto de la asociita subreto. Mi kontrolas ilin en tiu ordo, ĉar ĉiu fiasko aspektas malsame de la klienta flanko. Ĉi tiu gvidilo kovras la administratan finpunkton asociitan kun VPC, ne OpenVPN-servilon sur EC2-instalaĵo kaj ne Cloud WAN aŭ Transit Gateway aliĝon.

Komencu per tio, kion la kliento efektive enkursigas

Konektita stato pruvas la TLS-sesion kaj la CIDR-donitan al la kliento, nenion pli. Demandu la operaciumon, kien publika adreso irus dum la tunelo estas aktiva. En Linux, ip route get 1.1.1.1 devus nomi la tunelan interfacon; en macOS, netstat -rn -f inet | head -5 montras la defaŭltan rikordon; en Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 presas la elektitan interfacon kaj la sekvan salton.

Poste legu la split-tunnel flagon, ĉar ĝi decidas, ĉu la publikigitaj vojoj de la finpunkto estas la solaj celoj, kiujn la kliento sendas en la tunelon:

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

Kiam SplitTunnel estas true, publika celo uzas la tunelon nur kiam la finpunkto publikigas vojon, kiu kovras ĝin, do mankanta 0.0.0.0/0 lasas tiun trafikon sur la loka interfaco. Kiam ĝi estas false, la kliento kaptas la trafikon, sed la finpunkto ankoraŭ devas enkursigi kaj rajtigi ĝin; alie pakaĵoj eniras la tunelon kaj haltas tie. Rekonektu la klienton post ŝanĝo de iu ajn el la du agordoj, ĉar vojoj kaj DNS-serviloj liveriĝas ĉe konekta tempo kaj funkcianta kliento povas konservi sian malnovan aron.

Legu la vojon de la finpunkto kaj la rajtigan regulon aparte

Ĝi estas du objektoj, kaj kreado de unu ne kreas la alian. Listigu la vojojn de la finpunkto kaj serĉu defaŭltan vojon, kies celo estas asociita subreto:

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

Ĉiu vojo havas ekzakte unu celan subreton, do tri asocioj bezonas kongruan defaŭltan vojon por ĉiu. AWS dokumentas ĉi tiun postulon pri kovrado, kaj la praktika simptomo de breĉo estas uzanto, kiu laboras el unu subreto kaj blokiĝas el alia, kio legiĝas kiel intermita paneo anstataŭ mankanta vojo. La oficiala dokumentaro de la Client VPN-scenario priskribas la aranĝon de publika subreto, al kiu apartenas ĉi tiuj vojoj.

Rajtigo estas la dua objekto. Kiam neniu regulo kovras la publikan celon, la tunelo portas la pakaĵon kaj la servo forĵetas ĝin, do privataj rimedoj plu funkcias dum la interreto ne:

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

Regulo por la CIDR de la VPC diras nenion pri 0.0.0.0/0. Aldoni la mankantajn partojn por plena tunelo signifas unu vojon por ĉiu asociita subreto plus rajtiga regulo, kiun vi povos revizii poste:

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 donas la celon al ĉiu kliento de la finpunkto, do tenu ĝin nur dum la tunelo devas esti plena; regulo ligita al adresara grupo estas preferinda, kiam vi havas grupojn por ligi.

Sekvu la pakaĵon ekster la asociita subreto

La vojo de la finpunkto decidas, ke AWS transdonas la pakaĵon al tiu subreto. Ĝi ne decidas la sekvan salton post ĝi, kiu loĝas en la propra VPC-votabelo de la subreto:

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

Uzebla defaŭlta vojo montras al interreta pordego por publika subreto, aŭ al NAT-pordego por privata, kaj stato blackhole signifas, ke la celo estis forviŝita kaj la vojo nun silente mortas. Ĝi estas malsamaj tabeloj ol la voja listo de la finpunkto, kaj riparo de unu ne riparas la alian.

Sur ĉi tiu salto sidas du filtriloj. La sekureca grupo aplikata al la cela reta asocio devas permesi elirantan trafikon al la publika celo, kaj iu ajn aplikebla reta ACL devas permesi la peton kaj la revenan trafikon sur efemeraj pordoj. Restrikta asocia sekureca grupo estas ofta kaŭzo, kial privata aliro funkcias dum publika ne.

Elektu la unuan tavolon laŭ la simptomo anstataŭ ŝanĝi la tri samtempe:

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

Apartigu DNS-fiaskon de morta vojo

Nomresolvado fiaskas malsame ol plusendado, kaj plena tunelo igas la diferencon grava ĉar la puŝita solvilo nun atingiĝas tra la tunelo. Se la finpunkto specifas VPC DNS-servilojn, iliaj adresoj bezonas vojkovradon kaj rajtigon kiel iu ajn alia celo. Demandu la solvilon rekte por vidi, kiun fiaskon vi havas: dig +short example.com @10.0.0.2, aŭ nslookup example.com 10.0.0.2 en Windows.

Kiam numera URL respondas kaj nomita ne, ĉesu redakti la defaŭltan vojon kaj laboru pri DNS. Peto al IP-adreso pruvas nenion pri nomita virtuala gastiganto kaj ĝia atestilo, do konservu unu nomitan teston en la fina kontrolo.

Tempo helpas. TCP-ligo, kiu ne ricevas respondon ene de kelkaj sekundoj, montras al enkursigado aŭ filtrilo, dum peto, kiu pendas en la nomserĉo, montras al la solvilo. Ŝanĝi la defaŭltan vojon dum la solvilo estas neatingebla emas igi unu fiaskon du.

Restarigu pure, poste kontrolu la eliran vojon

Ambaŭ objektoj estis aldonaĵoj, do restarigo estas forviŝo, ne riparo:

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

Rekonektu, poste konfirmu, per kiu vojo la trafiko eliras. Komparu la observitan publikan adreson kun la elastika IP-adreso de la NAT-pordego, aŭ kun la interreta pordego, kiun vi intencis uzi, kaj kontrolu, ĉu privata rimedo ankoraŭ respondas en la sama sesio.

Finu per mallonga listo kaj traktu la lastan eron kiel parton de la ŝanĝo, ne kiel dokumentaron:

  • Unu 0.0.0.0/0 finpunkta vojo por ĉiu asociita subreto.
  • Rajtiga regulo, kiu kovras 0.0.0.0/0 por la klientoj, kiujn vi volas servi.
  • VPC-defaŭlta vojo, kiu ne estas blackhole, sur ĉiu asociita subreto.
  • Elirejo de la asocia sekureca grupo, plus ACL-revena trafiko.
  • Solvilaj adresoj enkursigitaj kaj rajtigitaj, kontrolitaj per nomita peto.
  • Registrita restarigo por la vojo kaj la regulo.

Unu skopa noto: ĉi tio estas IPv4-vojo. Dual-stack kliento konservas ĉian IPv6-konektecon, kiun ĝi jam havas, do IPv6-defaŭlta vojo estas aparta decido kun propra rajtigo, ne kromefiko de ĉi tiu.

Rilataj artikoloj