Geograficzny DNS i anycast: sprawdzanie punktu wejścia VPN, który otrzymujesz

Pobliska odpowiedź DNS wydaje się rozwiązaniem problemu, dopóki połączenie nie wyląduje gdzie indziej. Geograficzny DNS i anycast próbują skrócić ścieżkę, ale podejmują tę decyzję na podstawie różnych informacji. Żaden z nich nie gwarantuje, że brama, do której docierasz, jest osiągalna, że przedstawia tożsamość oczekiwaną przez klienta ani że sesja przetrwa zmianę węzła. Poniższe kontrole rozdzielają te cztery pytania.

Sprawdź, czyją lokalizację faktycznie raportuje resolver

Serwer autorytatywny odpowiadający na zapytanie wrażliwe na topologię zwykle widzi adres rekurzyjnego resolvera, który zapytał, a nie adres osoby, która wpisała nazwę. Scentralizowany resolver może znajdować się daleko od obsługiwanych klientów, a odpowiedź odzwierciedla resolver, a nie ich. To nie jest defekt; tak zachowuje się protokół, dopóki nie dostarczy się dodatkowych informacji. Specyfikacja EDNS Client Subnet opisuje zarówno ograniczenie, jak i opcjonalne rozwiązanie.

EDNS Client Subnet może przenosić informacje o sieci pochodzenia, gdy każdy uczestnik go obsługuje i włączy. Jest opcjonalny, ma konsekwencje dla prywatności i buforowania, i nie jest pozwoleniem na założenie, że jakikolwiek publiczny resolver raportuje dokładną lokalizację użytkownika. Zapytaj operatorów resolverów, zanim zaprojektujesz rozwiązanie w oparciu o niego.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Sprawdź, co zdecydowało trasowanie anycast

W anycast wiele lokalizacji ogłasza osiągalność jednego adresu usługi, a sieć dostarcza każdego klienta do węzła preferowanego przez trasowanie. Tę decyzję podejmuje BGP i otaczająca go polityka, a nie odległość na mapie. Bliskość topologiczna na ogół nie oznacza też lepszej wydajności w obie strony, ponieważ ścieżka, która wygląda krótko, może być przeciążona lub asymetryczna. Otrzymany adres nie mówi nic o tym, który węzeł odpowiedział.

Potwierdź lokalizację obsługującą po stronie usługi lub z odpowiedzi, która ją nazywa, a nie tylko z odpowiedzi DNS. traceroute -n 198.51.100.20 pokazuje ścieżkę, którą przebyłeś, i nadal nie nazywa hosta na jej końcu, więc czytaj ją jako ścieżkę, a nie jako odpowiedź.

Sprawdź, czy sesja przetrwa zmianę węzła

Zapytanie DNS jest krótkie, a sesja VPN długa, i oba mają zupełnie inne wymagania dotyczące stanu. Trasowanie może zmienić się w trakcie sesji, a gdy tak się stanie, późniejsze pakiety mogą dotrzeć do węzła, który nigdy nie widział twojego tunelu. To, czy jest to do przetrwania, zależy od implementacji: współdzielony stan, celowe ponowne połączenie lub udokumentowana awaria. Sam adres nie zapewnia żadnego z nich.

Obserwuj zmianę, zamiast ją zakładać. sudo tcpdump -ni any -c 20 esp pokazuje pakiety zewnętrzne w miarę zmiany ścieżki, a nagła zmiana adresu peera to właśnie zachodząca zmiana. Zdefiniuj zamierzone zachowanie wprost dla uruchamianej implementacji, a następnie przetestuj je, wymuszając zmianę ścieżki. Jeśli projekt zakłada replikację sesji, nazwij mechanizm i nazwij awarię, której nie obejmuje.

Sprawdź, czy tożsamość nadal się zgadza

Każdy punkt wejścia musi przedstawiać tożsamość oczekiwaną przez profil klienta. Certyfikat wystawiony dla nazwy usługi działa w obrębie węzłów, natomiast certyfikaty dla poszczególnych węzłów zmuszają klienta do zaakceptowania czegoś nowego i właśnie tam użytkownicy uczą się klikać przez ostrzeżenia. Utrzymuj oczekiwaną tożsamość i profil spójne z modelem wejścia.

Sprawdź to z klienta, który dotarł do nietypowego węzła, ponieważ to przypadek, w którym certyfikat dla węzła staje się widoczny. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com wypisuje łańcuch i nazwy, czyli dokładnie to, co porównuje klient. Następnie zdecyduj, czy zawęzić profil, czy zmienić model certyfikatów.

Sprawdź zapis, nie tylko pierwszą odpowiedź

Oceń trzy scenariusze i zapisz dla każdego cztery fakty: normalne wejście, niedostępna lokalizacja i uzgodniony przypadek odzyskiwania. Cztery fakty to użyty resolver, zwrócony adres, lokalizacja, która obsłużyła połączenie, oraz świeży wynik aplikacji. Ten zapis oddziela problem wyboru DNS od problemu bramy, problemu trasowania lub problemu stanu sesji. Bez niego wszystkie cztery wyglądają z klienta identycznie.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Uruchamiaj scenariusze z reprezentatywnych sieci dostępowych, a nie tylko z biura, ponieważ całe pytanie dotyczy tego, do którego punktu wejścia różni klienci faktycznie docierają. Jedna sieć to próbka jednego.