openfortivpn kirjoittaa DNS:ää yhä uudelleen? Löydä todellinen omistaja

Seuraa yhteyttä siitä hetkestä, kun se nousee: asiakas todennetaan, pppd neuvottelee, ja sitten jokin kirjoittaa DNS-asetukset käyttöjärjestelmään. Jos tiedät vain, että VPN vaihtoi selvittimesi, et vielä tiedä, mikä noista vaiheista sen teki. Kaksi niistä voi, ja dokumentoitua pppd-integraatiota käyttävässä asiakkaassa ne toimivat tarpeeksi lähellä toisiaan näyttääkseen yhdeltä toimijalta. Kirjoittajan nimeäminen on ensimmäinen askel; sen korvaajan valinta on toinen, ja se on erillinen päätös omine vikatiloineen.

Alla oleva järjestys seuraa asiakasta ulospäin: mitä yhteys muutti, mikä kytkin vaientaa minkä kirjoittajan, kenen pitäisi ottaa vastuu ja miten varmistat, että tulos kestää uudelleenyhdistämisen. Jokainen vaihe jättää erilaisen jäljen, ja jälki on se, mikä kertoo sinulle, tapahtuiko luovutus todella.

Aloita siitä, mitä yhteys todella muutti

Yhdistä kerran tavallisella komennollasi ja vertaa nimien selvitystä ennen ja jälkeen. Linux-isännässä, jossa on systemd-resolved, resolvectl status tulostaa DNS-palvelimet ja hakutoimialueet jokaista linkkiä kohden, ja uusi tun- tai ppp-linkki omine palvelimineen on asiakaspuolen päivityksen sormenjälki. macOS:ssä scutil --dns näyttää selvittimen kokoonpanon siinä järjestyksessä, jossa sovellukset sitä kysyvät.

Vertaa sitä tiedostoon, jonka odotit muuttuvan. Linkkikohtaisessa näkymässä oleva yhteyteen sidottu merkintä ja uudelleenkirjoitettu /etc/resolv.conf ovat kaksi eri lopputulosta, ja jälkimmäinen voi olla symbolinen linkki, jota hallitsee kokonaan jokin muu. Kirjaa selvittimen osoite, hakutoimialueet ja liitännän nimi samalla hetkellä; muutos missä tahansa niistä osoittaa toiseen kirjoittajaan. Ilman tätä perustasoa jokainen myöhempi korjaus on arvaus siitä, mikä kolmesta komponentista liikahti.

Kaksi kytkintä ja kirjoittaja, jonka kumpikin vaientaa

openfortivpn dokumentoi valitsinfragmentin, joka sammuttaa molemmat kirjoittajat, joita se voi hallita, ja jokaisella kytkimellä on täysin kirjoitettu vastine, jota käsikirja kohtelee samana asetuksena.

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 estää asiakasta soveltamasta DNS-palvelimia, jotka se oppi yhdyskäytävältä, kun taas --pppd-no-peerdns estää pppd:tä työntämästä vertaisparin DNS:ää järjestelmään. Upstreamin käsikirja varoittaa, että PPP:n kautta tehtävät DNS-päivitykset voivat kilpailla asiakkaan omien DNS-päivitysten kanssa, minkä vuoksi molemmat kytkimet kuuluvat fragmenttiin sen sijaan, että kumpaakaan pidettäisiin riittävänä.

Kumpikaan kytkin ei nimeä varaselvitintä, eikä kumpikaan estä verkkohallintaa, DHCP-asiakasta tai erillistä VPN-integraatiota kirjoittamasta selvitystä jälkeenpäin. Kahden kirjoittajan vaientaminen jättää kentän avoimeksi eikä omistetuksi. Jos kolmas komponentti hallitsee jo DNS:ää, fragmentti ei muuta mitään havaittavaa; jos mikään ei hallitse sitä, juuri poistit ainoan yksityisten nimien selvityksen lähteen. Tämä on pätevä järjestely vain, kun korvaava omistaja valittiin ensin ja testattiin erikseen.

Valitse omistaja ennen kuin poistat mitään käytöstä

Päätä ensin, kuka vastaa työnimien kyselyihin, koska se valinta rajoittaa kaikkea sen jälkeen. Nykyisen selvittimen pitäminen tarkoittaa, että yksityisen vyöhykkeen on jo oltava tavoitettavissa sieltä, missä asiakas istuu, ja toimiston sisäinen yksityinen selvittäjä tarvitsee reitin, joka kestää tunnelin nousemisen. Jokaisen kyselyn lähettäminen yhdelle sisäiselle palvelulle on kolmas käytäntö terävämmällä vikatilalla: kun tuo palvelu ei ole tavoitettavissa, julkiset nimet epäonnistuvat yksityisten mukana.

Reitin omistus pysyy tarkoituksella erillään. Reittivalinnat eivät ole tarpeen siksi, että muutit DNS:ää, ja reitin asennuksen poistaminen käytöstä ilman korvaajan asentamista voi tehdä juuri valitsemasi selvittimen tavoittamattomaksi. Tarkista reititystaulusta erityisesti selvittimen osoite, ei vain sen sovelluksen aliverkkoa, jota satuit testaamaan.

Tarkista nimien selvitys linkeittäin, ei tiedostoittain

Yksittäinen /etc/resolv.conf ei ole luettelo siitä, mitä sovellukset todella käyttävät isännässä, jossa on rajattu tai toimialuekohtainen selvitys, joten lue selvittimen tila niin kuin alusta sen paljastaa.

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

Kysy yhtä yksityistä nimeä ja yhtä julkista nimeä, kun yhteys on ylhäällä, ja merkitse, mikä linkki vastasi kumpaankin. Kun VPN-linkki kantaa toimialuekohtaisen hakuluettelon, yksityinen nimi voi selvitä oikein, kun taas julkinen nimi menee yhä paikalliselle selvittimelle, ja tämä jako on toimivaa suunnittelua eikä vika. Jos yksityinen kysely epäonnistuu, tarkista reitti selvittimelle ennen kuin kosket DNS:ään uudelleen; jos se onnistuu, kun sovellus yhä epäonnistuu, sovellus lukee ehkä omaa välimuistiin tallennettua tai erikseen määritettyä selvitintä.

Yhdistä uudelleen ja varmista irrotettu tila

Laske yhteys alas ja toista molemmat kyselyt. Mitä valittu omistaja asensi, sen pitäisi kyseinen omistaja poistaa tai palauttaa, eikä sitä pitäisi jättää jälkeensä asiakkaan, jonka vaijensit. Tunnelin yli elävä vanhentunut linkkikohtainen merkintä lähettää yhä yksityisiä kyselyitä osoitteeseen, joka ei ole enää tavoitettavissa.

Yhdistä sitten uudelleen ja lue samat kolme arvoa uudelleen: selvittimen osoite, hakutoimialueet, liitäntä.

Jos ne vastaavat kirjaamaasi käytäntöä, luovutus on valmis eikä VPN-asiakas ole enää yksi kirjoittajista. Jos arvo valuu takaisin muutama sekunti linkin nousun jälkeen, jokin muu soveltaa yhä kokoonpanoa, ja seuraava askel on tunnistaa tuo komponentti sen sijaan, että lisäät toisen lipun. Haluamasi lopputila on tapahtumaton: yksi omistaja, yksi dokumentoitu käytäntö ja irrotettu isäntä, joka selvittää täsmälleen kuten ennen tunnelin olemassaoloa.