openfortivpn stalno prepisuje DNS? Nađite pravog vlasnika

Pratite vezu od trenutka kada se podigne: klijent se autentificira, pppd pregovara, a zatim nešto upisuje DNS postavke u operativni sistem. Ako znate samo to da je VPN promijenio vaš razrješivač, još ne znate koja je od tih faza to učinila. Dvije od njih mogu, a na klijentu s dokumentiranom integracijom pppd-a rade dovoljno blizu jedna drugoj da izgledaju kao jedan akter. Imenovanje pisca prvi je korak; odabir njegove zamjene drugi je, i to je odvojena odluka s vlastitim načinima kvara.

Slijed ispod vodi klijenta prema van: šta je veza promijenila, koji prekidač ušutkava kojeg pisca, ko treba da preuzme i kako potvrditi da rezultat preživljava ponovno povezivanje. Svaka faza ostavlja drugačiji trag, a trag je ono što vam kaže da li se primopredaja zaista dogodila.

Počnite od onoga što je veza zaista promijenila

Povežite se jednom svojom uobičajenom komandom i uporedite razrješavanje prije i poslije. Na Linux hostu sa systemd-resolved resolvectl status ispisuje DNS servere i domene pretrage po svakoj vezi, a nova tun ili ppp veza sa vlastitim serverima otisak je ažuriranja na strani klijenta. Na macOS-u scutil --dns prikazuje konfiguraciju razrješivača redoslijedom kojim je aplikacije konsultuju.

Uporedite to s datotekom koju ste očekivali da će se promijeniti. Unos vezan za vezu u prikazu po svakoj vezi i prepisana /etc/resolv.conf dva su različita ishoda, a drugi može biti simbolička veza kojom u potpunosti upravlja nešto drugo. Zabilježite adresu razrješivača, domene pretrage i naziv interfejsa u istom trenutku; promjena u bilo kojem od njih ukazuje na drugog pisca. Bez te osnovne linije svaki kasniji popravak je nagađanje o tome koja se od tri komponente pomjerila.

Dva prekidača i pisac koji svaki od njih ušutkava

openfortivpn dokumentira fragment opcija koji isključuje oba pisca koje može kontrolirati, a svaki prekidač ima do kraja ispisan ekvivalent koji priručnik tretira kao istu postavku.

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 sprječava klijenta da primijeni DNS servere koje je naučio od pristupnika, dok --pppd-no-peerdns sprječava pppd da ugura DNS druge strane u sistem. Priručnik upstream projekta upozorava da se DNS ažuriranja u PPP-u mogu trkati s vlastitim DNS ažuriranjima klijenta, zbog čega oba prekidača pripadaju u fragment, umjesto da se bilo koji od njih smatra dovoljnim.

Nijedan prekidač ne imenuje zamjenski razrješivač, niti jedan ne sprječava mrežnog menadžera, DHCP klijenta ili odvojenu VPN integraciju da nakon toga upisuje razrješavanje. Ušutkavanje dva pisca ostavlja polje otvorenim, a ne posjedovanim. Ako treća komponenta već upravlja DNS-om, fragment ne mijenja ništa što možete primijetiti; ako njime ne upravlja ništa, upravo ste uklonili jedini izvor razrješavanja privatnih imena. To je valjan raspored samo kada je zamjenski vlasnik prvo odabran i zasebno testiran.

Odaberite vlasnika prije nego što bilo šta onemogućite

Prvo odlučite ko odgovara na upite za radna imena, jer taj izbor ograničava sve poslije njega. Zadržavanje postojećeg razrješivača znači da privatna zona već mora biti dostupna odakle god klijent sjedi, a privatni razrješivač unutar ureda treba rutu koja preživljava podizanje tunela. Slanje svakog upita jednoj internoj usluzi treća je politika s oštrijim načinom kvara: kada ta usluga nije dostupna, javna imena padaju zajedno s privatnima.

Vlasništvo nad rutama namjerno ostaje odvojeno. Opcije ruta nisu potrebne zato što ste promijenili DNS, a isključivanje instalacije ruta bez instaliranja zamjene može učiniti razrješivač koji ste upravo odabrali nedostupnim. Provjerite tabelu rutiranja posebno za adresu razrješivača, ne samo za podmrežu aplikacije koju ste slučajno testirali.

Provjeravajte razrješavanje po vezi, ne po datoteci

Jedna /etc/resolv.conf nije popis onoga što aplikacije zaista koriste na hostu s ograničenim ili po domeni razrješavanjem, zato čitajte stanje razrješivača onako kako ga platforma izlaže.

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

Zatražite jedno privatno ime i jedno javno ime nakon što je veza podignuta i zabilježite koja je veza odgovorila na svako. Tamo gdje VPN veza nosi listu pretrage po domeni, privatno ime može se ispravno razriješiti dok javno ime još ide lokalnom razrješivaču, i ta podjela je dizajn koji radi, a ne kvar. Ako privatni upit ne uspije, pregledajte rutu do razrješivača prije nego ponovo dirate DNS; ako uspije dok aplikacija još pada, aplikacija možda čita vlastiti keširani ili zasebno konfigurirani razrješivač.

Ponovo se povežite i potvrdite isključeno stanje

Spustite vezu i ponovite oba upita. Šta god je odabrani vlasnik instalirao, taj vlasnik to treba ukloniti ili vratiti, a ne ostaviti klijent kojeg ste ušutkali. Zastario unos po vezi koji nadživi tunel nastavlja slati privatne upite na adresu koja više nije dostupna.

Zatim se ponovo povežite i pročitajte iste tri vrijednosti: adresa razrješivača, domeni pretrage, interfejs.

Ako se poklapaju s politikom koju ste zapisali, primopredaja je završena i VPN klijent više nije jedan od pisaca. Ako se vrijednost vrati nekoliko sekundi nakon podizanja veze, nešto drugo još primjenjuje konfiguraciju, a sljedeći korak je identificirati tu komponentu umjesto dodati još jedan prekidač. Krajnje stanje koje želite je bez događaja: jedan vlasnik, jedna dokumentirana politika i isključen host koji razrješava točno onako kako je činio prije nego što je tunel postojao.