Seu túnel dividido chega à aplicação, mas não ao servidor DNS dela
Um túnel dividido pode encaminhar a sub-rede da aplicação e ainda assim deixar de fora o resolvedor ao lado. Adicione a rota do host e depois verifique qual servidor o Windows realmente escolhe.
Encaminhar a sub-rede da aplicação é a parte óbvia de um túnel dividido, e não é todo o trabalho. O resolvedor costuma estar num endereço diferente da aplicação que atende, então um túnel a funcionar pode deixar a consulta de fora. Um perfil que transporta 10.80.0.0/16 e nada mais envia a consulta de 10.90.0.53 pela interface local, onde não existe nenhuma zona privada. Adicione a rota do resolvedor e depois olhe para a outra metade do problema: qual servidor o cliente realmente escolhe.
O mito: uma rota cobre todo o serviço
Um túnel dividido é uma lista de destinos que passam pela ligação, não uma descrição de um serviço. A sub-rede da aplicação e o endereço do resolvedor são dois destinos, e um perfil pode levar um sem o outro. Quando isso acontece, a aplicação é acessível por endereço enquanto o nome falha, o que parece uma falha de DNS em vez de um buraco de encaminhamento.
A sub-rede em volta do resolvedor também não fica coberta automaticamente. Uma rota de host para um único endereço chega para esse resolvedor e não abre os vizinhos. É esse o sentido de uma rota de host: estreita por conceção e fácil de esquecer quando o serviço seguinte aparece na mesma sub-rede.
Três coisas têm de se verificar para a consulta funcionar: o cliente encaminha o endereço do resolvedor pelo túnel, a gateway aceita e reencaminha esse pedido, e o resolvedor aceita a origem que recebe. A resposta também tem de voltar pelo caminho combinado. Se faltar uma delas, o sintoma é idêntico, por isso vale a pena escrever a tabela de endereços antes de mexer numa configuração.
Determine que endereços o perfil tem de transportar
Liste os destinos por ordem: a rede da aplicação, o endereço do resolvedor e o ponto final público que termina o próprio túnel. O terceiro nunca deve ser encaminhado para dentro do túnel, porque a ligação exterior precisa de um caminho que exista antes do túnel.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Inclua UDP e TCP para DNS, já que se espera que as implementações suportem TCP além de UDP, e um caminho TCP bloqueado produz falhas lentas e parciais em vez de limpas. Se a zona privada também for servida por IPv6, a exceção de host equivalente usa um endereço e um prefixo IPv6 e é uma entrada separada.
Anote o que o perfil já cobre antes de acrescentar seja o que for. Uma rota duplicada é inofensiva, mas uma rota existente inesperada diz-lhe que o perfil foi desenhado para um plano de endereços diferente do que recebeu.
Adicione a rota de host através do proprietário da ligação
Num perfil nativo do Windows gerido localmente, a rota pertence à ligação e não à tabela de encaminhamento global da máquina. Pré-visualize primeiro a adição e depois aplique-a com o mesmo âmbito que o perfil usa.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
O primeiro comando pré-visualiza a alteração sem instalar nada, e o segundo lista as rotas que o perfil transporta neste momento. A referência do Add-VpnConnectionRoute da Microsoft documenta os âmbitos por utilizador e para todos os utilizadores; um perfil para todos os utilizadores precisa do seu próprio parâmetro de âmbito, e um comando por utilizador contra um perfil para todos os utilizadores falha ou acaba no sítio errado.
Quando o perfil é gerido ou vem de um cliente de fornecedor, a alteração pertence a esse proprietário. Empilhar uma rota de sistema permanente sobre uma política de ligação funciona até a política ser reaplicada e a rota desaparecer, o que costuma acontecer durante uma chamada de suporte e não durante os testes. Essa falha é silenciosa: a rota desaparece, o nome deixa de resolver e ninguém liga os dois acontecimentos. Coloque a alteração no registo próprio do proprietário para que a reaplicação seguinte a leve em vez de a apagar.
Depois de aplicar, volte a ligar o perfil em vez de assumir que a rota fez efeito. As alterações de rota numa ligação ativa nem sempre são apanhadas, e voltar a ligar também reproduz o estado que os seus utilizadores terão na realidade.
Verifique qual resolvedor o cliente realmente usou
Uma rota controla os pacotes endereçados ao resolvedor. Não decide que nomes devem ser enviados para lá, e essa seleção é um mecanismo à parte. No Windows, as regras efetivas de espaço de nomes podem escolher um resolvedor por domínio, enquanto as definições de DNS do perfil fornecem um valor predefinido. Essas duas camadas podem discordar sem produzir qualquer erro, e por isso uma consulta direta é apenas metade da prova.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
O primeiro comando imprime a política de espaço de nomes em vigor, e o segundo pergunta diretamente ao resolvedor privado pelo nome da aplicação. Uma resposta direta prova que o caminho e o resolvedor funcionam; não prova que a consulta da própria aplicação escolheu esse servidor. Compare-a com uma consulta normal do mesmo nome e com a resposta que a aplicação recebe.
Tenha em conta as caches e o DNS seguro ao nível do navegador, que pode contornar por completo o resolvedor do sistema para nomes escritos por um utilizador. Um sufixo de pesquisa é outra pista falsa: expande um nome curto num nome totalmente qualificado e não tem nada a ver com o servidor que responde.
Termine voltando a ligar e repetindo a consulta normal, e depois confirme que a navegação comum continua a seguir a sua política aprovada. Substituir o resolvedor privado por um público para que um nome não relacionado resolva não é uma correção, e move em silêncio as consultas privadas para onde nunca deveriam ter ido.