Patuloy na nire-rewrite ng openfortivpn ang DNS? Hanapin ang tunay na may-ari

Sundin ang koneksyon mula sa sandaling umangat ito: nagpapatunay ang kliyente, nakikipagnegosasyon ang pppd, at pagkatapos ay may nagsusulat ng mga setting ng DNS sa operating system. Kung alam mo lamang na binago ng VPN ang iyong resolver, hindi mo pa alam kung alin sa mga yugtong iyon ang gumawa nito. Dalawa sa kanila ang kaya, at sa isang kliyenteng gumagamit ng dokumentadong integrasyon ng pppd, tumatakbo sila nang sapat na malapit upang magmukhang isang aktor. Ang pagngangalan sa manunulat ay ang unang hakbang; ang pagpili ng kapalit nito ay ang pangalawa, at iyon ay hiwalay na desisyon na may sariling mga paraan ng pagpalya.

Ang pagkakasunod-sunod sa ibaba ay sumusunod sa kliyente pakanluran: ano ang binago ng koneksyon, aling switch ang nagpapatahimik sa aling manunulat, sino ang dapat humalili at paano kumpirmahin na ang resulta ay nakakaligtas sa muling pagkonekta. Bawat yugto ay nag-iiwan ng ibang bakas, at ang bakas ang nagsasabi sa iyo kung tunay na nangyari ang paglilipat.

Magsimula sa kung ano talaga ang binago ng koneksyon

Kumonekta nang isang beses gamit ang iyong karaniwang utos at ihambing ang resolusyon bago at pagkatapos. Sa isang host na Linux na nagpapatakbo ng systemd-resolved, ipiniprint ng resolvectl status ang mga server ng DNS at mga domain ng paghahanap bawat link, at ang bagong tun o ppp na link na may sariling mga server ay ang fingerprint ng update mula sa panig ng kliyente. Sa macOS, ipinapakita ng scutil --dns ang konfigurasyon ng resolver sa pagkakasunod-sunod na kinukunsulta ito ng mga aplikasyon.

Ihambing iyon sa file na inaasahan mong magbabago. Ang entry na nakatali sa koneksyon sa view bawat link at ang muling naisulat na /etc/resolv.conf ay dalawang magkaibang resulta, at ang pangalawa ay maaaring simbolikong link na ganap na pinamamahalaan ng ibang bagay. Itala ang address ng resolver, ang mga domain ng paghahanap at ang pangalan ng interface sa parehong sandali; ang pagbabago sa alinman sa mga ito ay tumuturo sa ibang manunulat. Kung wala ang baseline na iyon, ang bawat susunod na pagwawasto ay haka-haka tungkol sa alin sa tatlong bahagi ang gumalaw.

Ang dalawang switch at ang manunulat na pinapatahimik ng bawat isa

Dokumentado ng openfortivpn ang isang fragment ng opsyon na nagpapatay sa dalawang manunulat na kayang kontrolin nito, at ang bawat switch ay may buong nakasulat na katumbas na itinuturing ng manwal na parehong setting.

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

Pinipigilan ng --no-dns ang kliyente na ilapat ang mga server ng DNS na natutunan nito mula sa gateway, habang pinipigilan ng --pppd-no-peerdns ang pppd na itulak ang DNS ng kapares sa system. Ang manwal ng upstream ay nagbababala na ang mga update ng DNS sa pamamagitan ng PPP ay maaaring makipagkarera sa sariling mga update ng DNS ng kliyente, kaya ang dalawang switch ay kabilang sa fragment sa halip na isa sa kanila ang ituring na sapat.

Walang switch na nagngangalan ng kapalit na resolver, at walang pumipigil sa tagapamahala ng network, kliyente ng DHCP o hiwalay na integrasyon ng VPN na magsulat ng resolusyon pagkatapos. Ang pagpapatahimik sa dalawang manunulat ay nag-iiwan sa larangan na bukas sa halip na pag-aari. Kung ang ikatlong bahagi ay namamahala na sa DNS, walang binabago ang fragment na maaari mong obserbahan; kung walang namamahala dito, kaaalis mo lang ng nag-iisang pinagmumulan ng resolusyon ng mga pribadong pangalan. Iyon ay isang wastong kaayusan lamang kapag ang kapalit na may-ari ay pinili muna at sinubok nang mag-isa.

Piliin ang may-ari bago mo i-disable ang anuman

Magpasya muna kung sino ang sasagot sa mga query para sa mga pangalan ng trabaho, dahil ang pagpiling iyon ay naglilimita sa lahat ng sumusunod. Ang pagpapanatili ng umiiral na resolver ay nangangahulugan na ang pribadong zone ay dapat na maabot na mula saanman naroon ang kliyente, at ang pribadong resolver sa loob ng opisina ay nangangailangan ng rutang nakakaligtas kapag umangat ang tunnel. Ang pagpapadala ng bawat query sa isang panloob na serbisyo ay ikatlong patakaran na may mas matalas na paraan ng pagpalya: kapag hindi maabot ang serbisyong iyon, nabibigo ang mga pampublikong pangalan kasama ng mga pribado.

Ang pagmamay-ari ng ruta ay nananatiling hiwalay nang sadya. Hindi kailangan ang mga opsyon ng ruta dahil binago mo ang DNS, at ang pag-disable sa pag-install ng ruta nang hindi naglalagay ng kapalit ay maaaring gawing hindi maabot ang resolver na pinili mo lang. Suriin ang routing table partikular para sa address ng resolver, hindi lamang para sa subnet ng aplikasyong sinubukan mo nang nagkataon.

Suriin ang resolusyon bawat link, hindi bawat file

Ang isang /etc/resolv.conf ay hindi imbentaryo ng aktwal na ginagamit ng mga aplikasyon sa isang host na may limitado o bawat domain na resolusyon, kaya basahin ang estado ng resolver sa paraang inilalantad ito ng platform.

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

Magtanong ng isang pribadong pangalan at isang pampublikong pangalan kapag umangat na ang koneksyon, at itala kung aling link ang sumagot sa bawat isa. Kung saan ang link ng VPN ay may dalang listahan ng paghahanap bawat domain, ang pribadong pangalan ay maaaring malutas nang tama habang ang pampublikong pangalan ay patungo pa rin sa lokal na resolver, at ang paghahati na iyon ay gumaganang disenyo at hindi sira. Kung nabigo ang pribadong query, siyasatin ang ruta patungo sa resolver bago muling hawakan ang DNS; kung nagtagumpay ito habang nabigo pa rin ang isang aplikasyon, maaaring binabasa ng aplikasyon ang sarili nitong naka-cache o hiwalay na naka-configure na resolver.

Kumonekta muli at kumpirmahin ang nadiskonektang estado

Ibaba ang koneksyon at ulitin ang dalawang query. Anuman ang inilagay ng piniling may-ari ay dapat alisin o ibalik ng may-ari na iyon, hindi iwanan ng kliyenteng pinatahimik mo. Ang lumang entry bawat link na nabubuhay nang mas matagal kaysa sa tunnel ay patuloy na nagpapadala ng mga pribadong query sa address na hindi na maabot.

Pagkatapos ay kumonekta muli at basahin ang parehong tatlong halaga: address ng resolver, mga domain ng paghahanap, interface.

Kung tumutugma ang mga ito sa patakarang itinala mo, kumpleto na ang paglilipat at ang kliyente ng VPN ay hindi na isa sa mga manunulat. Kung ang isang halaga ay umurong pabalik ilang segundo pagkatapos umangat ang link, may ibang bagay pang naglalapat ng konfigurasyon, at ang susunod na hakbang ay tukuyin ang bahaging iyon sa halip na magdagdag ng isa pang flag. Ang huling estadong gusto mo ay walang pangyayari: isang may-ari, isang dokumentadong patakaran, at isang nadiskonektang host na lumulutas nang eksakto tulad ng dati bago pa man umiral ang tunnel.