DNS w AWS Client VPN: użyj resolvera VPC, a nie podsieci

Endpoint znajduje się w 10.0.8.0/24, więc resolver musi być 10.0.8.2. To najczęściej słyszane rozumowanie i jest błędne dwukrotnie. Route 53 Resolver odpowiada w głównym zakresie IPv4 VPC plus dwa, co dla VPC 10.0.0.0/16 oznacza 10.0.0.2, niezależnie od tego, której podsieci używa endpoint. Drugi błąd jest cichszy: wpisanie poprawnego adresu w endpoincie nie oznacza, że system operacyjny klienta kiedykolwiek o coś go zapyta. Oba błędy dają ten sam objaw: rozwiązywanie nazw działa u niektórych klientów, a u innych zawodzi.

Mit zaczyna się od skojarzenia podsieci

Skojarzenie dotyczy tego, gdzie mieszkają elastyczne interfejsy sieciowe połączeń klienckich, a nie tego, który adres resolvera istnieje. Podsieci endpointu dają klientom adres wewnątrz VPC i żadna z nich nie ma własnego resolvera.

Gdy rozdzielisz te dwie idee, arytmetyka przestaje być zagadkowa, a rozwiązywanie problemów przenosi się do klienta, gdzie większość takich przypadków faktycznie się kończy.

Oblicz adres z głównego zakresu VPC

Weź główny CIDR IPv4 VPC i dodaj dwa do adresu sieci. 10.0.0.0/16 daje 10.0.0.2, 172.31.0.0/16 daje 172.31.0.2, a VPC z zakresem dodatkowym trzyma resolver w głównym. Podsieć 10.0.8.0/24 w tym VPC go nie przesuwa. Zapisz adres obok ID VPC, zanim dotkniesz endpointu, bo liczba jest właściwością VPC, a nie połączenia.

VPC odpowiada także na adresie link-local 169.254.169.253. Ten adres jest osiągalny z wnętrza VPC, ale nie jest ogólnym trasowanym celem dla laptopa po drugiej stronie tunelu.

Są więc dwa poprawne adresy resolvera i żaden z nich nie jest podsiecią plus dwa.

Co robi ustawienie endpointu, a czego nie

Endpoint Client VPN ma pola serwera DNS, a tam gdzie konsola oferuje opcję resolvera VPC, wpisuje tę samą ideę. Ustawienie ich zmienia to, co usługa przekazuje klientom podczas nawiązywania połączenia. Nie zmienia tego, co niezarządzany klient OpenVPN robi z tą wartością, bo klient nadal musi zastosować ją w systemie operacyjnym. Z tej luki bierze się „działa na moim Macu, ale nie na maszynie Linux”.

W Linuksie integracja resolvera należy do menedżera połączeń, a nie do użytkownika. Ręczna edycja /etc/resolv.conf dowodzi, że adres działa dla jednej sesji, a potem znika przy ponownym połączeniu — dlatego tyle naprawionych przypadków wraca następnego ranka.

Sprawdź aktywny resolver na kliencie po połączeniu, a nie stronę konfiguracji endpointu.

Split tunneling może pokonać poprawny resolver

Przy split tunelingu używane są tylko trasy wepchnięte do tunelu. Jeśli adres resolvera nie jest objęty trasą, zapytanie wychodzi przez interfejs lokalny i odpowiada na nie domowy router. Adres w endpoincie nadal jest poprawny, a wyszukiwanie nadal zawodzi. Dodaj trasę dla resolvera, a potem przetestuj ponownie.

Nakładające się zakresy lokalne dają ten sam wynik w bardziej przykry sposób: zapytanie dostaje odpowiedź, tylko od niewłaściwego serwera.

Nie otwieraj grup bezpieczeństwa dla adresu Amazon DNS

Odruch, gdy wyszukiwania przekraczają czas, to dodanie reguły zezwalającej na UDP 53 do adresu resolvera. AWS dokumentuje, że grupy bezpieczeństwa i listy ACL sieci nie filtrują ruchu Amazon DNS tak, jak filtrują ruch do własnej instancji DNS. Otwarcie tych reguł nic nie zmienia dla resolvera VPC i bez powodu poszerza granicę. Resolver, który prowadzisz sam, to inny przypadek i naprawdę potrzebuje własnych reguł.

Jeśli oba występują w twoim projekcie, sprawdź, na który klient faktycznie wskazuje, zanim edytujesz jakąkolwiek regułę.

Sprawdź ścieżkę, a potem zmierz coś innego

Rozwiąż nazwę publiczną, rozwiąż nazwę prywatną zarejestrowaną w prywatnej strefie hostowanej powiązanej z VPC i odczytaj pomiędzy nimi aktywny resolver klienta. Ta kolejność oddziela „adres resolvera jest błędny” od „strefa nie jest powiązana” i od „klient zignorował ustawienie”. Każdy ma inną poprawkę i żaden nie jest problemem przepustowości.

Udane wyszukiwanie nic nie mówi o trwałej prędkości przesyłania, więc trzymaj te dwie rozmowy osobno, gdy raportujesz.