openfortivpn sobreescriu el DNS? Trobeu el propietari real

Seguiu la connexió des del moment que s'aixeca: el client s'autentica, pppd negocia i llavors alguna cosa escriu la configuració de DNS al sistema operatiu. Si només sabeu que la VPN us va canviar el resolutor, encara no sabeu quina d'aquestes etapes ho va fer. Dues d'elles poden, i en un client que fa servir la integració documentada amb pppd funcionen prou a prop l'una de l'altra per semblar un sol actor. Nomenar l'escriptor és el primer pas; triar-ne el substitut és el segon, i és una decisió separada amb els seus propis modes de fallada.

La seqüència de sota segueix el client cap enfora: què va canviar la connexió, quin commutador suprimeix quin escriptor, qui ha d'assumir-ho i com confirmar que el resultat sobreviu a una reconnexió. Cada etapa deixa un rastre diferent, i el rastre és el que us diu si el traspàs va passar de debò.

Comenceu per què va canviar realment la connexió

Connecteu-vos una vegada amb la vostra invocació habitual i compareu la resolució abans i després. En un amfitrió Linux amb systemd-resolved, resolvectl status imprimeix els servidors DNS i els dominis de cerca per enllaç, i un enllaç tun o ppp nou que porti els seus propis servidors és l'empremta d'una actualització del costat del client. A macOS, scutil --dns mostra la configuració del resolutor en l'ordre en què les aplicacions la consulten.

Compareu-ho amb el fitxer que esperàveu que canviés. Una entrada vinculada a la connexió a la vista per enllaç i un /etc/resolv.conf reescrit són dos resultats diferents, i el segon pot ser un enllaç simbòlic que gestiona del tot una altra cosa. Anoteu l'adreça del resolutor, els dominis de cerca i el nom de la interfície en el mateix moment; un canvi en qualsevol d'ells apunta a un escriptor diferent. Sense aquesta línia de base, cada correcció posterior és una conjectura sobre quin de tres components s'ha mogut.

Els dos commutadors i l'escriptor que silencia cadascun

openfortivpn documenta un fragment d'opcions que desactiva tots dos escriptors que pot controlar, i cada commutador té un equivalent escrit del tot que el manual tracta com la mateixa configuració.

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 impedeix que el client apliqui els servidors DNS que ha après de la passarel·la, mentre que --pppd-no-peerdns impedeix que pppd empenyi el DNS del parell dins del sistema. El manual de l’upstream adverteix que les actualitzacions de DNS per PPP poden competir amb les actualitzacions de DNS pròpies del client, i per això tots dos commutadors pertanyen al fragment en lloc de tractar-ne cap com a suficient.

Cap commutador no nomena un resolutor substitut, ni impedeix que un gestor de xarxa, un client DHCP o una integració de VPN separada escriguin la resolució després. Suprimir dos escriptors deixa el camp obert en lloc de posseït. Si un tercer component ja gestiona el DNS, el fragment no canvia res que pugueu observar; si no el gestiona res, acabeu de treure l'única font de resolució de noms privats. Aquesta és una disposició vàlida només quan el propietari substitut es va triar primer i es va provar pel seu compte.

Trieu el propietari abans de desactivar res

Decidiu primer qui respon les consultes dels noms de feina, perquè aquesta tria condiciona tot el que ve després. Mantenir el resolutor existent vol dir que la zona privada ja ha de ser abastable des d'on sigui que se situï el client, i un resolutor privat dins de l'oficina necessita una ruta que sobrevisqui a l'aixecament del túnel. Enviar cada consulta a un sol servei intern és una tercera política amb un mode de fallada més esmolat: quan aquest servei no és abastable, els noms públics fallen juntament amb els privats.

La propietat de les rutes es manté separada a propòsit. Les opcions de ruta no són necessàries perquè hàgiu canviat el DNS, i desactivar la instal·lació de rutes sense instal·lar un substitut pot fer inabastable el resolutor que acabeu de triar. Reviseu la taula d'encaminament específicament per a l'adreça del resolutor, no només per a la subxarxa de l'aplicació que vàreu provar per casualitat.

Comproveu la resolució per enllaç, no per fitxer

Un sol /etc/resolv.conf no és un inventari del que les aplicacions fan servir realment en un amfitrió amb resolució limitada o per domini, així que llegiu l'estat del resolutor tal com la plataforma l'exposa.

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

Consulteu un nom privat i un nom públic un cop la connexió és enlaire, i anoteu quin enllaç ha respost cada un. On l'enllaç de la VPN porta una llista de cerca per domini, un nom privat es pot resoldre correctament mentre un nom públic encara va al resolutor local, i aquesta divisió és el disseny funcionant i no una fallada. Si la consulta privada falla, inspeccioneu la ruta cap al resolutor abans de tocar el DNS una altra vegada; si té èxit mentre una aplicació encara falla, potser l'aplicació llegeix un resolutor propi en memòria cau o configurat a part.

Reconnecteu-vos i confirmeu l'estat desconnectat

Baixeu la connexió i repetiu totes dues consultes. El que hagi instal·lat el propietari triat ho ha de treure o restaurar aquell propietari, no ho ha de deixar enrere el client que heu silenciat. Una entrada per enllaç obsoleta que sobreviu al túnel continua enviant consultes privades a una adreça que ja no és abastable.

Després reconnecteu-vos i torneu a llegir els mateixos tres valors: adreça del resolutor, dominis de cerca, interfície.

Si coincideixen amb la política que heu escrit, el traspàs és complet i el client de la VPN ja no és un dels escriptors. Si un valor retrocedeix uns segons després de l'aixecament de l'enllaç, alguna altra cosa encara aplica configuració, i el pas següent és identificar aquest component en lloc d'afegir un altre indicador. L'estat final que voleu és sense incidents: un propietari, una política documentada i un amfitrió desconnectat que resol exactament com ho feia abans que el túnel existís.