AWS Client VPN połączony, ale brak internetu: sprawdzanie tras

Jesteś połączony z punktem końcowym AWS Client VPN, prywatna podsieć odpowiada, a każda publiczna strona nadal kończy się przekroczeniem czasu. Ta kombinacja zawęża problem do jednego z trzech obiektów po stronie zarządzanej: trasy instalowanej przez klienta, trasy punktu końcowego wraz z regułą autoryzacji albo następnego skoku powiązanej podsieci. Sprawdzam je w tej kolejności, bo każda awaria wygląda inaczej z perspektywy klienta. Ten poradnik dotyczy zarządzanego punktu końcowego powiązanego z VPC, a nie serwera OpenVPN na instancji EC2 ani połączenia Cloud WAN lub Transit Gateway.

Zacznij od tego, co klient rzeczywiście trasuje

Stan połączenia dowodzi sesji TLS i przypisania CIDR klientowi, niczego więcej. Zapytaj system operacyjny, dokąd trafiłby adres publiczny, gdy tunel jest aktywny. W Linuksie ip route get 1.1.1.1 powinno wskazać interfejs tunelu; w macOS netstat -rn -f inet | head -5 pokazuje wpis domyślny; w Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 wypisuje wybrany interfejs i następny skok.

Następnie odczytaj flagę split-tunnel, bo decyduje ona, czy trasy publikowane przez punkt końcowy są jedynymi celami, które klient wysyła do tunelu:

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

Gdy SplitTunnel ma wartość true, cel publiczny korzysta z tunelu tylko wtedy, gdy punkt końcowy publikuje trasę, która go obejmuje, więc brakująca 0.0.0.0/0 zostawia ten ruch na interfejsie lokalnym. Gdy ma wartość false, klient przechwytuje ruch, ale punkt końcowy nadal musi go trasować i autoryzować; inaczej pakiety wchodzą do tunelu i tam się zatrzymują. Po zmianie któregokolwiek z tych ustawień połącz klienta ponownie, bo trasy i serwery DNS są dostarczane w momencie połączenia, a działający klient może zachować stary zestaw.

Czytaj trasę punktu końcowego i regułę autoryzacji osobno

To dwa obiekty, a utworzenie jednego nie tworzy drugiego. Wylistuj trasy punktu końcowego i poszukaj trasy domyślnej, której celem jest powiązana podsieć:

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

Każda trasa ma dokładnie jedną podsieć docelową, więc trzy powiązania potrzebują odpowiedniej trasy domyślnej dla każdego. AWS dokumentuje ten wymóg pokrycia, a praktycznym objawem luki jest użytkownik, który pracuje z jednej podsieci i zatyka się z innej, co czyta się jako okresowa awaria, a nie brakująca trasa. Oficjalna dokumentacja scenariusza Client VPN opisuje układ publicznej podsieci, do którego należą te trasy.

Autoryzacja to drugi obiekt. Gdy żadna reguła nie obejmuje celu publicznego, tunel niesie pakiet, a usługa go odrzuca, więc zasoby prywatne nadal działają, a internet nie:

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

Reguła dla CIDR VPC nie mówi nic o 0.0.0.0/0. Dodanie brakujących elementów dla pełnego tunelu oznacza jedną trasę na powiązaną podsieć plus regułę autoryzacji, którą można później przeaudytować:

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 przyznaje cel każdemu klientowi punktu końcowego, więc trzymaj ją tylko dopóki tunel ma być pełny; reguła powiązana z grupą katalogu jest lepsza, gdy masz grupy do powiązania.

Śledź pakiet na zewnątrz powiązanej podsieci

Trasa punktu końcowego decyduje, że AWS przekazuje pakiet tej podsieci. Nie decyduje o następnym skoku za nią, który mieszka we własnej tabeli tras VPC podsieci:

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

Użyteczna trasa domyślna wskazuje na bramę internetową dla podsieci publicznej albo na bramę NAT dla prywatnej, a stan blackhole oznacza, że cel został usunięty i ścieżka teraz cicho umiera. To inne tabele niż lista tras punktu końcowego, a naprawa jednej nie naprawia drugiej.

Na tym skoku siedzą dwa filtry. Grupa zabezpieczeń zastosowana do powiązania sieci docelowej musi zezwalać na ruch wychodzący w kierunku celu publicznego, a każda mająca zastosowanie lista ACL sieci musi zezwalać na żądanie i ruch powrotny na portach efemerycznych. Restrykcyjna grupa zabezpieczeń powiązania to częsta przyczyna tego, że dostęp prywatny działa, a publiczny nie.

Wybierz pierwszą warstwę na podstawie objawu, zamiast zmieniać wszystkie trzy naraz:

Oddziel awarię DNS od martwej trasy

Rozwiązywanie nazw zawodzi inaczej niż przekazywanie, a pełny tunel sprawia, że ta różnica ma znaczenie, bo do wymuszonego resolvera dociera się teraz przez tunel. Jeśli punkt końcowy podaje serwery DNS VPC, ich adresy potrzebują pokrycia trasą i autoryzacji jak każdy inny cel. Zapytaj resolver bezpośrednio, aby zobaczyć, która awaria występuje: dig +short example.com @10.0.0.2, lub nslookup example.com 10.0.0.2 w Windows.

Gdy odpowiada adres URL z liczbami, a nazwany nie, przestań edytować trasę domyślną i zajmij się DNS. Żądanie do adresu IP niczego nie dowodzi w kwestii nazwanego hosta wirtualnego i jego certyfikatu, więc zachowaj jeden test z nazwą w końcowym sprawdzeniu.

Czas pomaga. Połączenie TCP, które w ciągu kilku sekund nie otrzymuje odpowiedzi, wskazuje na trasowanie lub filtr, natomiast żądanie wiszące w wyszukiwaniu nazwy wskazuje na resolver. Zmiana trasy domyślnej, gdy resolver jest nieosiągalny, zwykle zamienia jedną awarię w dwie.

Wycofaj zmiany czysto, a potem zweryfikuj ścieżkę wyjścia

Oba obiekty były dodawane, więc wycofanie to usunięcie, a nie naprawa:

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

Połącz się ponownie i potwierdź, którą ścieżką ruch wychodzi. Porównaj zaobserwowany adres publiczny z elastycznym adresem IP bramy NAT albo z bramą internetową, której zamierzałeś użyć, i sprawdź, czy zasób prywatny nadal odpowiada w tej samej sesji.

Zakończ krótką listą i potraktuj ostatni punkt jako część zmiany, a nie dokumentację:

• Jedna 0.0.0.0/0 trasa punktu końcowego dla każdej powiązanej podsieci.
• Reguła autoryzacji obejmująca 0.0.0.0/0 dla klientów, którym chcesz służyć.
• Trasa domyślna VPC, która nie jest w stanie blackhole, na każdej powiązanej podsieci.
• Wyjście grupy zabezpieczeń powiązania plus ruch powrotny ACL.
• Adresy resolvera trasowane i autoryzowane, zweryfikowane żądaniem z nazwą.
• Zapisane wycofanie dla trasy i reguły.

Jedna uwaga o zakresie: to ścieżka IPv4. Klient z podwójnym stosem zachowuje łączność IPv6, którą już ma, więc domyślna trasa IPv6 jest osobną decyzją z własną autoryzacją, a nie skutkiem ubocznym tej.