AWS Client VPN je pripojený, ale internet nefunguje: kontrola trás

AWS Client VPN pripojený bez prístupu na internet? Skontrolujte trasy klienta, autorizáciu koncového bodu, výstup z podsiete a DNS v tomto poradí.

Ste pripojení ku koncovému bodu AWS Client VPN, privátna podsieť odpovedá, a napriek tomu každá verejná stránka končí časovým limitom. Táto kombinácia zužuje problém na jeden z troch objektov na spravovanej strane: trasu, ktorú klient nainštaluje, trasu koncového bodu spolu s jej autorizačným pravidlom, alebo ďalší skok priradenej podsiete. Kontrolujem ich v tomto poradí, pretože každá porucha vyzerá z pohľadu klienta inak. Tento postup sa týka spravovaného koncového bodu priradeného k VPC, nie servera OpenVPN na inštancii EC2 ani pripojenia Cloud WAN či Transit Gateway.

Začnite tým, čo klient skutočne smeruje

Stav pripojenia dokazuje reláciu TLS a pridelenie CIDR klientovi, nič viac. Opýtajte sa operačného systému, kam by verejná adresa išla, kým je tunel aktívny. V Linuxe ip route get 1.1.1.1 má uviesť rozhranie tunela; v macOS netstat -rn -f inet | head -5 zobrazuje predvolený záznam; vo Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 vypíše zvolené rozhranie a ďalší skok.

Potom prečítajte príznak rozdeleného tunela, pretože rozhoduje, či sú publikované trasy koncového bodu jedinými cieľmi, ktoré klient posiela do tunela:

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

Keď je SplitTunnel true, verejný cieľ používa tunel len vtedy, keď koncový bod publikuje trasu, ktorá ho pokrýva, takže chýbajúca 0.0.0.0/0 necháva túto prevádzku na lokálnom rozhraní. Keď je false, klient prevádzku zachytí, ale koncový bod ju stále musí smerovať a autorizovať; inak pakety vstúpia do tunela a tam sa zastavia. Po zmene ktoréhokoľvek nastavenia pripojte klienta znova, pretože trasy a servery DNS sa doručujú pri pripojení a bežiaci klient si môže ponechať starú sadu.

Čítajte trasu koncového bodu a autorizačné pravidlo oddelene

Sú to dva objekty a vytvorenie jedného nevytvorí druhý. Vypíšte trasy koncového bodu a hľadajte predvolenú trasu, ktorej cieľom je priradená podsieť:

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

Každá trasa má práve jednu cieľovú podsieť, takže tri priradenia potrebujú zodpovedajúcu predvolenú trasu pre každé. AWS tento požiadavok na pokrytie dokumentuje, a praktickým príznakom medzery je používateľ, ktorý pracuje z jednej podsiete a z inej sa zasekne, čo sa číta ako občasná porucha namiesto chýbajúcej trasy. Oficiálna dokumentácia scenára Client VPN opisuje usporiadanie s verejnou podsieťou, ku ktorému tieto trasy patria.

Autorizácia je druhý objekt. Keď verejný cieľ nepokrýva žiadne pravidlo, tunel paket prenesie a služba ho zahodí, takže privátne prostriedky ďalej fungujú, zatiaľ čo internet nie:

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

Pravidlo pre CIDR VPC nehovorí nič o 0.0.0.0/0. Doplnenie chýbajúcich častí pre plný tunel znamená jednu trasu na každú priradenú podsieť plus autorizačné pravidlo, ktoré môžete neskôr auditovať:

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 prideľuje cieľ každému klientovi koncového bodu, preto ho držte len kým má byť tunel plný; pravidlo naviazané na skupinu adresára je vhodnejšie, keď máte skupiny na naviazanie.

Sledujte paket von z priradenej podsiete

Trasa koncového bodu rozhoduje, že AWS odovzdá paket tejto podsieti. Nerozhoduje o ďalšom skoku za ňou, ktorý žije vo vlastnej smerovacej tabuľke VPC danej podsiete:

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

Použiteľná predvolená trasa ukazuje na internetovú bránu pre verejnú podsieť alebo na bránu NAT pre privátnu a stav blackhole znamená, že cieľ bol vymazaný a cesta teraz ticho umiera. Sú to iné tabuľky než zoznam trás koncového bodu a oprava jednej neopraví druhú.

Na tomto skoku stoja dva filtre. Bezpečnostná skupina použitá na sieťové priradenie cieľa musí povoliť odchádzajúcu prevádzku k verejnému cieľu a akýkoľvek uplatniteľný sieťový ACL musí povoliť požiadavku aj spätnú prevádzku na efemérnych portoch. Obmedzujúca bezpečnostná skupina priradenia je častý dôvod, prečo privátny prístup funguje a verejný nie.

Vyberte prvú vrstvu podľa príznaku, namiesto toho aby ste menili všetky tri naraz:

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

Oddeľte zlyhanie DNS od mŕtvej trasy

Preklad názvov zlyháva inak než preposielanie a plný tunel robí ten rozdiel podstatným, pretože vynútený resolver sa teraz dosahuje cez tunel. Ak koncový bod určuje servery DNS vo VPC, ich adresy potrebujú pokrytie trasou a autorizáciu ako každý iný cieľ. Opýtajte sa resolvera priamo, aby ste videli, ktoré zlyhanie máte: dig +short example.com @10.0.0.2, alebo nslookup example.com 10.0.0.2 vo Windows.

Keď číselná URL odpovedá a pomenovaná nie, prestaňte upravovať predvolenú trasu a pracujte na DNS. Požiadavka na IP adresu nič nedokazuje o pomenovanom virtuálnom hostiteľovi a jeho certifikáte, preto si v záverečnej kontrole ponechajte jeden pomenovaný test.

Čas pomáha. Spojenie TCP, ktoré do niekoľkých sekúnd nedostane odpoveď, ukazuje na smerovanie alebo filter, zatiaľ čo požiadavka, ktorá visí v hľadaní názvu, ukazuje na resolver. Zmena predvolenej trasy, kým je resolver nedostupný, zvyčajne premení jednu poruchu na dve.

Vráťte zmeny čisto a potom overte výstupnú cestu

Oba objekty boli prírastkové, takže vrátenie je vymazanie, nie 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

Pripojte sa znova a potvrďte, ktorou cestou prevádzka odchádza. Porovnajte pozorovanú verejnú adresu s elastickou IP adresou brány NAT alebo s internetovou bránou, ktorú ste chceli použiť, a overte, že privátny prostriedok v tej istej relácii stále odpovedá.

Skončite krátkym zoznamom a poslednú položku berte ako súčasť zmeny, nie ako dokumentáciu:

  • Jedna 0.0.0.0/0 trasa koncového bodu pre každú priradenú podsieť.
  • Autorizačné pravidlo, ktoré pokrýva 0.0.0.0/0 pre klientov, ktorým chcete slúžiť.
  • Predvolená trasa VPC, ktorá nie je v stave blackhole, na každej priradenej podsieti.
  • Odchádzajúca prevádzka bezpečnostnej skupiny priradenia plus spätná prevádzka ACL.
  • Adresy resolvera smerované a autorizované, overené pomenovanou požiadavkou.
  • Zaznamenané vrátenie pre trasu a pravidlo.

Jedna poznámka k rozsahu: toto je cesta IPv4. Klient s duálnym zásobníkom si ponechá IPv6 konektivitu, ktorú už má, takže predvolená trasa IPv6 je samostatné rozhodnutie s vlastnou autorizáciou, nie vedľajší efekt tohto.

Súvisiace články