Dokąd trafia DNS, gdy łączysz Tor z VPN-em

Działają dwa narzędzia prywatności, jedna strona się nie ładuje, a test resolvera mówi, że coś poza przeglądarką otrzymało nazwę. Zanim stanie się to raportem o wycieku, nazwij wymianę, z której to przyszło. Konfiguracja Tor plus VPN zawiera co najmniej trzy różne zapytania o nazwy z trzema różnymi właścicielami, a przejście przez nie w kolejności, w jakiej następują, to najszybszy sposób, by zobaczyć, które zachowuje się źle.

Nazwij każdą wymianę, zanim nazwiesz to wyciekiem

Pierwsza wymiana rozwiązuje sam punkt końcowy VPN i następuje, zanim istnieje jakakolwiek ochrona. Druga rozwiązuje cel dla przeglądarki Tor, która może przekazać nazwę do proxy zamiast rozwiązywać ją lokalnie. Trzecia obejmuje wszystko inne na maszynie, w tym sprawdzanie aktualizacji, klienty poczty i własne zapytania usług systemu operacyjnego. Tylko pierwsza z nich może nastąpić bez udziału pozostałych dwóch.

Każda z nich może podążać inną drogą, a jeden test w przeglądarce obserwuje tylko własne żądanie. Branie jednego wyniku za stan wszystkich trzech to miejsce, w którym zaczyna się większość zamieszania.

Zapisz, które nazwy należą do której warstwy, zanim cokolwiek zmienisz. Prywatne nazwy organizacyjne, publiczny cel i sam punkt końcowy tunelu nie mają tego samego wymogu, a polityka traktująca je jako jedną kategorię coś zepsuje.

Zapytanie startowe następuje przed tunelem

Klient skonfigurowany z nazwą hosta musi rozwiązać tę nazwę, aby otworzyć tunel, a w tym momencie nie istnieje tunel, który mógłby przenieść zapytanie. Odpowiada dowolny resolver oferowany przez system operacyjny w bieżącej sieci, którym może być portal przechwytujący, resolver hotelowy albo publiczny. To nie jest wyciek w tunelu, bo tunelu jeszcze nie ma.

Zmiana ustawienia bezpiecznego DNS w przeglądarce również nie dotyka tego zapytania, ponieważ należy ono do usługi działającej poza przeglądarką i uruchamianej przed otwarciem jakiejkolwiek strony. Jeśli nazwa punktu końcowego nie da się rozwiązać, żadna polityka wewnątrz tunelu nie pomoże, bo błąd następuje o jeden etap wcześniej niż wszystko, co opisuje konfiguracja.

To jedyne miejsce, w którym użycie dosłownego adresu dla punktu końcowego, jeśli dostawca to obsługuje, usuwa zależność zamiast ją dodawać. Usuwa też możliwość podążania za dostawcą, który rotuje adresy, więc zamiana jest realna i powinna zostać rozstrzygnięta, a nie odkryta.

Przeglądarka i reszta maszyny różnią się

Interfejs SOCKS Tora obsługuje przekazywanie nazwy hosta celu do proxy, co oznacza, że zdalna strona wykonuje rozwiązanie, a lokalna maszyna nigdy nie pyta. Ogólna aplikacja obsługująca proxy może najpierw rozwiązać nazwę lokalnie, a potem połączyć się z uzyskanym adresem, co tworzy lokalne zapytanie o cel, który użytkownik uważał za proxowany. Obie aplikacje mogą więc wyciekać w różnych miejscach, dzieląc jedno ustawienie proxy. Nic we współdzielonym adresie proxy nie mówi, które z dwóch zachowań jest używane.

Przeglądarki dodają kolejną warstwę, gdy włączony jest bezpieczny DNS, bo mogą wybrać własnego dostawcę i całkowicie ominąć resolver systemowy. Klient tunelu tymczasem może przepchnąć resolver przez tunel dla całej maszyny. Te dwa ustawienia mogą być jednocześnie poprawne i nadal opisywać różne zachowanie różnych programów.

Sprawdź program, który wysłał żądanie, zamiast ekstrapolować z jednej strony testowej. Różnica między zapytaniem przenoszonym w tunelu a takim, które nigdy nie dotarło do Tora, to dokładnie ta różnica, której jeden adres resolvera nie pokaże.

Sprawdź każdy program, a potem porównaj z zamiarem

Wykonaj obserwacje osobno: czego użyłby system, na co skonfigurowana jest przeglądarka i czy połączenie SOCKS przenosi nazwę czy adres. To ostatnie to różnica między rozwiązywaniem zdalnym a lokalnym, a specyfikacja rozszerzeń SOCKS opisuje, jak nazwa hosta jest przekazywana, zamiast być najpierw rozwiązana.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Następnie porównaj to, co zaobserwowałeś, z tym, co zamierzałeś. Publiczna nazwa rozwiązana przez tunel przez wybrany przez ciebie resolver nie jest tym samym odkryciem co prywatna nazwa przekazana publicznemu resolverowi podczas fallbacku, i zwykle tylko ta druga wymaga działania. Pierwsza to konfiguracja działająca zgodnie z projektem, nawet jeśli w raporcie wygląda niecodziennie.

Zapisz wyjątki, które akceptujesz, w tym zapytanie startowe, którego nie da się ochronić. Zapisany wyjątek to decyzja projektowa, podczas gdy ten sam wyjątek odkryty później wygląda jak defekt. Kto go znajdzie, potraktuje go jak defekt, a ty spędzisz spotkanie na wyjaśnianiu, dlaczego nim nie jest.