Quem aplica realmente as configurações de DNS do OpenConnect no Windows?

Levantar o túnel não é o mesmo que instalar os seus valores de DNS. O OpenConnect negocia e um auxiliar do lado do Windows aplica. A lacuna entre esses dois passos explica a maioria das falhas de nomes privados neste cliente, e o auxiliar quase nunca é a página de configurações de VPN do Windows.

Separe o que o gateway ofereceu do que o Windows instalou

O cliente entrega os dados da conexão a uma interface de script, e as variantes de Unix e Windows são programas separados. No Windows a implementação costuma ser um auxiliar JavaScript que lê variáveis como o servidor DNS interno e o domínio interno antes de tocar em qualquer adaptador. Nada dentro do próprio túnel escreve o estado do resolvedor.

Essa divisão importa porque um valor pode existir na negociação e nunca chegar ao adaptador. Um auxiliar ausente, que falha a meio caminho ou que é uma cópia mais antiga incluída num invólucro GUI deixa o Windows exatamente como estava. A sessão parece ligada, o nome privado continua a resolver-se pelo fornecedor local e nada na janela do cliente sugere a diferença. Ler a saída do próprio auxiliar é a única forma fiável de saber que etapa falhou.

Um invólucro GUI pode trazer a sua própria cópia do cliente e do auxiliar, por isso um segundo openconnect.exe noutro local do disco não prova nada. Encontre o executável que iniciou a sessão antes de julgar a sua configuração.

Leia o estado do resolvedor sem o alterar

Três consultas só de leitura cobrem a confusão habitual, e cada uma responde a uma pergunta diferente:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

Um servidor ao nível do adaptador é o que a maioria das pessoas entende por DNS de VPN. Um sufixo específico da ligação decide se um nome curto chega a ser expandido. A lista de políticas de espaço de nomes aplica-se a nomes correspondentes independentemente da ordem dos adaptadores, e um resultado vazio ali não é um defeito quando o auxiliar nunca pretendeu criar um. Ler os três antes de editar é o que evita uma reparação que apenas move o sintoma para outro lugar.

Comece pelo nome totalmente qualificado. Se o FQDN resolve e o nome curto não, a lacuna é o sufixo ou a lista de pesquisa, não o endereço do servidor.

Pergunte diretamente ao servidor pretendido como segundo passo, com qualquer ferramenta de resolvedor já instalada. Uma resposta direta prova que o servidor está acessível e é autoritativo para a zona. Não prova nada sobre qual servidor uma aplicação questiona por predefinição.

Nomeie o componente que possui a ligação

Duas disposições são comuns. Um cliente iniciado a partir de um terminal passa o caminho do seu script explicitamente, pelo que o proprietário é visível no comando executado. Uma aplicação empacotada inicia o cliente por si e guarda o auxiliar no seu próprio diretório, o que significa que o fornecedor decide quando este muda.

Compare as versões do auxiliar entre instalações antes de trocar seja o que for. Executar com privilégios elevados um auxiliar obtido de um espelho porque o nome do ficheiro parece familiar transforma uma lacuna de DNS num incidente de segurança.

Assim que o proprietário é conhecido, o alvo da reparação torna-se óbvio: um caminho de script suportado no lançador, uma atualização do pacote ou um perfil corrigido no gateway. Nenhum deles exige editar manualmente as propriedades do adaptador.

Repare o proprietário, não o adaptador

O DNS definido manualmente no adaptador sobrevive muitas vezes à desconexão, e é por isso que parece funcionar e depois causa problemas na rede seguinte. Um resolvedor público aparafusado em cada interface esconde o problema do espaço de nomes privado em vez de o resolver. Quando o auxiliar nunca recebeu um valor de DNS, o perfil do gateway é o local a observar. Quando recebeu um e o adaptador ainda mostra o servidor antigo, o auxiliar falhou durante a ligação e o registo do cliente costuma registá-lo perto das linhas de configuração do túnel.

Reconstrua o estado pelo caminho suportado e depois verifique um ciclo completo: ligue, resolva o FQDN privado, abra o serviço, desligue e confirme que o adaptador voltou com os servidores anteriores.

Verifique a aplicação que realmente falha

Um navegador com a sua própria definição de DNS encriptado ignora tudo o que está acima e continua a responder a partir de um resolvedor público. Uma aplicação que guarda uma resposta negativa em cache de antes de o túnel subir comporta-se da mesma forma. Compare-a com uma consulta de sistema simples na mesma máquina antes de voltar a alterar os endereços do resolvedor.

Se a consulta do sistema está correta e a aplicação não, a falha restante está dentro da configuração de DNS dessa aplicação, não no caminho da VPN.