Nazwy wewnętrzne nie działają w VPN, gdy publiczne witryny rozwiązują się poprawnie

Jeden użytkownik zgłasza, że nazwa hosta intranetowego nie rozwiązuje się przez VPN. Drugie zgłoszenie, z tego samego laptopa, mówi, że test wycieku nadal pokazuje zapytania odpowiadane przez lokalny resolver. Brzmią jak jeden problem, a są dwa, z różnymi dowodami, a zwykła naprawa pierwszego pogarsza drugi. Rozdziel je, zanim dotkniesz jakiegokolwiek ustawienia.

Dwa objawy, które nie są jedną usterką

Brak rozwiązania nazwy wewnętrznej oznacza, że pytanie trafiło tam, gdzie nie ma na nie odpowiedzi. Zapytania opuszczające tunel oznaczają, że pytanie trafiło w złe miejsce, nawet gdy odpowiedź była dostępna. To przeciwne awarie: jedna to brakująca odpowiedź, druga to dodatkowe miejsce docelowe.

Pułapka polega na tym, że dodanie resolvera biurowego wszędzie naprawia pierwsze i gwarantuje drugie. Dodanie publicznego resolvera wszędzie działa odwrotnie.

Zapisz obie obserwacje ze znacznikiem czasu, a następnie przejdź przez cztery kontrole poniżej po kolei.

Który adapter przekazuje pytanie swojemu resolverowi

W systemie Windows klient DNS wybiera serwery zgodnie z kolejnością powiązań adapterów, a adapter tunelu nie jest automatycznie pierwszy. Otwórz ustawienia zaawansowane adaptera, przenieś połączenie dostępu zdalnego powyżej adaptera fizycznego, a następnie połącz się ponownie, aby zmiana zadziałała w nowej sesji.

Kolejność powiązań to tylko połowa. Klient musi także wiedzieć, które nazwy należą do tego adaptera, a to pytanie o sufiks, nie o kolejność.

Połóż ipconfig /all działającej maszyny obok tego z laptopa, oba wykonane przy aktywnym tunelu. Działająca maszyna pokaże sufiks DNS właściwy dla połączenia na adapterze biurowym, a laptop może nie pokazać żadnego na tunelu. Ta różnica wyjaśnia całą klasę zgłoszeń, że serwer jest na miejscu, a nazwa nadal zawodzi, bo bez sufiksu krótka nazwa nigdy nie zostaje uzupełniona do strefy obsługiwanej przez resolver biurowy.

Krótka nazwa potrzebuje sufiksu, zanim potrzebuje trasy

Wpisanie niekwalifikowanej nazwy hosta prosi resolver o zgadnięcie domeny. Zgadywanie pochodzi z listy sufiksów przypisanej do połączenia, a jeśli ta lista jest pusta, zapytanie wychodzi jako jedna etykieta, której nie dopasuje żadna strefa prywatna.

Skopiuj sufiks działającej maszyny do właściwości IPv4 adaptera VPN na karcie DNS, a następnie połącz się ponownie. W systemie Linux odpowiednikiem jest domena wyszukiwania na łączu tunelu, którą systemd-resolved udostępnia osobno dla każdego łącza, a nie globalnie.

Trzymaj te dwa ustawienia osobno w notatkach. Sufiks zmienia to, o co się pyta; adres resolvera zmienia to, kogo się pyta. Naprawienie jednego, gdy drugie jest błędne, daje wynik, który wygląda losowo.

Zapytaj najpierw resolver bezpośrednio, potem o nazwę

Bezpośrednie zapytanie do resolvera biurowego oddziela problem nazwy od problemu ścieżki, ponieważ całkowicie omija wybór resolvera przez klienta.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Pierwsze polecenie prosi konkretny serwer o w pełni kwalifikowaną nazwę. Jeśli odpowie, resolver i trasa do niego są w porządku, a usterka tkwi w wyborze lub sufiksie. Jeśli kończy się przekroczeniem czasu, adres jest błędny lub nieosiągalny, a problem dotyczy routingu, nie DNS. Drugie polecenie pokazuje, co dzieje się z krótką nazwą, a trzecie wypisuje konfigurację resolvera dla łącza na hoście z systemd.

Uważaj na odpowiedzi z dziką kartą, które niektóre sieci zwracają dla nieznanych nazw. Odpowiedź, która wygląda wiarygodnie, nie dowodzi, że odpowiedział zamierzony serwer, więc porównaj zwrócony adres z tym, którego faktycznie używa usługa wewnętrzna. Jeśli adres należy do strony parkingowej lub proxy, resolver odpowiedział, ale odpowiedź nigdy nie była twoja. To rozróżnienie oszczędza godzinę ścigania tunelu, który przez cały czas działał.

W systemie Linux klient VPN, który przepisuje /etc/resolv.conf, całkowicie zastępuje lokalne resolvery. vpnc udostępnia DNSUpdate no, aby to zatrzymać, a systemd-resolved może kierować tylko wymienione domeny do łącza tunelu. Oba podejścia trzymają nazwy publiczne przy lokalnym resolverze, wysyłając nazwy wewnętrzne do biura.

Wycieki to reguła, nie pole wyboru

Rozwiązywanie nazw to wymiana UDP na port 53, więc tunel, który przenosi ruch webowy, ale nie UDP, zostawia zapytanie na ścieżce fizycznej. Udowodnij to, przechwytując ruch na fizycznej karcie sieciowej podczas rozwiązywania nazwy publicznej. Zapytanie widoczne na tym interfejsie w czytelnej formie oznacza, że tunel go nie przenosi.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Jeśli zapytanie pojawia się na tym interfejsie w czytelnej formie, tunel go nie przenosi. Naprawą jest reguła, która zezwala na port 53 tylko do resolvera wypchniętego przez VPN i odrzuca inne cele, plus konfiguracja klienta, która nie odrzuca po cichu wypchniętej opcji.

Ostatnia część jest ważniejsza, niż wygląda. Uruchom OpenVPN z route-nopull, a wypchnięta opcja DNS zniknie razem z trasami, chyba że filtr pobierania zostanie poszerzony, aby ją zachować. Klient, który ignoruje dhcp-option DNS, będzie dalej używał tego, co miał wcześniej. Każda zmiana po stronie serwera wymaga nowej sesji, aby zadziałała, ponieważ lista resolverów jest dostarczana przy podnoszeniu tunelu, a stara sesja nadal pokazuje stary stan.

Zapisz, którą awarię faktycznie zaobserwowałeś, zanim zamkniesz zgłoszenie. Brakująca odpowiedź wewnętrzna i zapytanie uciekające z tunelu wymagają różnych napraw, a zmiana sufiksu, która naprawia pierwszą, może po cichu pogorszyć drugą. Kto przejmie zgłoszenie później, zaufa etykiecie, więc zadbaj, by etykieta była trafna.