Twój tunel dzielony dociera do aplikacji, ale nie do jej serwera DNS

Trasowanie podsieci aplikacji to oczywista część tunelu dzielonego i nie jest to cała praca. Resolver często siedzi pod innym adresem niż aplikacja, której służy, więc działający tunel nadal może zostawić wyszukiwanie poza nim. Profil, który niesie 10.80.0.0/16 i nic więcej, wysyła zapytanie o 10.90.0.53 przez lokalny interfejs, gdzie nie istnieje żadna strefa prywatna. Dodaj ścieżkę do resolvera, a następnie spójrz na drugą połowę problemu: który serwer klient faktycznie wybiera.

Mit: jedna trasa pokrywa całą usługę

Tunel dzielony to lista miejsc docelowych, które idą przez połączenie, a nie opis usługi. Podsieć aplikacji i adres resolvera to dwa miejsca docelowe, a profil może nieść jedno bez drugiego. Gdy tak się stanie, aplikacja jest osiągalna po adresie, a jej nazwa zawodzi, co wygląda na usterkę DNS, a nie na lukę w trasowaniu.

Podsieć wokół resolvera też nie jest pokryta automatycznie. Trasa do hosta na jeden adres wystarcza temu resolverowi i nie otwiera jego sąsiadów. Taki jest sens trasy do hosta: wąska z założenia i łatwa do zapomnienia, gdy następna usługa pojawi się w tej samej podsieci.

Trzy rzeczy muszą zachodzić, aby wyszukiwanie działało: klient trasuje adres resolvera przez tunel, brama przyjmuje i przekazuje to żądanie, a resolver akceptuje otrzymane źródło. Odpowiedź też musi wrócić ustaloną ścieżką. Jeśli brakuje którejkolwiek, objaw jest identyczny, dlatego warto zapisać tabelę adresów, zanim dotknie się konfiguracji.

Ustal, jakie adresy musi nieść profil

Wypisz miejsca docelowe w kolejności: sieć aplikacji, adres resolvera i publiczny punkt końcowy, który kończy sam tunel. Trzeciego nigdy nie wolno trasować do tunelu, ponieważ połączenie zewnętrzne potrzebuje ścieżki, która istnieje przed tunelem.

Uwzględnij zarówno UDP, jak i TCP dla DNS, ponieważ od implementacji oczekuje się obsługi TCP obok UDP, a zablokowana ścieżka TCP daje wolne, częściowe błędy zamiast czystych. Jeśli strefa prywatna jest obsługiwana także przez IPv6, równoważny wyjątek hosta używa adresu i prefiksu IPv6 i jest osobnym wpisem.

Zapisz, co profil już pokrywa, zanim cokolwiek dodasz. Zduplikowana trasa jest nieszkodliwa, ale nieoczekiwana istniejąca trasa mówi, że profil zaprojektowano dla innego planu adresów niż ten, który otrzymałeś.

Dodaj trasę do hosta przez właściciela połączenia

Dla zarządzanego lokalnie natywnego profilu Windows trasa należy do połączenia, a nie do globalnej tabeli trasowania maszyny. Najpierw podejrzyj dodanie, a potem zastosuj je w tym samym zakresie, którego używa profil.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

Pierwsze polecenie pokazuje zmianę w podglądzie bez instalowania czegokolwiek, a drugie wylicza trasy, które profil obecnie niesie. Dokumentacja Add-VpnConnectionRoute firmy Microsoft opisuje zakresy dla pojedynczego użytkownika i dla wszystkich użytkowników; profil dla wszystkich użytkowników potrzebuje własnego parametru zakresu, a polecenie dla pojedynczego użytkownika wobec profilu dla wszystkich użytkowników kończy się niepowodzeniem lub trafia w złe miejsce.

Gdy profil jest zarządzany lub pochodzi od klienta dostawcy, zmiana należy do tego właściciela. Nakładanie trwałej trasy systemowej na politykę połączenia działa do chwili ponownego zastosowania polityki, gdy trasa znika, co zwykle dzieje się podczas rozmowy z pomocą techniczną, a nie podczas testów. Ta usterka jest cicha: trasa znika, nazwa przestaje się rozwiązywać i nikt nie łączy tych dwóch zdarzeń. Umieść zmianę we własnym zapisie właściciela, aby kolejne ponowne zastosowanie ją niosło, a nie usuwało.

Po zastosowaniu połącz profil ponownie, zamiast zakładać, że trasa zaczęła działać. Zmiany tras na aktywnym połączeniu nie zawsze są wychwytywane, a ponowne połączenie odtwarza też stan, który twoi użytkownicy naprawdę będą mieli.

Sprawdź, którego resolvera klient faktycznie użył

Trasa kontroluje pakiety adresowane do resolvera. Nie decyduje, które nazwy należy tam wysłać, a ten wybór jest osobnym mechanizmem. W Windows efektywne reguły przestrzeni nazw mogą wybierać resolver dla każdej domeny, podczas gdy ustawienia DNS profilu dają wartość domyślną. Te dwie warstwy mogą się nie zgadzać bez żadnego błędu, dlatego bezpośrednie zapytanie to tylko połowa dowodu.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

Pierwsze polecenie wypisuje obowiązującą politykę przestrzeni nazw, a drugie pyta prywatny resolver wprost o nazwę aplikacji. Bezpośrednia odpowiedź dowodzi, że ścieżka i resolver działają; nie dowodzi, że wyszukiwanie samej aplikacji wybrało ten serwer. Porównaj ją ze zwykłym wyszukaniem tej samej nazwy i z odpowiedzią, którą otrzymuje aplikacja.

Uwzględnij pamięci podręczne i bezpieczne DNS na poziomie przeglądarki, które może całkowicie ominąć resolver systemu dla nazw wpisanych przez użytkownika. Sufiks wyszukiwania to kolejny fałszywy trop: rozszerza krótką nazwę do w pełni kwalifikowanej i nie ma nic wspólnego z tym, który serwer odpowiada.

Zakończ ponownym połączeniem i powtórzeniem zwykłego wyszukiwania, a potem potwierdź, że zwykłe przeglądanie nadal stosuje się do zatwierdzonej polityki. Zastąpienie prywatnego resolvera publicznym, aby rozwiązać niepowiązaną nazwę, nie jest naprawą i po cichu przenosi prywatne zapytania tam, gdzie nigdy nie powinny trafić.