DNS nie rozwiązuje się, gdy kill switch VPN blokuje port 53
Kill switch może celowo blokować DNS. Porównaj rozwiązywanie tylko w tunelu z wyjątkiem dla lokalnego resolvera, a potem ustal, która warstwa naprawdę zawiodła.
Gdy kill switch zrzuca tunel, zabiera ze sobą również ścieżkę DNS, a resolver, który zostaje, rzadko jest tym, którego oczekujesz. Dwa projekty traktują ten moment bardzo różnie: blokować każdy pakiet DNS, który nie znajduje się w tunelu, albo zostawić jeden resolver jako wyjątek. Oba są do obrony. Z karty przeglądarki objawy wyglądają niemal identycznie, więc pierwszym zadaniem jest ustalić, który projekt faktycznie wdrożyłeś.
Trzymam tę różnicę przed oczami, bo poprawka jest w każdym przypadku odwrotna. Jeden projekt potrzebuje szerszego wyjątku, drugi węższego. Zgadywanie kosztuje cię albo prywatność, albo popołudnie.
Dwa projekty DNS dla tej samej awarii
Projekt A traktuje resolver jak kolejną usługę za tunelem. Reguły firewalla zezwalają na UDP i TCP 53 tylko na interfejsie tunelu, a adres przekazywany klientowi to resolver wewnątrz tunelu. Gdy tunel padnie, wyszukiwania się zatrzymują, i to jest zamierzony wynik, a nie usterka.
Projekt B utrzymuje resolver osiągalny w sieci lokalnej, zwykle router pod 192.168.1.1 lub stub systemu operacyjnego pod 127.0.0.53, wychodząc z założenia, że rozwiązywanie nazw nie powinno umierać razem z tunelem. Jest to wygodne w domowej sieci LAN, gdzie router rozwiązuje nazwy dla całego domu. W Wi-Fi hotelu lub lotniska ten sam wyjątek wskazuje na cudzy serwer i każde wpisane nazwisko zostaje ujawnione, nawet jeśli ruch webowy pozostaje zablokowany.
Granica leży w tym, kto jest właścicielem resolvera. Jeśli ufasz lokalnemu, wyjątek jest małą, uczciwą dziurą. Jeśli nie, projekt tylko-tunelowy jest jedynym, który się trzyma, a ceną jest to, że zerwany tunel zabiera wszystkie nazwy.
Dlaczego wyszukiwanie samego klienta VPN nadal działa
Klient musi rozwiązać nazwę hosta bramy, zanim tunel istnieje, więc ścisła blokada nie może obejmować ścieżki startowej klienta. Większość klientów albo buforuje adres punktu końcowego, albo dostarcza udokumentowany wyjątek startowy dla tego jednego hosta. Jeśli twój zestaw reguł blokuje to wyszukiwanie, tunel nigdy nie wróci, a logi pokażą klienta, który nie dociera do własnego serwera; to wada polityki, a nie DNS.
Podzielony DNS to drugie miejsce, w którym to wychodzi. Klient pcha strefę wewnętrzną do prywatnego resolvera, a wszystko inne zostawia resolverowi systemowemu. Po zerwaniu nazwy publiczne mogą się jeszcze rozwiązywać, podczas gdy wewnętrzne kończą się przekroczeniem czasu, bo strefa prywatna nie ma już trasy. Dla użytkownika to „VPN zepsuł internet”; dla logu resolvera to zapytanie, które nigdy nie dotarło.
Pod systemd-resolved podział widać bezpośrednio.resolvectl status wymienia serwery DNS dla każdego łącza i domeny routingu, a po upadku tunelu domena wewnętrzna nadal wskazuje serwer na łączu, którego już nie ma. Stub pod 127.0.0.53 wciąż przyjmuje zapytanie, a potem czeka na serwer nadrzędny, który nie odpowie, i dlatego awaria trwa sekundy zamiast wracać natychmiast.
Szyfrowany DNS nie omija filtra pakietów
DNS over HTTPS i DNS over TLS jadą po 443 i 853, więc reguła blokująca port 53 nic o nich nie powiedziała. Blokowanie „DNS” według portu to polityka dotycząca portu, a nie rozwiązywania nazw. Jeśli twój kill switch blokuje cały ruch poza tunelem, DoH jest objęty przypadkiem. Jeśli wygospodarowałeś wyjątek dla portalu przechwytującego lub publicznego resolvera, nie jest.
Kontrolki po stronie klienta to tańsza dźwignia. Firefox porzuca swój resolver DoH, gdy nazwa kanarka use-application-dns.net nie rozwiązuje się, i dlatego zarządzane sieci publikują tę domenę jako NXDOMAIN; polityka korporacyjna może też przypiąć ją wyłączoną. Android Private DNS i bezpieczny DNS Chrome mają własne przełączniki i własne wartości domyślne. Wyłączenie ich jest pewniejsze niż gonienie za adresami resolverów, bo lista adresów się zmienia, a twój zestaw reguł nie.
Jest wersja tego, która w ogóle nie dotyczy wycieków. Aplikacja z przypiętym resolverem nadal potrzebuje ścieżki sieciowej, żeby do niego dotrzeć. Szyfrowanie zmienia to, kto może przeczytać zapytanie, a nie to, czy pakiet może opuścić maszynę, więc blokada całego urządzenia pokonuje ustawienie, nie dotykając go.
Dopasuj objaw do warstwy
Większość zgłoszeń przychodzi jako jedno zdanie, a to zdanie zwykle już nazywa warstwę. Tabela poniżej to to, co przechodzę, zanim dotknę reguły; chodzi o to, by zdecydować, czy zapytanie zostało zablokowane, skierowane źle, czy nigdy nie wysłane.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Pierwsze dwa wiersze to te, które ludzie diagnozują źle. Ciche zerwanie i odmowa wyglądają w przeglądarce tak samo jak „DNS się zepsuł”, ale tylko jedno z nich oznacza, że twój kill switch robi swoje. Odmowa oznacza, że coś odpowiedziało, więc blokada nie jest tam, gdzie myślisz.
Przywróć politykę resolvera, a potem ją udowodnij
Napraw projekt, nie objaw. Dla rozwiązywania tylko w tunelu zezwól na 53 na interfejsie tunelu, wypchnij wewnętrzny resolver razem z konfiguracją tunelu i zostaw łącze fizyczne bez żadnego zezwolenia DNS. W wg-quick to linia DNS = zapisuje resolver w konfiguracji interfejsu, więc tunel, który ją pomija, zostawia stary resolver na miejscu i każde zapytanie na złej ścieżce.podręcznik wg-quick dokumentuje to zachowanie dla każdej platformy.
Potem sprawdź w tej kolejności. W Linuksie resolvectl status pokazuje aktywne łącze,dig +short example.com testuje nazwę publiczną,dig @10.8.0.1 internal.example.com testuje prywatną, a sudo tcpdump -ni any port 53 pokazuje, którego interfejsu używają pakiety, gdy uruchamiasz oba. W Windows Get-DnsClientServerAddress -AddressFamily IPv4 i Resolve-DnsName example.com dają te same dwa fakty: kto jest skonfigurowany i kto odpowiada.
Zakończ testem negatywnym. Odłącz tunel, potwierdź, że świeża nazwa publiczna zawodzi, potwierdź, że nazwa prywatna zawodzi, i potwierdź, że żaden pakiet portu 53 nie opuścił fizycznego adaptera. Blokada, która trzyma się tylko dla odpowiedzi z pamięci podręcznej, w ogóle się nie trzyma.
Lista kontrolna przed zamknięciem zgłoszenia:
- Resolver używany podczas awarii to ten, który przewiduje polityka.
- Wyszukiwanie własnego punktu końcowego przez klienta jest nadal dozwolone, przez pamięć podręczną lub wyjątek.
- DoH i DoT są albo objęte blokadą, albo wyłączone przez politykę.
- Strefy prywatne zawodzą zamknięte, a nie otwarte, gdy tylko tunel zniknie.