Wyciek DNS w VPN na Windows: dlaczego metryka wygrywa z trasą

Zapytanie opuszcza maszynę i dociera do domowego routera, choć każdy pakiet jest tunelowany. Naturalny wniosek to brakująca trasa, a trasa zwykle jest w porządku. Windows może według metryki interfejsu wybrać, którego resolvera zapytać, i adapter tunelu często przegrywa to porównanie z bezprzewodowym.

Dwa wyjaśnienia jednego wycieku

Wyjaśnienie tras mówi, że część ruchu wydostaje się z tunelu, więc trasa domyślna albo lista tunelu dzielonego musi być błędna. Można to sprawdzić jednym poleceniem, a gdy trasa domyślna wskazuje do tunelu, sprawa jest zamknięta. Sprawdź ją najpierw, bo jest tania, a potem odłóż, gdy wróci czysta.

Wyjaśnienie rankingu mówi, że ruch jest w całości w tunelu, a zapytanie i tak trafia do innego resolvera. Windows traktuje wybór resolvera jako właściwość każdego interfejsu z kolejnością, więc fizyczny adapter z lepszą metryką może dostarczyć DNS dla nazwy, mimo że pakiety do rozwiązanego adresu idą przez tunel. Oba wyjaśnienia dają ten sam objaw na stronie testu wycieku, dlatego test nie jest diagnozą. Tylko jedno z nich naprawia się przez edycję tras.

Porównaj metryki i resolvery razem

Zapisz interfejsy, ich metryki i skonfigurowane serwery, dopóki tunel jest aktywny. Czytaj je jako tabelę, a nie jako dwie osobne listy, bo pytanie brzmi, który resolver jest pierwszy, a nie jakie resolvery istnieją.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Jeśli adapter tunelu ma wyższy numer niż adapter fizyczny, jego resolver nie jest preferowany, a nazwa wewnętrzna trafi tam, co oferuje strona fizyczna. Ten router może odpowiedzieć z pamięci podręcznej, przekazać zapytanie dalej albo je odrzucić, i żaden z tych wyników nie jest projektem, który miałeś na myśli. Ranking jest preferencją, więc przegrywa po cichu, zamiast zgłaszać błąd.

Adapter tunelu bez jakiegokolwiek skonfigurowanego resolvera to równie częsty wariant. Klient podnosi interfejs bez wypychania DNS, więc pytanie o ranking w ogóle nie powstaje.

Podnieś tunel w rankingu i sprawdź ponownie

Nadaj interfejsowi tunelu najniższą metrykę albo podnieś wartość adaptera fizycznego w powłoce z podniesionymi uprawnieniami. Oba są ustawieniami dla interfejsu i oba są odwracalne, co ma znaczenie, gdy zmieniasz maszynę, przed którą może nie siedzisz.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Zmiana jest widoczna od razu, a klient DNS i inni konsumenci buforują wybór, którego już dokonali. Połącz tunel ponownie albo uruchom ponownie system, zanim wyciągniesz cokolwiek z wyniku zapytania. Test uruchomiony zbyt wcześnie powtórzy stare zachowanie i będzie wyglądał na nieudaną naprawę.

Potem zapytaj o jedną nazwę wewnętrzną i jedną publiczną i sprawdź, który serwer odpowiedział. dokumentacja o automatycznych metrykach Microsoftu wyjaśnia, dlaczego preferowana jest najniższa wartość i jak wyprowadzane jest automatyczne przypisanie.

Zrób to trwałym wobec ponownego połączenia

Ręczna metryka na adapterze, który jest tworzony od nowa przy każdym połączeniu, to ustawienie, które znika. Jeśli klient odbuduje interfejs, nadpisanie wymaga skryptu po połączeniu, zasady lub konfiguracji klienta, która włada DNS przez czas połączenia.

Statycznie skonfigurowane serwery na adapterze fizycznym mają ten sam problem trwałości odwrotnie. Odpowiadają za ten interfejs, dopóki nie zostaną usunięte, a DHCP uzupełni je z kolejnego najmu, więc ich usunięcie jest pomiarem, a nie projektem. Trwałym projektem jest zasada rozwiązywania nazw dla wewnętrznej przestrzeni nazw albo klient, który przejmuje DNS na czas połączenia. Tak czy inaczej, zapisz listę resolverów przed ponownym połączeniem i po nim, przywróć pierwotną metrykę po zakończeniu testów i potwierdź, że wcześniejsze zachowanie wróciło.