Tunel dzielony wyklucza przeglądarkę, nie jej zapytania DNS

Przeglądarka wykluczona z tunelu, strona publicznego IP potwierdza, że jej ruch wychodzi przez domowe połączenie, a wewnętrzna wiki nadal się nie otwiera. Rozwiązywanie nazw poszło gdzie indziej, a to gdzie indziej to zwykle resolver ustawiony przez VPN. Ścieżka danych i ścieżka resolvera to w większości projektów tunelu dzielonego osobne decyzje. Sprawdź, której przeglądarka faktycznie użyła, zanim nazwiesz wykluczenie zepsutym.

Ścieżka danych i ścieżka resolvera się rozdzielają

Wykluczenie usuwa pakiety aplikacji z tunelu, co jest decyzją o routingu i zaporze na ścieżce danych. Rozwiązywanie nazw to inne wyszukiwanie: proces pyta resolver systemu, a ten resolver decyduje, który serwer otrzyma pytanie.

Oba mogą być zamierzone i różne. Wdrożenie firmowe może trzymać wewnętrzne przestrzenie nazw na resolverze korporacyjnym, a wybrane przeglądanie publiczne wysyłać poza tunel, właśnie dlatego że nazwy wewnętrzne nigdzie indziej się nie rozwiązują. Mylący przypadek jest odwrotny: publiczna witryna zawodzi, bo przeglądarka nigdy nie zapytała resolvera, którego oczekiwało wdrożenie. Zapisz trasę i resolver osobno, a połowa sporów znika.

Ustal, który proces zadaje pytanie

Przeglądarka może używać resolvera systemu, własnej usługi szyfrowanego DNS albo resolvera, który system operacyjny przypisuje dla każdej sieci. Pierwszy działa zgodnie z polityką platformy, drugi całkowicie ją omija, a trzeci zależy od tego, do którego łącza kierowane jest zapytanie.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Przeczytaj obowiązującą konfigurację przed testowaniem: które łącza niosą serwery DNS, jakich przestrzeni nazw wymagają i czy polityka dla pojedynczej nazwy zastępuje domyślną. W Linuksie dzielony DNS używa domen routingu; w Windows tabela zasad rozwiązywania nazw robi to samo dla przestrzeni nazw. Żadnego z nich nie widać ze strony testu wycieku.

Zdecyduj, który resolver widzi którą nazwę

Zapisz zamierzone mapowanie, zanim cokolwiek zmienisz: nazwy wewnętrzne do resolvera korporacyjnego, nazwy publiczne do usługi, której pozwala polityka, a wyjątki z osobą odpowiedzialną. Bez tej listy każda etykieta testu wycieku staje się sporem o politykę, którego nikt nie potrafi rozstrzygnąć.

Następnie sprawdź ustawienie samej przeglądarki, bo szyfrowany DNS w przeglądarce jest stosowany, zanim system operacyjny otrzyma zapytanie. Użytkownik, który włączył go, by obejść portal przechwytujący, po cichu nadpisał resolver wybrany przez wdrożenie. To decyzja konfiguracyjna, a nie wyciek, i zasługuje na decyzję, a nie na listę blokad.

Nie przepisuj każdego pola DNS, żeby jedna etykieta testu stała się zielona. Etykieta opisuje jedno zapytanie jednego procesu w jednej chwili.

Sprawdź zapytanie i połączenie osobno

Testuj obie ścieżki niezależnie. Test połączenia pokazuje trasę danych, a test resolvera pokazuje, kto otrzymał nazwę.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Zapytaj resolvera także wprost, żeby niepowodzenie można było przypisać serwerowi, a nie ścieżce. Potem uruchom przeglądarkę ponownie i powtórz, bo aplikacje buforują negatywne odpowiedzi, a stary błąd wygląda na trwały.

Po zatwierdzonej zmianie zapisz trasę danych i odbiorcę resolvera jako dwie osobne linie z datą. Jeśli zachowanie wróci przy następnym połączeniu, poprawić trzeba profil, który je dostarcza, a nie przeglądarkę.