AWS Client VPN je připojený, ale internet nefunguje: kontrola tras

AWS Client VPN připojený bez přístupu k internetu? Zkontrolujte trasy klienta, autorizaci koncového bodu, výstup z podsítě a DNS v tomto pořadí.

Jste připojení ke koncovému bodu AWS Client VPN, privátní podsíť odpovídá, a přesto každá veřejná stránka končí časovým limitem. Tahle kombinace zužuje problém na jeden ze tří objektů na spravované straně: trasu, kterou klient instaluje, trasu koncového bodu spolu s jejím autorizačním pravidlem, nebo další skok přidružené podsítě. Kontroluji je v tomto pořadí, protože každá závada vypadá z pohledu klienta jinak. Tento postup se týká spravovaného koncového bodu přidruženého k VPC, ne serveru OpenVPN na instanci EC2 ani připojení Cloud WAN či Transit Gateway.

Začněte tím, co klient skutečně směruje

Stav připojení dokazuje relaci TLS a přidělení CIDR klientovi, nic víc. Zeptejte se operačního systému, kam by veřejná adresa šla, dokud je tunel aktivní. V Linuxu ip route get 1.1.1.1 má uvést rozhraní tunelu; v macOS netstat -rn -f inet | head -5 ukazuje výchozí záznam; ve Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 vypíše zvolené rozhraní a další skok.

Pak přečtěte příznak rozděleného tunelu, protože rozhoduje, zda jsou publikované trasy koncového bodu jedinými cíli, které klient posílá do tunelu:

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

Když je SplitTunnel true, veřejný cíl používá tunel jen tehdy, když koncový bod publikuje trasu, která ho pokrývá, takže chybějící 0.0.0.0/0 nechává tento provoz na místním rozhraní. Když je false, klient provoz zachytí, ale koncový bod ho stále musí směrovat a autorizovat; jinak pakety vstoupí do tunelu a tam se zastaví. Po změně kteréhokoli nastavení připojte klienta znovu, protože trasy a servery DNS se doručují při připojení a běžící klient si může ponechat starou sadu.

Čtěte trasu koncového bodu a autorizační pravidlo odděleně

Jsou to dva objekty a vytvoření jednoho nevytvoří druhý. Vypište trasy koncového bodu a hledejte výchozí trasu, jejímž cílem je přidružená podsíť:

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

Každá trasa má právě jednu cílovou podsíť, takže tři přidružení potřebují odpovídající výchozí trasu pro každé z nich. AWS tento požadavek na pokrytí dokumentuje a praktickým symptomem mezery je uživatel, který pracuje z jedné podsítě a z jiné se zasekává, což vypadá jako občasná závada místo chybějící trasy. Oficiální dokumentace scénáře Client VPN popisuje uspořádání s veřejnou podsítí, ke kterému tyto trasy patří.

Autorizace je druhý objekt. Když veřejný cíl nepokrývá žádné pravidlo, tunel paket přenese a služba ho zahodí, takže privátní prostředky dál fungují, zatímco internet ne:

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

Pravidlo pro CIDR VPC neříká nic o 0.0.0.0/0. Doplnění chybějících částí pro plný tunel znamená jednu trasu na každou přidruženou podsíť plus autorizační pravidlo, které můžete později auditovat:

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 přiděluje cíl každému klientovi koncového bodu, takže ho držte jen dokud má být tunel plný; pravidlo vázané na skupinu adresáře je vhodnější, když máte skupiny k navázání.

Sledujte paket ven z přidružené podsítě

Trasa koncového bodu rozhoduje, že AWS předá paket této podsíti. Nerozhoduje o dalším skoku za ní, který žije ve vlastní směrovací tabulce VPC dané podsítě:

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

Použitelná výchozí trasa ukazuje na internetovou bránu u veřejné podsítě nebo na bránu NAT u privátní a stav blackhole znamená, že cíl byl smazán a cesta teď tiše umírá. Jsou to jiné tabulky než seznam tras koncového bodu a oprava jedné neopraví druhou.

Na tomto skoku stojí dva filtry. Bezpečnostní skupina použitá na síťové přidružení cíle musí povolit odchozí provoz k veřejnému cíli a jakýkoli uplatnitelný síťový ACL musí povolit požadavek i zpětný provoz na efemérních portech. Omezující bezpečnostní skupina přidružení je častý důvod, proč privátní přístup funguje a veřejný ne.

Vyberte první vrstvu podle symptomu, místo abyste měnili všechny tři najednou:

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

Oddělte selhání DNS od mrtvé trasy

Překlad jmen selhává jinak než předávání a plný tunel dělá ten rozdíl podstatným, protože vynucený resolver se teď dosahuje přes tunel. Pokud koncový bod určuje servery DNS ve VPC, jejich adresy potřebují pokrytí trasou a autorizaci jako každý jiný cíl. Zeptejte se resolveru přímo, abyste viděli, které selhání máte: dig +short example.com @10.0.0.2, nebo nslookup example.com 10.0.0.2 ve Windows.

Když číselná URL odpovídá a pojmenovaná ne, přestaňte upravovat výchozí trasu a pracujte na DNS. Požadavek na IP adresu nic nedokazuje o pojmenovaném virtuálním hostiteli a jeho certifikátu, takže si v závěrečné kontrole ponechte jeden pojmenovaný test.

Čas pomáhá. Spojení TCP, které během několika sekund nedostane odpověď, ukazuje na směrování nebo filtr, zatímco požadavek, který visí uvnitř hledání jména, ukazuje na resolver. Změna výchozí trasy, dokud je resolver nedostupný, obvykle promění jednu závadu ve dvě.

Vraťte změny čistě a pak ověřte výstupní cestu

Oba objekty byly přírůstkové, takže vrácení je smazání, ne oprava:

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

Připojte se znovu a potvrďte, kterou cestou provoz odchází. Porovnejte pozorovanou veřejnou adresu s elastickou IP adresou brány NAT nebo s internetovou bránou, kterou jste chtěli použít, a ověřte, že privátní prostředek v téže relaci stále odpovídá.

Skončete krátkým seznamem a poslední položku berte jako součást změny, ne jako dokumentaci:

  • Jedna 0.0.0.0/0 trasa koncového bodu pro každou přidruženou podsíť.
  • Autorizační pravidlo, které pokrývá 0.0.0.0/0 pro klienty, kterým chcete sloužit.
  • Výchozí trasa VPC, která není ve stavu blackhole, na každé přidružené podsíti.
  • Odchozí provoz bezpečnostní skupiny přidružení plus zpětný provoz ACL.
  • Adresy resolveru směrované a autorizované, ověřené pojmenovaným požadavkem.
  • Zaznamenané vrácení pro trasu i pravidlo.

Jedna poznámka k rozsahu: tohle je cesta IPv4. Klient s duálním zásobníkem si ponechá IPv6 konektivitu, kterou už má, takže výchozí trasa IPv6 je samostatné rozhodnutí s vlastní autorizací, ne vedlejší efekt tohoto.

Související články