openfortivpn daŭre superskribas DNS? Trovu la veran posedanton

Sekvu la konekton de la momento, kiam ĝi leviĝas: la kliento aŭtentikigas, pppd intertraktas, kaj poste io skribas DNS-agordojn en la operaciumon. Se vi nur scias, ke la VPN ŝanĝis vian solvilon, vi ankoraŭ ne scias, kiu el tiuj etapoj faris tion. Du el ili povas, kaj ĉe kliento uzanta la dokumentitan pppd-integriĝon ili funkcias sufiĉe proksime unu al la alia por aspekti kiel unu aktoro. Nomado de la skribanto estas la unua paŝo; elekto de ĝia anstataŭanto estas la dua, kaj tio estas aparta decido kun propraj fiaskmanieroj.

La sinsekvo sube sekvas la klienton eksteren: kion ŝanĝis la konekto, kiu ŝaltilo silentigas kiun skribanton, kiu devus transpreni, kaj kiel konfirmi, ke la rezulto postvivas rekonekton. Ĉiu etapo lasas malsaman spuron, kaj la spuro estas tio, kio diras al vi, ĉu la transdono vere okazis.

Komencu per tio, kion la konekto vere ŝanĝis

Konektiĝu unufoje per via kutima komando kaj komparu la solvon antaŭ kaj post. Ĉe Linux-gastiganto kun systemd-resolved, resolvectl status presas la DNS-servilojn kaj serĉajn domajnojn por ĉiu ligo, kaj nova tun- aŭ ppp-ligo portanta proprajn servilojn estas la fingrospuro de klientflanka ĝisdatigo. Ĉe macOS, scutil --dns montras la agordon de la solvilo en la ordo, en kiu aplikaĵoj konsultas ĝin.

Komparu tion kun la dosiero, kiun vi atendis ŝanĝiĝi. Konekto-ligita ero en la vido por ĉiu ligo kaj reskribita /etc/resolv.conf estas du malsamaj rezultoj, kaj la dua povas esti simbola ligilo, kiun tute administras io alia. Notu la adreson de la solvilo, la serĉajn domajnojn kaj la interfacan nomon en la sama momento; ŝanĝo en iu ajn el ili montras al alia skribanto. Sen tiu bazlinio, ĉiu posta korekto estas konjekto pri tio, kiu el tri komponantoj moviĝis.

La du ŝaltiloj kaj la skribanto, kiun ĉiu silentigas

openfortivpn dokumentas opcian fragmenton, kiu malŝaltas ambaŭ skribantojn, kiujn ĝi povas kontroli, kaj ĉiu ŝaltilo havas plene skribitan ekvivalenton, kiun la manlibro traktas kiel la saman agordon.

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 malhelpas la klienton apliki la DNS-servilojn, kiujn ĝi lernis de la enirejo, dum --pppd-no-peerdns malhelpas pppd puŝi la DNS de la kontraŭulo en la sistemon. La manlibro de upstream avertas, ke DNS-ĝisdatigoj per PPP povas vetkuri kontraŭ la propraj DNS-ĝisdatigoj de la kliento, kaj tial ambaŭ ŝaltiloj apartenas al la fragmento anstataŭ trakti iun ajn el ili kiel sufiĉan.

Nek unu ŝaltilo nomas anstataŭan solvilon, nek unu malhelpas retan administrilon, DHCP-klienton aŭ apartan VPN-integriĝon skribi solvon poste. Silentigi du skribantojn lasas la kampon malfermita anstataŭ posedata. Se tria komponanto jam administras DNS, la fragmento ŝanĝas nenion observeblan; se nenio administras ĝin, vi ĵus forigis la solan fonton de solvo de privataj nomoj. Tio estas valida aranĝo nur kiam la anstataŭa posedanto estis elektita unue kaj testita memstare.

Elektu la posedanton antaŭ ol malŝalti ion

Unue decidu, kiu respondas demandojn pri laboraj nomoj, ĉar tiu elekto limigas ĉion post ĝi. Reteni la ekzistantan solvilon signifas, ke la privata zono jam devas esti atingebla de kie ajn la kliento sidas, kaj privata solvilo ene de la oficejo bezonas itineron, kiu postvivas la leviĝon de la tunelo. Sendi ĉiun demandon al unu interna servo estas tria politiko kun pli akra fiaskmaniero: kiam tiu servo ne estas atingebla, publikaj nomoj fiaskas kune kun la privataj.

Itinera posedado restas aparta intence. La itineroj opcioj ne estas postulataj ĉar vi ŝanĝis DNS, kaj malŝalti itineran instaladon sen instali anstataŭanton povas igi la solvilon, kiun vi ĵus elektis, neatingebla. Kontrolu la enkursigan tabelon specife por la adreso de la solvilo, ne nur por la aplikaĵa subreto, kiun vi hazarde testis.

Kontrolu la solvon por ĉiu ligo, ne por dosiero

Unu sola /etc/resolv.conf ne estas inventaro de tio, kion aplikaĵoj vere uzas ĉe gastiganto kun limigita aŭ podomajna solvo, do legu la staton de la solvilo tiel, kiel la platformo elmontras ĝin.

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

Demandu unu privatan nomon kaj unu publikan nomon post kiam la konekto leviĝis, kaj notu, kiu ligo respondis al ĉiu. Kie la VPN-ligo portas serĉliston podomajnan, privata nomo povas solviĝi ĝuste dum publika nomo ankoraŭ iras al la loka solvilo, kaj tiu divido estas la dizajno funkcianta, ne difekto. Se la privata demando fiaskas, inspektu la itineron al la solvilo antaŭ ol tuŝi DNS denove; se ĝi sukcesas dum aplikaĵo ankoraŭ fiaskas, la aplikaĵo eble legas propran kaŝmemorigitan aŭ aparte agorditan solvilon.

Rekonektiĝu kaj konfirmu la malkonektitan staton

Mallevu la konekton kaj ripetu ambaŭ demandojn. Kion ajn la elektita posedanto instalas, tiu posedanto devus forigi aŭ restarigi ĝin, ne lasi ĝin malantaŭe la kliento, kiun vi silentigis. Kaduka ero por ĉiu ligo, kiu postvivas la tunelon, daŭre sendas privatajn demandojn al adreso, kiu jam ne estas atingebla.

Poste rekonektiĝu kaj legu denove la samajn tri valorojn: adreso de la solvilo, serĉaj domajnoj, interfaco.

Se ili kongruas kun la politiko, kiun vi notis, la transdono estas kompleta kaj la VPN-kliento jam ne estas unu el la skribantoj. Se valoro reenŝoviĝas kelkajn sekundojn post la levigo de la ligo, io alia ankoraŭ aplikas agordon, kaj la sekva paŝo estas identigi tiun komponanton anstataŭ aldoni ankoraŭ unu flagon. La fina stato, kiun vi volas, estas sensensacia: unu posedanto, unu dokumentita politiko kaj malkonektita gastiganto, kiu solvas ĝuste kiel antaŭ ol la tunelo ekzistis.