Plik hosts kontra filtr routera: blokowanie witryny przez VPN

Wpis w pliku hosts i filtr routera blokują tę samą witrynę z zupełnie różnych powodów, dlatego jeden nadal działa pod VPN, a drugi po cichu przestaje. Plik hosts odpowiada na nazwę, zanim jakikolwiek pakiet opuści maszynę. Filtr routera sprawdza ruch, który przez niego przechodzi. Umieść tunel między tymi dwoma punktami, a drugi traci widok, podczas gdy pierwszy niczego nie zauważa.

To, gdzie rozwiązywana jest nazwa, decyduje o wszystkim

Każde blokowanie zaczyna się od pytania: kto zamienia nazwę na adres? Na zwykłym komputerze odpowiada resolver systemowy, który podąża za skonfigurowaną kolejnością i zwykle czyta plik hosts, zanim zapyta DNS. W filtrowanej sieci odpowiedzieć może router, który widzi zapytanie tylko wtedy, gdy klient wyśle je przez niego bez ochrony. Zmień ścieżkę, a zmienisz to, komu wolno odpowiadać.

VPN robi tu dwie rzeczy naraz: przesuwa trasę domyślną i może narzucić własny serwer DNS. Każda z tych zmian wystarczy, by odsunąć rozwiązywanie nazw od urządzenia, które wymuszało blokadę.

To mechanizm stojący za znanym zarzutem, że filtr działa do momentu połączenia VPN.

Wpis hosts odpowiada, zanim tunel istnieje

Wiersz taki jak 127.0.0.1 www.example.com czyta lokalny resolver, więc odpowiedź powstaje na maszynie bez udziału sieci. Podłącz tunel, zmień serwer DNS, zmień sieć: wpis nadal zwraca loopback. Dlatego blokada hosts jest jedyną z dwóch, na którą nie wpływa to, gdzie kończy się VPN.

Jej martwe punkty są równie lokalne. Aplikacja, która niesie własny resolver, mówi DNS over HTTPS lub łączy się z dosłownym adresem, nigdy nie pyta systemu, więc wpis nie jest brany pod uwagę. Adres w pamięci podręcznej działającego procesu ma ten sam skutek, dopóki proces nie zostanie uruchomiony ponownie.

Potwierdź odpowiedź za pomocą getent ahosts w Linuksie lub Resolve-DnsName w Windows, zamiast ufać karcie przeglądarki.

Filtr routera widzi tylko to, co przez niego przechodzi

Filtr treści lub adresów URL na domowym routerze dopasowuje nazwy i żądania, które przechodzą przez niego w czytelnej formie. Gdy klient buduje szyfrowany tunel do serwera gdzie indziej, router widzi jeden strumień do tego serwera i nic w jego wnętrzu. Filtr nie ma nazwy do dopasowania, więc przepuszcza ruch, i wygląda to na awarię filtra, a nie na jego obejście.

Działa druga topologia: router sam trzyma tunel, odszyfrowuje na końcu i tam stosuje filtr. W tym układzie filtr siedzi tam, gdzie pojawia się tekst jawny.

Jeśli tunel kończy się na laptopie, router jest z definicji poza chronioną ścieżką, niezależnie od tego, jak zapisano regułę.

Cztery punkty egzekwowania i co każdy z nich pomija

Cztery miejsca mogą egzekwować blokadę i każde zawodzi inaczej. Czytaj tę listę jako mapę pokrycia, a nie jako ranking.

• Plik hosts lub lokalny resolver: działa offline i pod każdym tunelem, ale jest omijany przez wbudowany resolver lub zaszyty adres.
• Filtrowanie DNS na bramie VPN: obejmuje klientów, którzy używają narzuconego resolvera, i pomija klientów, którzy omijają DNS.
• Reguły wyjścia bramy według adresu lub SNI: niezależne od DNS klienta, ale ślepe na nazwy, których nie potrafią odczytać, i na adresy, których się nie nauczyły.
• Zarządzana polityka przeglądarki lub urządzenia: mocna na zarządzanym sprzęcie, nieobecna na urządzeniach prywatnych.

Żadne z nich nie jest granicą bezpieczeństwa wobec zdeterminowanego użytkownika na niezarządzanym urządzeniu. To mechanizmy kontroli polityki, a uczciwy opis mówi, jaki ruch każde z nich naprawdę obejmuje.

Wybierz warstwę pasującą do intencji: wygoda domowa należy do urządzenia, a reguła organizacyjna do bramy.

Przetestuj oba stany, zanim uznasz to za skończone

Uruchom te same trzy polecenia z podłączonym i odłączonym VPN: getent ahosts, aby zobaczyć odpowiedź resolvera, nslookup, aby zobaczyć, co zwraca zapytanie, oraz curl -I wobec witryny, aby zobaczyć, czy połączenie nadal się kończy. Jeśli pierwsze zwraca loopback, a trzecie łączy się z prawdziwym adresem, coś ominęło resolver i wpis hosts nie jest kontrolą, którą myślisz.

Na routerze odczytaj liczniki filtra przed żądaniem i po nim. Licznik, który nigdy się nie porusza, oznacza, że ruch nigdy nie dotarł do filtra, a to odpowiedź routingu, nie reguły.

Zapisz wynik razem z topologią, ponieważ następna zmiana VPN znowu przesunie ścieżkę.