Dlaczego hotspot przekierowuje DNS, zanim połączy się VPN?
Hotspot przepisuje zapytania we własnej sieci, a punkt końcowy zapisany jako nazwa hosta jest rozwiązywany, zanim powstanie jakikolwiek tunel. Prześledź, który resolver odpowiedział na każde zapytanie.
Dołączenie do sieci hotelowej stawia przed tobą dwie decyzje DNS w różnych momentach: zapytania, które urządzenie wykonuje podczas logowania, oraz zapytania wykonywane po podniesieniu tunelu. Hotspot może wpływać na pierwsze przez sieć, którą kontroluje. Drugie zależą od polityki samego klienta, co jest osobną rzeczą do zbadania.
Przejdź przez połączenie po kolei, od pierwszego dzierżawienia DHCP do zapytania, które rozwiązało prywatną nazwę. Wtedy dwa błędy, które w zgłoszeniu do pomocy technicznej wyglądają identycznie, rozdzielają się czysto: jeden zdarzył się przed powstaniem tunelu, drugi w jego wnętrzu.
Czego hotspot może, a czego nie może dotknąć
Sieć dostępowa przydziela adres resolvera przez DHCP i może przechwycić port 53 w kierunku tego adresu. To wystarcza, aby odpowiedzieć na każde niezabezpieczone zapytanie adresem portalu lub stroną blokady. Wystarcza też, aby złamać klienta VPN, którego punkt końcowy jest zapisany jako nazwa hosta.
Czego hotspot nie może, to czytać ani przepisywać zapytania, gdy podróżuje już wewnątrz ustanowionego tunelu, zakładając, że tunel naprawdę je przenosi. Przechwycenie zależy od zobaczenia pytania w postaci jawnej.
Zapytania i tak opuszczają tunel z powodów niezwiązanych z hotspotem: ustawienie bezpiecznego DNS w przeglądarce, reguła split-DNS utrzymująca firmowy sufiks na lokalnym resolverze albo klient skonfigurowany tak, by wyłączyć DNS z tunelu. Każdy z nich jest wyborem po stronie klienta i każdy z zewnątrz wygląda jak ingerencja hotspota.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Pierwsze zapytanie następuje, zanim powstanie tunel
Klient, który otrzymuje nazwę hosta, musi najpierw ją rozwiązać, a w tej chwili żaden tunel nie chroni zapytania. Jeśli hotspot odpowie adresem portalu, negocjacja się nie udaje albo zawiesza. Jeśli nie odpowie niczym, klient zgłasza błąd nazwy i tunel nigdy nie startuje. Każdy z tych dwóch wyników wyjaśnia pusty dziennik tunelu, który inaczej wygląda niewinnie.
Systemy operacyjne wykonują też własne kontrole łączności i wykrywanie portalu, opisane w RFC 8910 i RFC 8952, a te żądania wychodzą, zanim podniesie się jakikolwiek VPN. Widzenie ich w dzienniku proxy to oczekiwane zachowanie, a nie dowód wycieku.
Praktycznym rozwiązaniem jest danie klientowi punktu końcowego, który nie wymaga zapytania. Gdy to niemożliwe, dokończ najpierw logowanie, a potem się połącz.
Ustal, który resolver odpowiedział
Pytaj system, a nie przeglądarkę, i uruchom zapytanie dwa razy: raz przez dowolny resolver, którego urządzenie teraz używa, raz wobec stałego adresu.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Odpowiedź pierwszego polecenia różna od trzeciej mówi ci, że lokalny resolver zwraca coś innego, i właśnie to robi przekierowujący hotspot. Błąd trzeciego wraz z sukcesem pierwszego wskazuje portal: lokalny resolver podał adres logowania, podczas gdy wychodzący port 53 został odrzucony. Przekroczenie czasu w obu oznacza, że sieć odrzuca DNS, dopóki uwierzytelnianie się nie zakończy.
Powtórz po połączeniu i porównaj. Odpowiedź z pamięci podręcznej przetrwa przejście, więc wyczyść pamięć podręczną albo zapytaj o nową nazwę do drugiej obserwacji.
Utrzymaj późniejsze zapytania na zamierzonej ścieżce
Profil pełnego tunelu, który przechwytuje też DNS, jest najprostszym układem: każde zapytanie każdej aplikacji idzie do resolvera narzucanego przez tunel, a sieć lokalna widzi tylko ruch szyfrowany. Udowodnij to, rozwiązując po połączeniu nazwę wewnętrzną i publiczną, a następnie porównując obie odpowiedzi z tym, co resolver tunelu zwraca sam.
Split-DNS wymaga listy domen napisanej z rozmysłem: sufiksy firmowe przez tunel, wszystko inne lokalnie i bez nakładania się na siebie.
Bezpieczny DNS przeglądarki stoi poza tą polityką, więc jeśli musi być wyłączony, aby profil zachowywał się przewidywalnie, wyłącz go dla tego profilu, a nie dla maszyny. Zrób to w ustawieniach przeglądarki, nie edytując resolvera systemowego, aby zmiana była widoczna następnym razem. Zapisuj odpowiedź, resolver i etap połączenia w jednym wierszu na test. Raport, że DNS zawiódł w hotelowym Wi-Fi, opisuje objaw z co najmniej trzema różnymi przyczynami.