openfortivpn stále prepisuje DNS? Nájdite skutočného vlastníka

Sledujte spojenie od okamihu, keď sa zdvihne: klient sa autentifikuje, pppd vyjednáva a potom niečo zapíše nastavenia DNS do operačného systému. Ak viete len to, že vám VPN zmenila resolver, ešte neviete, ktorá z tých fáz to urobila. Dve z nich to dokážu a u klienta s dokumentovanou integráciou pppd bežia dosť blízko seba, aby vyzerali ako jeden aktér. Pomenovať zapisovača je prvý krok; vybrať jeho náhradu je druhý, a to je samostatné rozhodnutie s vlastnými režimami zlyhania.

Postup nižšie sleduje klienta smerom von: čo spojenie zmenilo, ktorý prepínač umlčí ktorého zapisovača, kto má prevziať a ako potvrdiť, že výsledok prežije opätovné pripojenie. Každá fáza zanecháva inú stopu a práve stopa vám povie, či sa odovzdanie naozaj udialo.

Začnite tým, čo spojenie skutočne zmenilo

Pripojte sa raz svojím obvyklým príkazom a porovnajte preklad pred a po. Na hostiteľovi Linux so systemd-resolved vypisuje resolvectl status servery DNS a domény hľadania pre každé spojenie a nové spojenie tun alebo ppp s vlastnými servermi je odtlačkom aktualizácie zo strany klienta. Na macOS zobrazuje scutil --dns konfiguráciu resolvera v poradí, v akom ju aplikácie konzultujú.

Porovnajte to so súborom, u ktorého ste očakávali zmenu. Záznam viazaný na spojenie v zobrazení po spojeniach a prepísaný /etc/resolv.conf sú dva rôzne výsledky a druhý môže byť symbolický odkaz, ktorý úplne spravuje niečo iné. Zapíšte adresu resolvera, domény hľadania a názov rozhrania v tom istom okamihu; zmena v ktoromkoľvek z nich ukazuje na iného zapisovača. Bez tejto základnej línie je každá neskoršia oprava dohadom o tom, ktorá z troch komponentov sa pohla.

Dva prepínače a zapisovač, ktorý každý z nich umlčí

openfortivpn dokumentuje fragment volieb, ktorý vypína oboch zapisovačov, ktorých dokáže ovládať, a každý prepínač má plne vypísaný ekvivalent, ktorý manuál považuje za to isté nastavenie.

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áni klientovi použiť servery DNS, ktoré sa naučil od brány, zatiaľ čo --pppd-no-peerdns bráni pppd pretlačiť DNS protistrany do systému. Manuál upstreamu varuje, že aktualizácie DNS cez PPP môžu pretekať s vlastnými aktualizáciami DNS klienta, a preto oba prepínače patria do fragmentu, namiesto toho, aby sa ktorýkoľvek z nich považoval za dostatočný.

Ani jeden prepínač neuvádza náhradný resolver a ani jeden nebráni správcovi siete, klientovi DHCP alebo samostatnej integrácii VPN, aby potom zapisovali preklad. Umlčanie dvoch zapisovačov necháva pole otvorené, nie vlastnené. Ak už DNS spravuje tretia komponenta, fragment nemení nič, čo môžete pozorovať; ak ho nespravuje nič, práve ste odstránili jediný zdroj prekladu súkromných mien. To je platné usporiadanie len vtedy, keď bol náhradný vlastník vybraný ako prvý a otestovaný samostatne.

Vyberte vlastníka, skôr než čokoľvek vypnete

Najprv rozhodnite, kto odpovedá na dopyty na pracovné mená, pretože táto voľba obmedzuje všetko nasledujúce. Zachovanie existujúceho resolvera znamená, že súkromná zóna už musí byť dostupná odtiaľ, kde klient sedí, a súkromný resolver v kancelárii potrebuje trasu, ktorá prežije zdvihnutie tunela. Posielanie každého dopytu jednému internému servisu je tretia politika s ostrejším režimom zlyhania: keď je ten servis nedostupný, verejné mená zlyhávajú spolu so súkromnými.

Vlastníctvo trás zostáva zámerne oddelené. Voľby trás nie sú potrebné preto, že ste zmenili DNS, a vypnutie inštalácie trás bez inštalácie náhrady môže urobiť práve vybraný resolver nedostupným. Skontrolujte smerovaciu tabuľku konkrétne pre adresu resolvera, nie len pre podsieť aplikácie, ktorú ste náhodou testovali.

Kontrolujte preklad po spojeniach, nie po súboroch

Jeden /etc/resolv.conf nie je zoznamom toho, čo aplikácie na hostiteľovi s obmedzeným alebo doménovým prekladom skutočne používajú, preto čítajte stav resolvera tak, ako ho platforma odhaľuje.

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

Spýtajte sa na jedno súkromné meno a jedno verejné meno, keď je spojenie zdvihnuté, a poznamenajte, ktoré spojenie odpovedalo na každé. Tam, kde spojenie VPN nesie zoznam hľadania po doménach, môže sa súkromné meno preložiť správne, zatiaľ čo verejné meno stále ide na miestny resolver, a toto rozdelenie je návrh, ktorý funguje, nie porucha. Ak súkromný dopyt zlyhá, preskúmajte trasu k resolveru, skôr než znova siahnete na DNS; ak uspeje, zatiaľ čo aplikácia stále zlyháva, aplikácia možno číta vlastný kešovaný alebo samostatne nastavený resolver.

Pripojte sa znova a potvrďte odpojený stav

Zložte spojenie a zopakujte oba dopyty. Čo vybraný vlastník nainštaloval, má odstrániť alebo obnoviť on, nie to nechať po sebe klient, ktorého ste umlčali. Zastaraný záznam po spojeniach, ktorý prežije tunel, ďalej posiela súkromné dopyty na adresu, ktorá už nie je dostupná.

Potom sa znova pripojte a prečítajte tie isté tri hodnoty: adresa resolvera, domény hľadania, rozhranie.

Ak zodpovedajú politike, ktorú ste zapísali, je odovzdanie dokončené a klient VPN už nie je jedným zo zapisovačov. Ak sa hodnota po zdvihnutí spojenia o pár sekúnd vráti späť, niečo iné stále uplatňuje konfiguráciu a ďalším krokom je ten komponent identifikovať, nie pridať ďalší prepínač. Koncový stav, ktorý chcete, je bez udalostí: jeden vlastník, jedna dokumentovaná politika a odpojený hostiteľ, ktorý prekladá presne tak, ako predtým, než tunel existoval.