openfortivpn kirjutab DNS-i üha üle? Leidke tõeline omanik

Jälgige ühendust hetkest, mil see püsti tõuseb: klient autendib end, pppd peab läbirääkimisi ja siis kirjutab miski DNS-i seaded operatsioonisüsteemi. Kui teate ainult seda, et VPN muutis teie resolverit, ei tea te veel, milline neist etappidest seda tegi. Kaks neist saavad seda teha, ja dokumenteeritud pppd-integratsiooni kasutaval kliendil töötavad nad üksteisele piisavalt lähedal, et näida ühe osalisena. Kirjutaja nimetamine on esimene samm; tema asendaja valimine on teine, ja see on eraldi otsus omaenda tõrkerežiimidega.

Allolev jada järgib klienti väljapoole: mida ühendus muutis, milline lüliti vaigistab millist kirjutajat, kes peaks üle võtma ja kuidas kinnitada, et tulemus peab vastu taasühendamisele. Iga etapp jätab erineva jälje, ja jälg on see, mis ütleb teile, kas üleandmine tegelikult toimus.

Alustage sellest, mida ühendus tegelikult muutis

Ühenduge üks kord oma tavapärase käsuga ja võrrelge nimehüüet enne ja pärast. Linuxi hostis, kus töötab systemd-resolved, trükib resolvectl status DNS-serverid ja otsingudomeenid iga lingi kohta, ja uus tun- või ppp-link oma serveritega on kliendipoolse uuenduse sõrmejälg. macOS-is näitab scutil --dns resolveri konfiguratsiooni selles järjekorras, milles rakendused seda konsulteerivad.

Võrrelge seda failiga, mille muutumist te eeldasite. Ühendusega seotud kirje lingipõhises vaates ja ümber kirjutatud /etc/resolv.conf on kaks erinevat tulemust, ja teine võib olla sümbollink, mida haldab täiesti miski muu. Kirjutage resolveri aadress, otsingudomeenid ja liidese nimi üles samal hetkel; muutus ükskõik millises neist osutab teisele kirjutajale. Ilma selle baasjooneta on iga hilisem parandus oletus, milline kolmest komponendist liikus.

Kaks lülitit ja kirjutaja, mille kumbki vaigistab

openfortivpn dokumenteerib valikufragmendi, mis lülitab välja mõlemad kirjutajad, mida see kontrollida suudab, ja igal lülitil on täielikult välja kirjutatud vaste, mida käsiraamat kohtleb sama seadena.

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 takistab kliendil rakendamast DNS-servereid, mille see lüüsilt õppis, samal ajal kui --pppd-no-peerdns takistab pppd-l partneri DNS-i süsteemi surumast. Upstreami käsiraamat hoiatab, et PPP kaudu tehtavad DNS-uuendused võivad võistelda kliendi enda DNS-uuendustega, mistõttu kuuluvad mõlemad lülitid fragmenti, selle asemel et kumbagi neist pidada piisavaks.

Kumbki lüliti ei nimeta asendusresolverit, ja kumbki ei takista võrguhaldurit, DHCP-klienti ega eraldi VPN-integratsiooni hiljem nimehüüet kirjutamast. Kahe kirjutaja vaigistamine jätab välja lahtiseks, mitte omatuks. Kui kolmas komponent juba haldab DNS-i, ei muuda fragment midagi, mida te saate jälgida; kui miski ei halda seda, eemaldasite just ainsa privaatse nimehüüde allika. See on kehtiv korraldus ainult siis, kui asendusomanik valiti esimesena ja testiti eraldi.

Valige omanik enne, kui midagi välja lülitate

Otsustage esimesena, kes vastab töönimede päringutele, sest see valik piirab kõike järgnevat. Olemasoleva resolveri hoidmine tähendab, et privaatne tsoon peab juba olema kättesaadav sealt, kus klient asub, ja kontori sees olev privaatne resolver vajab marsruuti, mis peab vastu tunnelil püsti tõusmisele. Iga päringu saatmine ühte sisevteenusesse on kolmas poliitika teravama tõrkerežiimiga: kui see teenus pole kättesaadav, ebaõnnestuvad avalikud nimed koos privaatsetega.

Marsruudi omandus jääb meelega eraldi. Marsruudivalikud ei ole nõutud sellepärast, et te muutsite DNS-i, ja marsruudi paigaldamise väljalülitamine ilma asendajat paigaldamata võib muuta just valitud resolveri kättesaamatuks. Kontrollige marsruutimistabelit konkreetselt resolveri aadressi jaoks, mitte ainult selle rakenduse alamvõrgu jaoks, mida te juhuslikult testisite.

Kontrollige nimehüüet iga lingi, mitte faili kohta

Üksik /etc/resolv.conf ei ole loend sellest, mida rakendused piiratud või domeenipõhise nimehüüdega hostis tegelikult kasutavad, seega lugege resolveri olekut nii, nagu platvorm seda paljastab.

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

Küsige ühte privaatset nime ja ühte avalikku nime, kui ühendus on püsti, ja märkige, milline link kummale vastas. Kui VPN-link kannab domeenipõhist otsinguloendit, võib privaatne nimi laheneda õigesti, samal ajal kui avalik nimi läheb ikka kohalikku resolverisse, ja see jaotus on töötav disain, mitte viga. Kui privaatne päring ebaõnnestub, uurige marsruuti resolverini enne, kui DNS-i uuesti puudutate; kui see õnnestub, samal ajal kui rakendus ikka ebaõnnestub, loeb rakendus võib-olla omaenda vahemällu salvestatud või eraldi seadistatud resolverit.

Ühenduge uuesti ja kinnitage lahtiühendatud olek

Võtke ühendus maha ja korrake mõlemat päringut. Mida iganes valitud omanik paigaldas, peaks see omanik eemaldama või taastama, mitte jätma maha klient, mille te vaigistasite. Tunneli üle elav aegunud lingipõhine kirje saadab jätkuvalt privaatseid päringuid aadressile, mis pole enam kättesaadav.

Seejärel ühenduge uuesti ja lugege uuesti samu kolme väärtust: resolveri aadress, otsingudomeenid, liides.

Kui need vastavad poliitikale, mille te üles kirjutasite, on üleandmine lõpetatud ja VPN-klient ei ole enam üks kirjutajatest. Kui väärtus triivib paar sekundit pärast lingi üles tulekut tagasi, rakendab miski muu ikka konfiguratsiooni, ja järgmine samm on see komponent tuvastada, mitte lisada veel üks lipp. Lõppolek, mida te soovite, on sündmusteta: üks omanik, üks dokumenteeritud poliitika ja lahtiühendatud host, mis lahendab täpselt nii, nagu enne tunneli olemasolu.