openfortivpn sobrescribe o DNS sen parar? Atope o propietario real

Siga a conexión desde o momento en que se ergue: o cliente autentícase, pppd negocia e despois algo escribe a configuración de DNS no sistema operativo. Se o único que sabe é que a VPN lle cambiou o resolvedor, aínda non sabe cal desas etapas o fixo. Dúas delas poden, e nun cliente que usa a integración documentada con pppd funcionan o bastante preto como para parecer un só actor. Nomear o escritor é o primeiro paso; escoller o seu substituto é o segundo, e é unha decisión aparte cos seus propios modos de fallo.

A secuencia de abaixo segue o cliente cara a fóra: que cambiou a conexión, que interruptor suprime a que escritor, quen debe facerse cargo e como confirmar que o resultado sobrevive a unha reconexión. Cada etapa deixa un rastro distinto, e o rastro é o que lle di se o traspaso ocorreu de verdade.

Comece polo que a conexión cambiou realmente

Conéctese unha vez coa súa invocación habitual e compare a resolución antes e despois. Nun host Linux con systemd-resolved, resolvectl status imprime os servidores DNS e os dominios de busca por enlace, e un enlace tun ou ppp novo que leva os seus propios servidores é a pegada dunha actualización do lado do cliente. En macOS, scutil --dns mostra a configuración do resolvedor na orde en que as aplicacións a consultan.

Compare iso co ficheiro que esperaba que cambiase. Unha entrada vinculada á conexión na vista por enlace e un /etc/resolv.conf reescrito son dous resultados distintos, e o segundo pode ser unha ligazón simbólica que xestiona por completo outra cousa. Anote o enderezo do resolvedor, os dominios de busca e o nome da interface no mesmo momento; un cambio en calquera deles apunta a un escritor distinto. Sen esa liña base, cada corrección posterior é unha conxectura sobre cal de tres compoñentes se moveu.

Os dous interruptores e o escritor que silencia cada un

openfortivpn documenta un fragmento de opcións que apaga ambos os escritores que pode controlar, e cada interruptor ten un equivalente escrito por completo que o manual trata como o mesmo axuste.

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 impide que o cliente aplique os servidores DNS que aprendeu da pasarela, mentres que --pppd-no-peerdns impide que pppd empurre o DNS do par ao sistema. O manual de upstream advirte de que as actualizacións de DNS por PPP poden competir coas actualizacións de DNS propias do cliente, e por iso ambos os interruptores pertencen ao fragmento en lugar de tratar calquera dos dous como suficiente.

Ningún interruptor nomea un resolvedor de substitución, e ningún impide que un xestor de rede, un cliente DHCP ou unha integración de VPN aparte escriban a resolución despois. Silenciar dous escritores deixa o campo aberto en lugar de posuído. Se un terceiro compoñente xa xestiona o DNS, o fragmento non cambia nada que vostede poida observar; se nada o xestiona, acaba de quitar a única fonte de resolución de nomes privados. Eso é unha disposición válida só cando o propietario de substitución se escolleu primeiro e se probou pola súa conta.

Escolla o propietario antes de desactivar nada

Decida primeiro quen responde ás consultas dos nomes de traballo, porque esa elección condiciona todo o que vén despois. Manter o resolvedor existente significa que a zona privada xa debe ser alcanzable desde onde estea o cliente, e un resolvedor privado dentro da oficina necesita unha ruta que sobreviva ao erguemento do túnel. Enviar cada consulta a un só servizo interno é unha terceira política cun modo de fallo máis afiado: cando ese servizo non é alcanzable, os nomes públicos fallan xunto cos privados.

A propiedade das rutas mantense separada a propósito. As opcións de ruta non son necesarias porque vostede cambiase o DNS, e desactivar a instalación de rutas sen instalar un substituto pode deixar inalcanzable o resolvedor que acaba de escoller. Revise a táboa de encamiñamento especificamente para o enderezo do resolvedor, non só para a subrede da aplicación que probou por casualidade.

Comprobe a resolución por enlace, non por ficheiro

Un só /etc/resolv.conf non é un inventario do que as aplicacións usan realmente nun host con resolución limitada ou por dominio, así que lea o estado do resolvedor tal como a plataforma o expón.

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

Consulte un nome privado e un nome público unha vez ergueita a conexión, e anote que enlace respondeu a cada un. Onde o enlace da VPN leva unha lista de busca por dominio, un nome privado pode resolverse correctamente mentres un nome público aínda vai ao resolvedor local, e esa división é o deseño funcionando e non unha avaría. Se a consulta privada falla, inspeccione a ruta cara ao resolvedor antes de tocar o DNS outra vez; se ten éxito mentres unha aplicación segue fallando, pode que a aplicación estea a ler un resolvedor propio en caché ou configurado á parte.

Reconecte e confirme o estado desconectado

Baixe a conexión e repita ambas as consultas. O que instalase o propietario escollido debe retiralo ou restauralo ese propietario, non deixalo atrás o cliente que vostede silenciou. Unha entrada por enlace obsoleta que sobrevive ao túnel segue enviando consultas privadas a un enderezo que xa non é alcanzable.

Despois reconecte e lea outra vez os mesmos tres valores: enderezo do resolvedor, dominios de busca, interface.

Se coinciden coa política que anotou, o traspaso está completo e o cliente da VPN xa non é un dos escritores. Se un valor retrocede uns segundos despois do erguemento do enlace, algo máis segue aplicando configuración, e o paso seguinte é identificar ese compoñente en lugar de engadir outra marca. O estado final que vostede quere é sen sobresaltos: un propietario, unha política documentada e un host desconectado que resolve exactamente como o facía antes de que existise o túnel.