DNS punktu końcowego AWS Client VPN: dlaczego przypinanie rozwiązanego adresu IP zawodzi

W zeszłym tygodniu dig +short podało jeden adres dla nazwy punktu końcowego w Twoim profilu AWS Client VPN i tunel się połączył. W tym tygodniu ten sam profil stoi na 'Connecting' na Twoim laptopie, podczas gdy nietknięta kopia kolegi nadal działa. Nic nie zostało zablokowane i certyfikat nie wygasł. Ktoś zastąpił nazwę hosta punktu końcowego tym rozwiązanym adresem i usługa już tam nie odpowiada. Wyeksportowana nazwa to część zbudowana tak, by przetrwać tę zmianę.

Nazwa w Twoim profilu może nie być nazwą, o którą pyta klient

Profile eksportowane z Client VPN często zawierają remote-random-hostname. Gdy ta opcja jest włączona, klient tworzy jednorazową etykietę, łączy ją z nazwą punktu końcowego kropką i rozwiązuje połączoną nazwę. Rekord wildcard w strefie punktu końcowego odpowiada na dowolną etykietę, dlatego wymyślony prefiks nadal się rozwiązuje i dlatego sztuczka pozostaje niewidoczna, gdy próbujesz odtworzyć zapytanie ręcznie.

Więc gdy wklejasz nazwę punktu końcowego do terminala i dostajesz odpowiedź, rozwiązałeś inną nazwę niż ta, której klient używa przy połączeniu. Ta rozbieżność nie jest usterką do poprawienia w profilu. Etykieta jest odtwarzana celowo: opcja nie pozwala pamięciom podręcznym trzymać nieaktualnej odpowiedzi i nigdy nie identyfikuje Twojej maszyny ani sesji.

Spotkałem się z przypadkiem zgodności, w którym klient całkowicie ignoruje tę opcję. AWS dokumentuje obejście: zachowaj prawdziwą nazwę punktu końcowego i dodaj przed nią losowy ciąg oraz kropkę, traktując to jako wzorzec nazewnictwa, a nie wartość do wklejenia. Zastosowanie tego do starego klienta jest rozsądne; twarde zakodowanie ciągu z prefiksem jako punktu końcowego już nie.

Dlaczego zapisana odpowiedź nie może pozostać poprawna

Adresy punktów końcowych Client VPN są zarządzane przez AWS i zmieniają się w czasie, co dokumentacja najlepszych praktyk mówi wprost. Przechwycona odpowiedź to migawka jednego rozwiązania. Profil, który ją zakoduje, staje się profilem celującym w wycofany host, gdy tylko usługa się przesunie, a awaria rzadko wygląda jak DNS: dostajesz przekroczenie czasu połączenia albo zawieszony handshake, więc ludzie gonią routing i certyfikaty.

Ta sama odpowiedź w /etc/hosts dziedziczy ten sam termin z dodatkowym problemem. Wpis hosts przeżywa restarty, ponowne eksporty i poprawki 'zainstaluj klienta ponownie', więc awaria wraca za każdym razem, gdy adres się przesunie. Widziałem taki, który tygodniami leżał nieszkodliwie, a potem wyłączył każdą maszynę, która go nosiła, podczas gdy świeże instalacje łączyły się normalnie. Ten podział, jedna grupa zawodzi, a druga jest w porządku na tym samym koncie, to najtańsza wskazówka, jaką dostaniesz.

Ogranicz losowość właściwie. Zachodzi przy każdej próbie połączenia. Ustanowiony tunel nie rozwiązuje ponownie swojego punktu końcowego, nie zmienia serwera w połowie sesji, a pojedyncze żądania aplikacji nie wybierają każde nowego hosta VPN. Dopiero następna próba rozwiązuje ponownie, dlatego sesja działająca całe popołudnie nic nie mówi o jutrzejszym poranku.

Co sprawdza usługa, gdy tunel się podnosi

Client VPN wymaga, aby adres, z którym jesteś połączony, odpowiadał adresowi rozwiązanemu dla nazwy DNS punktu końcowego. To jedno wymaganie wyjaśnia kilka awarii, które wyglądają na niepowiązane: niestandardowy rekord DNS wskazujący gdzie indziej, niestandardowy frontend przekazujący do prawdziwego adresu punktu końcowego oraz profil przepisany na surowy adres. AWS dokumentuje układ niestandardowego rekordu i przekazywania jako awarię z nowszymi klientami od AWS. Sprawdzenie jest wąskie; to nie jest wyrok, że każdy alias jest zabroniony.

To nie jest też ogólna zasada dotycząca protokołów VPN. Numeryczny remote jest całkowicie poprawny w zwykłym wdrożeniu OpenVPN, i wiele tak działa. Ograniczenie wynika z zarządzanego układu, a nie z protokołu pod nim.

Co czyni łagodzenie weryfikacji certyfikatu złym odruchem. Jeśli profil zawodzi po zamianie adresu, wyłączenie weryfikacji serwera przenosi błąd zamiast naprawić rozwiązanie lub wymóg zgodności adresu, i zostawia klienta, który zaufa wszystkiemu. Zachowaj wyeksportowany CA, weryfikację serwera i ustawienia wzajemnego uwierzytelniania dokładnie takie, jakie przyszły.

Listy dozwolonych, egress i prywatny DNS to trzy osobne problemy

Reguła zapory, która musi zezwolić na cel, zanim laptop się połączy, dotyczy zewnętrznego odbiornika. Daj właścicielowi sieci nazwę punktu końcowego, transport i skonfigurowany port, a potem zapytaj, czy ich kontrola potrafi podążać za zachowaniem DNS usługi. Reguła trzymająca jeden przechwycony adres to migawka z niezapisanym terminem ważności. Jeśli kontrola akceptuje tylko niezmienne cele, rozwiąż tę lukę przed wdrożeniem, zamiast po cichu kodować odpowiedź.

Partner, który potrzebuje stałego adresu źródłowego dla żądań po podniesieniu tunelu, ma inne wymaganie: egress. To, co widzi strona, zależy od trasy aplikacji i polityki tunelu dzielonego, a nie od adresu, z którym połączył się klient. Ruch w tunelu dzielonym może w ogóle nie dotykać AWS.

Prywatny DNS wewnątrz tunelu to trzecia warstwa. Resolver przekazany klientom odpowiada na nazwy wewnętrzne po połączeniu; nie może rozwiązać publicznego punktu końcowego, zanim tunel istnieje. Awaria rozwiązania punktu końcowego i awaria rozwiązania aplikacji wewnętrznej zachodzą na różnych etapach, a mieszanie ich prowadzi do złego logu.

Rodzina adresów należy do tej samej listy. Odpowiedź IPv4 nic nie mówi o dozwolonej ścieżce punktu końcowego IPv6 lub dwustosowego, więc migawka z jednej rodziny nie jest dowodem dla drugiej.

Sprawdź połączenie, niczego nie przypinając

Zacznij od profilu takiego, jaki został wyeksportowany, i przeczytaj, o co naprawdę prosi:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Następnie porównaj trzy rzeczy: nazwę punktu końcowego, którą trzyma profil, adres zgłaszany przez klienta dla nowej próby i to, na co nazwa rozwiązuje się teraz. Nazwa, która się rozwiązuje, dowodzi tylko, że rekord odpowiada; transport i uwierzytelnianie są osobne, a punkt końcowy nie musi odpowiadać na ping. Własny log klienta to jedyne źródło środkowej pozycji, więc przechwyć go podczas próby, a nie po niej.

Adres, który odpowiada dziś, jest dowodem o dniu dzisiejszym; nazwa jest tym, co usługa utrzymuje jako ważne. Zapisz obserwację, wyślij ją do właściciela punktu końcowego i zostaw profil wskazujący na nazwę.

Dwa nawyki do porzucenia: wyłączanie sprawdzania certyfikatów, by przejść zawieszony handshake, oraz układanie etykiet przed nazwą punktu końcowego w nadziei, że jedna się utrzyma. Etykieta rozwiązuje się przez rekord wildcard albo problem jest gdzie indziej. Jeśli poprawnie skonfigurowany profil nadal zawodzi, wyślij dokładne zapytanie i zdarzenie połączenia, a nie dłuższą nazwę hosta.

Zanim to zamkniesz: profil nadal niesie wyeksportowaną nazwę punktu końcowego, żaden plik hosts nie przypina adresu, remote w logu klienta odpowiada bieżącemu rozwiązaniu, a reguła zapory wymienia punkt końcowy, a nie adres. To także stan, który przekazujesz następnej osobie.