Dlaczego własny DNS routera omija tunel VPN?

Zapytania klientów podążają tunelem, natomiast własne zapytania routera wychodzą przez WAN, a reguła zapory, która rządzi jednym, nie ma żadnego wpływu na drugie. Przyczyna nie jest błędem: przekazane żądanie i żądanie wygenerowane przez sam router to dwa odrębne przepływy, a każde jest dopasowywane do innej części konfiguracji. Przechwycenie tylko połowy klienta daje pewną odpowiedź o ścieżce, której druga połowa nigdy nie używa. Naprawa polega na świadomym skierowaniu resolvera routera, a następnie przetestowaniu obu ścieżek osobno.

Do którego przepływu naprawdę należy przechwycenie pakietów

Jedno zapytanie obejmuje dwie wymiany. Klient LAN wysyła zapytanie do resolvera routera, a ono trafia jako ruch przekazany na interfejs LAN, więc reguła polityki routingu lub NAT napisana dla przekazanych pakietów może je dopasować. Następnie router odpowiada z pamięci podręcznej lub, gdy nie ma wpisu, otwiera własne zapytanie do serwera wyżej.

To drugie zapytanie ma router jako źródło i jako własny cel, a platforma wybiera jego ścieżkę z innego bloku konfiguracji. Obie wymiany noszą tę samą nazwę i żadna nie jest kopią drugiej. Dlatego przechwycenie zrobione po stronie LAN dowodzi, dokąd poszedł pakiet klienta, i nie mówi nic o pakiecie wychodzącym.

Praktyczne sprawdzenie polega na obserwowaniu obu stron jednocześnie. Na routerze wypisz gniazdo resolvera, zapytaj je lokalnie i przechwyć interfejs WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Jeśli lista gniazd pokazuje nasłuchujący powiązany z adresem loopback lub LAN, router odpowiada lokalnie, zamiast przekazywać do innego hosta. Przechwycenie pokazuje wtedy, czy wynikowe zapytanie w górę wychodzi przez interfejs tunelu, czy przez WAN, i to jest odpowiedź, której reguła polityki routingu nigdy by nie dała.

Dlaczego polityka routingu nigdy nie widzi drugiego zapytania

Reguły zapory pisze się dla interfejsu, źródła, celu i portu, a ocenia się je dla pakietów przechodzących przez urządzenie. Zapytanie, które tworzy router, nie przechodzi przez nic, bo lokalny proces przekazuje je wprost do tablicy routingu. Polityka routingu i NAT dotyczą więc tylko ścieżki przekazanej, i właśnie dlatego zestaw reguł może wyglądać na kompletny, a mimo to pozostawić DNS routera poza tunelem.

To rozróżnienie przetrwa każdą zmianę firmware'u, bo wynika ze ścieżki pakietu, a nie z funkcji. Wszystko, co urządzenie tworzy dla siebie, czy to zapytania resolvera, synchronizacja czasu, sprawdzanie aktualizacji, czy dostęp do luster pakietów, ma pochodzenie lokalne i trafia w ten sam martwy punkt. Dlatego też test z laptopa niczego nie dowodzi o routerze.

Gdzie resolver pfSense decyduje o własnej ścieżce w górę

pfSense uwidacznia ten podział. Ruch klientów można kierować polityką przez bramę VPN, podczas gdy własny ruch zapory podlega ustawieniu wyjściowemu resolvera, a nie regułom LAN. W interfejsie web tym ustawieniem jest Services > DNS Resolver > Outgoing Network Interfaces, a jego wartością jest lista interfejsów, których resolver może używać do zapytań w górę.

Wskazanie tam interfejsu tunelu, i tylko tego interfejsu, sprawia, że własne zapytania routera podążają tunelem. Pozostawione domyślnie, ustawienie wybiera wyjście z tablicy routingu, które na hoście z dwoma WAN lub VPN często jest WAN.

Inne firmware'y pokazują tę samą decyzję pod inną nazwą: lista serwerów wyżej powiązana z adresem źródłowym, tryb tylko przekazywania albo udokumentowana polityka tras. Ustawienie, którego trzeba szukać, to zawsze to, które wybiera wyjście lub źródło dla zapytań tworzonych lokalnie. Dokumentacja konfiguracji resolvera opisuje tę opcję dla pfSense i warto ją przeczytać przed zmianą.

Wybierz zachowanie przy awarii przed ustawieniem

Gdy tunel padnie, dwa zachowania są do obrony: zatrzymać zapytania w górę, żeby nic nie wyciekło, albo wrócić do zatwierdzonego resolvera na znanej ścieżce. Oba są polityką i żadne nie jest tym, co dostaje się domyślnie. Zdecyduj, którego potrzebuje sieć, zanim dotkniesz listy interfejsów.

Zamknięcie przy awarii łatwiej obronić, ale zamienia przerwę w tunelu w przerwę rozwiązywania nazw dla każdego urządzenia za routerem. Powrót utrzymuje biuro w użyciu, kosztem wymiany w górę poza tunelem, która musi być akceptowalna świadomie, a nie przypadkiem. Zapisz wybór, bo następna osoba, która zobaczy adres resolvera poza VPN, odczyta to jako wyciek, chyba że notatka mówi inaczej. Ta notatka oddziela udokumentowany powrót od niewyjaśnionego znaleziska w przeglądzie następnego kwartału.

Dwa przypadki komplikują decyzję. Nazwy prywatne mogą wymagać wewnętrznego resolvera, do którego tunel dociera, a przeglądarka lub aplikacja z własnym szyfrowanym DNS może całkowicie ominąć router, więc skonfigurowany resolver nie zawsze jest tym, którego używa dana aplikacja.

Przetestuj obie ścieżki i trzymaj wyniki osobno

Test DNS w przeglądarce odpowiada na wąskie pytanie: których resolverów użyła ta przeglądarka w warunkach tego testu. Nie inwentaryzuje urządzeń w sieci i nie widzi zapytania, które router utworzył dla siebie. Traktuj jego wynik jako jeden punkt danych, a nie audyt.

Z klienta LAN poproś router o nazwę publiczną, a potem o prywatną, na którą powinna odpowiadać tylko twoja strefa wewnętrzna. Niepowodzenie tylko przy drugim zapytaniu wskazuje na przekazywanie nazw, a nie na tunel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Następnie opuść tunel i powtórz oba zapytania. Odrzucone odpowiedzi oznaczają, że resolver zamyka się przy awarii; udana odpowiedź wskazuje resolver zapasowy i ścieżkę, której użył. Porównaj to z notatką, którą napisałeś, oraz z przechwyceniem na interfejsie WAN zrobionym w tej samej minucie.

Trzymaj obserwacje osobno w zapisie: wymianę klienta z routerem, wymianę routera z serwerem wyżej oraz konfigurację, która zdecydowała o drugiej. Późniejsza zmiana routingu użyje tej drugiej wymiany bez ostrzeżenia. Odpowiedź, która przychodzi z innego miejsca niż punkt końcowy VPN, sama w sobie nie jest wyciekiem; staje się wyciekiem dopiero wtedy, gdy konfiguracja wybrała tę ścieżkę przypadkiem.