openfortivpn kar naprej prepisuje DNS? Poiščite pravega lastnika

Sledite povezavi od trenutka, ko se dvigne: odjemalec se overi, pppd se pogaja, nato pa nekaj zapiše nastavitve DNS v operacijski sistem. Če veste le, da je VPN spremenil vaš razreševalnik, še ne veste, katera od teh stopenj je to storila. Dve od njih lahko, in pri odjemalcu z dokumentirano integracijo pppd tečeta dovolj blizu skupaj, da izgledata kot en sam akter. Poimenovati pisalca je prvi korak; izbrati njegovo zamenjavo je drugi, in to je ločena odločitev z lastnimi načini odpovedi.

Spodnje zaporedje sledi odjemalcu navzven: kaj je povezava spremenila, katero stikalo utiša katerega pisalca, kdo naj prevzame in kako potrditi, da rezultat preživi ponovno povezavo. Vsaka stopnja pusti drugačno sled, in sled je tista, ki vam pove, ali se je predaja res zgodila.

Začnite s tem, kaj je povezava v resnici spremenila

Povežite se enkrat s svojim običajnim ukazom in primerjajte razreševanje pred in po. Na gostitelju Linux s systemd-resolved resolvectl status izpiše strežnike DNS in iskalne domene za vsako povezavo, nova povezava tun ali ppp z lastnimi strežniki pa je prstni odtis posodobitve na strani odjemalca. Na macOS scutil --dns prikaže konfiguracijo razreševalnika v vrstnem redu, v katerem ga aplikacije posvetujejo.

Primerjajte to z datoteko, pri kateri ste pričakovali spremembo. Vnos, vezan na povezavo, v pogledu po povezavah in prepisan /etc/resolv.conf sta dva različna izida, in drugi je lahko simbolna povezava, ki jo v celoti upravlja nekaj drugega. Zapišite naslov razreševalnika, iskalne domene in ime vmesnika v istem trenutku; sprememba v katerem koli od njih kaže na drugega pisalca. Brez te osnovne črte je vsak poznejši popravek ugibanje o tem, katera od treh komponent se je premaknila.

Dva stikala in pisalec, ki ga vsako utiša

openfortivpn dokumentira fragment možnosti, ki izklopi oba pisalca, ki ju lahko nadzoruje, in vsako stikalo ima do konca izpisan ekvivalent, ki ga priročnik obravnava kot isto nastavitev.

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 odjemalcu prepreči, da bi uporabil strežnike DNS, ki se jih je naučil od prehoda, medtem ko --pppd-no-peerdns pppd prepreči, da bi potisnil DNS partnerja v sistem. Priročnik upstream opozarja, da lahko posodobitve DNS prek PPP tekmujejo z lastnimi posodobitvami DNS odjemalca, zato obe stikali sodita v fragment, namesto da bi katero koli od njiju veljalo za zadostno.

Nobeno stikalo ne navede nadomestnega razreševalnika in nobeno ne prepreči upravitelju omrežja, odjemalcu DHCP ali ločeni integraciji VPN, da bi pozneje zapisali razreševanje. Utišanje dveh pisalcev pusti polje odprto, ne pa lastniško. Če DNS že upravlja tretja komponenta, fragment ne spremeni ničesar, kar lahko opazite; če ga ne upravlja nič, ste pravkar odstranili edini vir razreševanja zasebnih imen. To je veljavna ureditev le, ko je bil nadomestni lastnik izbran najprej in preizkušen samostojno.

Izberite lastnika, preden karkoli onemogočite

Najprej odločite, kdo odgovarja na poizvedbe za delovna imena, ker ta izbira omejuje vse, kar sledi. Ohranitev obstoječega razreševalnika pomeni, da mora biti zasebna cona že dosegljiva od tam, kjer sedi odjemalec, zasebni razreševalnik v pisarni pa potrebuje pot, ki preživi dvig tunela. Pošiljanje vsake poizvedbe eni notranji storitvi je tretja politika z ostrejšim načinom odpovedi: ko ta storitev ni dosegljiva, javna imena odpovejo skupaj z zasebnimi.

Lastništvo poti ostaja namerno ločeno. Možnosti poti niso potrebne zato, ker ste spremenili DNS, in izklop namestitve poti brez namestitve zamenjave lahko naredi pravkar izbrani razreševalnik nedosegljiv. Preverite usmerjevalno tabelo posebej za naslov razreševalnika, ne le za podomrežje aplikacije, ki ste jo slučajno preizkusili.

Preverjajte razreševanje po povezavah, ne po datotekah

En /etc/resolv.conf ni seznam tega, kar aplikacije v resnici uporabljajo na gostitelju z omejenim ali domenskim razreševanjem, zato berite stanje razreševalnika tako, kot ga razkrije platforma.

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

Vprašajte za eno zasebno ime in eno javno ime, ko je povezava dvignjena, in zabeležite, katera povezava je odgovorila na vsako. Kjer povezava VPN nosi iskalni seznam po domenah, se lahko zasebno ime pravilno razreši, medtem ko javno ime še vedno gre k lokalnemu razreševalniku, in ta delitev je delujoča zasnova, ne okvara. Če zasebna poizvedba ne uspe, preglejte pot do razreševalnika, preden se znova dotaknete DNS; če uspe, medtem ko aplikacija še vedno odpove, aplikacija morda bere svoj predpomnjeni ali ločeno nastavljeni razreševalnik.

Znova se povežite in potrdite odklopljeno stanje

Spustite povezavo in ponovite obe poizvedbi. Kar je izbrani lastnik namestil, mora ta lastnik odstraniti ali obnoviti, ne pa pustiti odjemalec, ki ste ga utišali. Zastarel vnos po povezavah, ki preživi tunel, še naprej pošilja zasebne poizvedbe na naslov, ki ni več dosegljiv.

Nato se znova povežite in preberite iste tri vrednosti: naslov razreševalnika, iskalne domene, vmesnik.

Če se ujemajo s politiko, ki ste jo zapisali, je predaja končana in odjemalec VPN ni več eden od pisalcev. Če se vrednost nekaj sekund po dvigu povezave vrne nazaj, nekaj drugega še vedno uporablja konfiguracijo, in naslednji korak je prepoznati to komponento, ne dodati še ene zastavice. Končno stanje, ki ga želite, je brez dogodkov: en lastnik, ena dokumentirana politika in odklopljen gostitelj, ki razrešuje natanko tako, kot je pred obstojem tunela.