openfortivpn stále přepisuje DNS? Najděte skutečného vlastníka

Sledujte spojení od okamžiku, kdy se zvedne: klient se autentizuje, pppd vyjednává a pak něco zapíše nastavení DNS do operačního systému. Pokud víte jen to, že vám VPN změnila resolver, ještě nevíte, která z těch fází to udělala. Dvě z nich to umí a u klienta s dokumentovanou integrací pppd běží dost blízko u sebe, aby vypadaly jako jeden aktér. Pojmenovat zapisovače je první krok; vybrat jeho náhradu je druhý a je to samostatné rozhodnutí s vlastními režimy selhání.

Postup níže sleduje klienta směrem ven: co spojení změnilo, který přepínač umlčuje kterého zapisovače, kdo má převzít a jak potvrdit, že výsledek přežije opětovné připojení. Každá fáze zanechává jinou stopu a právě stopa vám řekne, zda k předání skutečně došlo.

Začněte tím, co spojení skutečně změnilo

Připojte se jednou svým obvyklým příkazem a porovnejte překlad před a po. Na hostiteli Linux se systemd-resolved vypisuje resolvectl status servery DNS a domény hledání pro každé spojení a nové spojení tun nebo ppp s vlastními servery je otiskem aktualizace na straně klienta. Na macOS ukazuje scutil --dns konfiguraci resolveru v pořadí, v jakém ji aplikace konzultují.

Porovnejte to se souborem, u kterého jste čekali změnu. Záznam vázaný na spojení v zobrazení po spojeních a přepsaný /etc/resolv.conf jsou dva různé výsledky a druhý může být symbolický odkaz, který zcela spravuje něco jiného. Zapište adresu resolveru, domény hledání a název rozhraní ve stejný okamžik; změna v kterémkoli z nich ukazuje na jiného zapisovače. Bez této základní linie je každá pozdější oprava dohadem o tom, která ze tří komponent se pohnula.

Dva přepínače a zapisovač, který každý z nich umlčuje

openfortivpn dokumentuje fragment voleb, který vypíná oba zapisovače, které dokáže ovládat, a každý přepínač má plně vypsaný ekvivalent, který manuál považuje za stejné nastavení.

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 brání klientovi použít servery DNS, které se naučil od brány, zatímco --pppd-no-peerdns brání pppd protlačit DNS protistrany do systému. Manuál upstreamu varuje, že aktualizace DNS přes PPP mohou závodit s vlastními aktualizacemi DNS klienta, a proto oba přepínače patří do fragmentu, místo aby se kterýkoli z nich považoval za dostatečný.

Ani jeden přepínač neuvádí náhradní resolver a ani jeden nebrání správci sítě, klientovi DHCP nebo samostatné integraci VPN, aby potom zapisovaly překlad. Umlčení dvou zapisovačů nechává pole otevřené, nikoli vlastněné. Pokud už DNS spravuje třetí komponenta, fragment nemění nic, co můžete pozorovat; pokud ho nespravuje nic, právě jste odstranili jediný zdroj překladu soukromých jmen. To je platné uspořádání jen tehdy, když byl náhradní vlastník vybrán jako první a otestován samostatně.

Vyberte vlastníka, než cokoli vypnete

Nejprve rozhodněte, kdo odpovídá na dotazy na pracovní jména, protože tato volba omezuje vše následující. Zachování stávajícího resolveru znamená, že soukromá zóna už musí být dostupná odtud, kde klient sedí, a soukromý resolver uvnitř kanceláře potřebuje trasu, která přežije zvednutí tunelu. Posílat každý dotaz jedné interní službě je třetí politika s ostřejším režimem selhání: když je ta služba nedostupná, veřejná jména padají spolu se soukromými.

Vlastnictví tras zůstává záměrně oddělené. Volby tras nejsou nutné proto, že jste změnili DNS, a vypnutí instalace tras bez instalace náhrady může udělat resolver, který jste právě vybrali, nedostupným. Zkontrolujte směrovací tabulku konkrétně na adresu resolveru, ne jen na podsíť aplikace, kterou jste náhodou testovali.

Kontrolujte překlad po spojeních, ne po souborech

Jeden /etc/resolv.conf není soupisem toho, co aplikace na hostiteli s omezeným nebo doménovým překladem skutečně používají, takže čtěte stav resolveru tak, jak ho platforma vystavuje.

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

Zeptejte se na jedno soukromé jméno a jedno veřejné jméno, jakmile je spojení zvednuté, a poznamenejte, které spojení odpovědělo na každé. Tam, kde spojení VPN nese seznam hledání po doménách, může se soukromé jméno přeložit správně, zatímco veřejné jméno stále jde na místní resolver, a toto rozdělení je návrh, který funguje, nikoli závada. Pokud soukromý dotaz selže, prohlédněte trasu k resolveru, než znovu sáhnete na DNS; pokud uspěje, zatímco aplikace stále selhává, může aplikace číst vlastní kešovaný nebo samostatně nastavený resolver.

Připojte se znovu a potvrďte odpojený stav

Sundejte spojení a zopakujte oba dotazy. Co vybraný vlastník nainstaloval, má odstranit nebo obnovit on, ne to nechat po sobě klient, kterého jste umlčeli. Zastaralý záznam po spojení, který tunel přežije, dál posílá soukromé dotazy na adresu, která už není dostupná.

Pak se znovu připojte a přečtěte stejné tři hodnoty: adresa resolveru, domény hledání, rozhraní.

Pokud odpovídají politice, kterou jste zapsali, je předání dokončené a klient VPN už není jedním ze zapisovačů. Pokud se hodnota po zvednutí spojení o pár sekund vrátí zpět, něco jiného stále uplatňuje konfiguraci a dalším krokem je ten komponent identifikovat, ne přidat další přepínač. Koncový stav, který chcete, je bez událostí: jeden vlastník, jedna dokumentovaná politika a odpojený hostitel, který překládá přesně tak, jako to dělal předtím, než tunel existoval.