openfortivpn ciągle nadpisuje DNS? Znajdź prawdziwego właściciela

Śledź połączenie od chwili, gdy się podnosi: klient się uwierzytelnia, pppd negocjuje, a potem coś zapisuje ustawienia DNS w systemie operacyjnym. Jeśli wiesz tylko, że VPN zmienił twój resolver, nie wiesz jeszcze, który z tych etapów to zrobił. Dwa z nich mogą, a na kliencie z udokumentowaną integracją pppd działają wystarczająco blisko siebie, by wyglądać jak jeden aktor. Nazwanie pisarza to pierwszy krok; wybór jego zamiennika to drugi, i to osobna decyzja z własnymi trybami awarii.

Poniższa sekwencja podąża za klientem na zewnątrz: co zmieniło połączenie, który przełącznik ucisza którego pisarza, kto powinien przejąć i jak potwierdzić, że wynik przetrwa ponowne połączenie. Każdy etap zostawia inny ślad, a ślad mówi ci, czy przekazanie naprawdę nastąpiło.

Zacznij od tego, co połączenie naprawdę zmieniło

Połącz się raz swoim zwykłym poleceniem i porównaj rozwiązywanie przed i po. Na hoście Linux z systemd-resolved resolvectl status wypisuje serwery DNS i domeny wyszukiwania dla każdego połączenia, a nowe połączenie tun lub ppp z własnymi serwerami jest odciskiem palca aktualizacji po stronie klienta. Na macOS scutil --dns pokazuje konfigurację resolvera w kolejności, w jakiej konsultują ją aplikacje.

Porównaj to z plikiem, którego zmiany oczekiwałeś. Wpis powiązany z połączeniem w widoku na połączenie i przepisany /etc/resolv.conf to dwa różne wyniki, a drugi może być dowiązaniem symbolicznym, którym zarządza zupełnie coś innego. Zapisz adres resolvera, domeny wyszukiwania i nazwę interfejsu w tym samym momencie; zmiana w którymkolwiek z nich wskazuje na innego pisarza. Bez tej linii bazowej każda późniejsza poprawka jest zgadywaniem, który z trzech składników się przesunął.

Dwa przełączniki i pisarz, którego każdy ucisza

openfortivpn dokumentuje fragment opcji, który wyłącza obu pisarzy, którymi może sterować, a każdy przełącznik ma w pełni wypisany odpowiednik, który podręcznik traktuje jako to samo ustawienie.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns powstrzymuje klienta przed zastosowaniem serwerów DNS poznanych od bramy, natomiast --pppd-no-peerdns powstrzymuje pppd przed wepchnięciem DNS peera do systemu. Podręcznik upstream ostrzega, że aktualizacje DNS przez PPP mogą ścigać się z własnymi aktualizacjami DNS klienta, dlatego oba przełączniki należą do fragmentu, zamiast uznawać którykolwiek z nich za wystarczający.

Żaden przełącznik nie wskazuje zastępczego resolvera i żaden nie powstrzymuje menedżera sieci, klienta DHCP ani osobnej integracji VPN przed późniejszym zapisaniem rozwiązywania. Uciszenie dwóch pisarzy zostawia pole otwarte, a nie posiadane. Jeśli trzeci składnik już zarządza DNS, fragment nie zmienia niczego, co możesz zaobserwować; jeśli nic nim nie zarządza, właśnie usunąłeś jedyne źródło rozwiązywania nazw prywatnych. To jest ważny układ tylko wtedy, gdy zastępczy właściciel został wybrany najpierw i przetestowany osobno.

Wybierz właściciela, zanim cokolwiek wyłączysz

Najpierw zdecyduj, kto odpowiada na zapytania o nazwy robocze, bo ten wybór ogranicza wszystko, co następuje. Zachowanie istniejącego resolvera oznacza, że strefa prywatna musi być już osiągalna stamtąd, gdzie siedzi klient, a prywatny resolver w biurze potrzebuje trasy, która przetrwa podniesienie tunelu. Wysyłanie każdego zapytania do jednej wewnętrznej usługi to trzecia polityka z ostrzejszym trybem awarii: gdy ta usługa jest nieosiągalna, nazwy publiczne zawodzą razem z prywatnymi.

Własność tras pozostaje celowo oddzielona. Opcje tras nie są wymagane dlatego, że zmieniłeś DNS, a wyłączenie instalacji tras bez instalowania zamiennika może uczynić właśnie wybrany resolver nieosiągalnym. Sprawdź tabelę routingu konkretnie pod adres resolvera, nie tylko pod podsieć aplikacji, którą przypadkiem testowałeś.

Sprawdzaj rozwiązywanie na połączenie, nie na plik

Pojedynczy /etc/resolv.conf nie jest spisem tego, czego aplikacje naprawdę używają na hoście z rozwiązywaniem ograniczonym lub na domenę, więc czytaj stan resolvera tak, jak ujawnia go platforma.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Zapytaj o jedną nazwę prywatną i jedną publiczną, gdy połączenie jest podniesione, i zanotuj, które połączenie odpowiedziało na każdą. Tam, gdzie połączenie VPN niesie listę wyszukiwania na domenę, nazwa prywatna może się poprawnie rozwiązać, podczas gdy nazwa publiczna wciąż idzie do lokalnego resolvera, i ten podział jest działającym projektem, a nie usterką. Jeśli zapytanie prywatne zawiedzie, zanim ponownie dotkniesz DNS, sprawdź trasę do resolvera; jeśli się powiedzie, a aplikacja nadal zawodzi, aplikacja może czytać własny buforowany lub osobno skonfigurowany resolver.

Połącz się ponownie i potwierdź stan rozłączony

Ściągnij połączenie i powtórz oba zapytania. To, co zainstalował wybrany właściciel, powinien usunąć lub przywrócić ten właściciel, a nie zostawić klient, którego uciszyłeś. Nieaktualny wpis na połączenie, który przeżywa tunel, nadal wysyła prywatne zapytania na adres, który nie jest już osiągalny.

Następnie połącz się ponownie i odczytaj te same trzy wartości: adres resolvera, domeny wyszukiwania, interfejs.

Jeśli pasują do polityki, którą zapisałeś, przekazanie jest zakończone i klient VPN nie jest już jednym z pisarzy. Jeśli wartość cofa się kilka sekund po podniesieniu połączenia, coś innego wciąż stosuje konfigurację, a następnym krokiem jest zidentyfikowanie tego składnika, a nie dodanie kolejnej flagi. Stan końcowy, którego chcesz, jest bez zdarzeń: jeden właściciel, jedna udokumentowana polityka i rozłączony host, który rozwiązuje dokładnie tak, jak przed istnieniem tunelu.