O openfortivpn continua a sobrescrever o DNS? Encontre o verdadeiro dono

Siga a ligação desde o momento em que sobe: o cliente autentica-se, o pppd negoceia e, depois, algo escreve as definições de DNS no sistema operativo. Se só sabe que a VPN mudou o seu resolvedor, ainda não sabe qual dessas fases o fez. Duas delas podem, e num cliente que usa a integração pppd documentada funcionam suficientemente perto uma da outra para parecerem um único ator. Nomear o escritor é o primeiro passo; escolher o seu substituto é o segundo, e é uma decisão separada com os seus próprios modos de falha.

A sequência abaixo segue o cliente para fora: o que a ligação mudou, que comutador silencia que escritor, quem deve assumir e como confirmar que o resultado sobrevive a uma religação. Cada fase deixa um rasto diferente, e é o rasto que lhe diz se a entrega aconteceu realmente.

Comece pelo que a ligação alterou de facto

Ligue-se uma vez com o seu comando habitual e compare a resolução antes e depois. Num anfitrião Linux com systemd-resolved, resolvectl status imprime os servidores DNS e os domínios de pesquisa por ligação, e uma nova ligação tun ou ppp que traga os seus próprios servidores é a impressão digital de uma atualização do lado do cliente. No macOS, scutil --dns mostra a configuração do resolvedor pela ordem em que as aplicações a consultam.

Compare isso com o ficheiro cuja alteração esperava. Uma entrada ligada à ligação na vista por ligação e um /etc/resolv.conf reescrito são dois resultados diferentes, e o segundo pode ser uma ligação simbólica gerida inteiramente por outra coisa. Anote o endereço do resolvedor, os domínios de pesquisa e o nome da interface no mesmo instante; uma alteração em qualquer um deles aponta para um escritor diferente. Sem essa linha de base, cada correção posterior é um palpite sobre qual de três componentes se moveu.

Os dois comutadores e o escritor que cada um silencia

O openfortivpn documenta um fragmento de opções que desliga ambos os escritores que consegue controlar, e cada comutador tem um equivalente escrito por extenso que o manual trata como a mesma definição.

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 impede o cliente de aplicar os servidores DNS que aprendeu do gateway, enquanto --pppd-no-peerdns impede o pppd de empurrar o DNS do par para o sistema. O manual do upstream avisa que as atualizações de DNS por PPP podem competir com as atualizações de DNS do próprio cliente, e é por isso que ambos os comutadores pertencem ao fragmento em vez de se considerar qualquer um deles suficiente.

Nenhum comutador nomeia um resolvedor substituto, e nenhum impede um gestor de rede, um cliente DHCP ou uma integração de VPN separada de escrever a resolução depois. Silenciar dois escritores deixa o campo aberto em vez de possuído. Se um terceiro componente já gere o DNS, o fragmento não altera nada que possa observar; se nada o gere, acabou de remover a única fonte de resolução de nomes privados. Isto só é uma disposição válida quando o dono substituto foi escolhido primeiro e testado isoladamente.

Escolha o dono antes de desativar o que quer que seja

Decida primeiro quem responde às consultas dos nomes de trabalho, porque essa escolha condiciona tudo o que vem depois. Manter o resolvedor existente significa que a zona privada já tem de ser alcançável de onde o cliente estiver, e um resolvedor privado dentro do escritório precisa de uma rota que sobreviva à subida do túnel. Enviar cada consulta a um único serviço interno é uma terceira política com um modo de falha mais afiado: quando esse serviço está inacessível, os nomes públicos falham juntamente com os privados.

A propriedade das rotas mantém-se separada de propósito. As opções de rota não são necessárias por ter alterado o DNS, e desativar a instalação de rotas sem instalar um substituto pode tornar inalcançável o resolvedor que acabou de escolher. Verifique a tabela de encaminhamento especificamente para o endereço do resolvedor, não apenas para a sub-rede da aplicação que testou por acaso.

Verifique a resolução por ligação, não por ficheiro

Um único /etc/resolv.conf não é um inventário do que as aplicações usam realmente num anfitrião com resolução limitada ou por domínio, por isso leia o estado do resolvedor como a plataforma o expõe.

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

Consulte um nome privado e um nome público depois de a ligação subir, e anote qual ligação respondeu a cada um. Onde a ligação VPN transporta uma lista de pesquisa por domínio, um nome privado pode resolver-se corretamente enquanto um nome público ainda vai para o resolvedor local, e essa divisão é o desenho a funcionar e não uma falha. Se a consulta privada falhar, inspecione a rota até ao resolvedor antes de voltar a tocar no DNS; se for bem-sucedida enquanto uma aplicação continua a falhar, a aplicação pode estar a ler um resolvedor próprio em cache ou configurado à parte.

Volte a ligar e confirme o estado desligado

Desça a ligação e repita ambas as consultas. O que o dono escolhido instalou deve ser removido ou reposto por esse dono, e não deixado atrás pelo cliente que silenciou. Uma entrada por ligação obsoleta que sobreviva ao túnel continua a enviar consultas privadas para um endereço que já não é alcançável.

Depois volte a ligar e leia outra vez os mesmos três valores: endereço do resolvedor, domínios de pesquisa, interface.

Se corresponderem à política que anotou, a entrega está completa e o cliente VPN já não é um dos escritores. Se um valor recuar alguns segundos depois de a ligação subir, algo mais continua a aplicar configuração, e o passo seguinte é identificar esse componente em vez de acrescentar outro indicador. O estado final que pretende é sem incidentes: um dono, uma política documentada e um anfitrião desligado que resolve exatamente como antes de o túnel existir.