O DNS do Azure P2S falha quando o resolvedor está numa VNet emparelhada

Faça ping à VM e ela responde; pergunte o nome e o cliente diz que o anfitrião é desconhecido. Quando o resolvedor está numa rede virtual emparelhada em vez de na que contém o gateway VPN, esse par de resultados é o esperado, e nenhuma quantidade de diagnóstico do resolvedor o muda. O que falta é um contrato de encaminhamento que o emparelhamento retém por predefinição. Duas topologias parecem quase idênticas no papel, e a diferença entre funcionar e falhar é um par de interruptores de emparelhamento colocados na direção certa.

Imagine um portátil a criar um túnel para um gateway na VNet2, com o controlador de domínio que serve DNS na VNet1.

Duas topologias, uma diferença

Coloque o resolvedor dentro da própria rede virtual do gateway e o nome resolve-se no momento em que o túnel sobe. Nenhuma definição de emparelhamento participa nessa consulta.

Mova o mesmo resolvedor para o outro lado de um emparelhamento e o cliente continua a receber resposta da VM enquanto o nome permanece desconhecido. Certificado, túnel e cliente estão inalterados. A única coisa que mudou foi onde vive o resolvedor. O emparelhamento deu-lhe uma rota para esse endereço, não autoridade ao gateway para transportar tráfego para lá.

Lado A: permita o trânsito de gateway no proprietário do gateway

Um emparelhamento liga duas redes virtuais, mas a ligação não é transitiva para o tráfego que chega através de um gateway, e um pedido ponto-a-site chega exatamente assim. O gateway na VNet2 não tem, portanto, legitimidade para entregar a consulta à VNet1 até o desenho o permitir. A permissão é um interruptor no emparelhamento detido pela rede que contém o gateway.

Defina Allow gateway transit no emparelhamento da VNet2 para a VNet1. A propriedade pertence ao objeto de emparelhamento, não ao recurso de gateway, por isso lê-se e altera-se na lâmina de emparelhamento. É todo o lado A.

Lado B: use gateways remotos no par

A outra metade é a imagem espelhada: no emparelhamento da VNet1 de volta para a VNet2, ative Use remote gateways. Ligar o mesmo indicador nas duas pontas, ou apenas numa, deixa um caminho a meio construir e o sintoma original intacto. Só a rede com o gateway VPN permite trânsito, e o par é o lado que o usa.

Leia ambas as propriedades nas duas redes em vez de confiar na lâmina do portal que abriu por último.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Ver o par lado a lado é a forma mais rápida de apanhar uma definição invertida. Um emparelhamento que reporta AllowGatewayTransit false do lado do gateway explica toda a falha sem captura de pacotes.

O que o cliente ainda tem de receber

O encaminhamento é necessário e não suficiente, porque o perfil ponto-a-site também tem de entregar ao cliente um endereço DNS que responda depois de o trânsito funcionar. O resolvedor da plataforma não é esse endereço: responde a zonas Azure Private DNS ligadas à rede virtual, mas nada para uma zona alojada nos seus próprios servidores de diretório, e é isso que esta implementação usa. Aponte um cliente para ele e os nomes públicos resolvem-se alegremente enquanto o anfitrião interno continua desconhecido.

Pergunte ao resolvedor a partir do portátil ligado antes de mudar mais alguma coisa.

nslookup dc01.corp.example 10.1.0.4

Um tempo limite diz que o caminho ainda falta. Uma resposta autoritativa empurra o problema de volta para o cliente, normalmente um sufixo que nunca é acrescentado, pelo que os nomes curtos viajam para um resolvedor público que os faz falhar alegremente.

Compare o mesmo contrato do lado site-a-site

Nada disto pertence especificamente aos portáteis. Troque o cliente por uma filial em site-a-site e o requisito de dois lados regressa: a filial chega diretamente à rede do gateway, e um serviço a duas redes de distância continua atrás do emparelhamento.

O trânsito tem de ser concedido nos dois emparelhamentos, e o interruptor que o concede vive no emparelhamento e não no tipo de cliente.

Antes de culpar o gateway

O Windows mantém uma lista de resolvedores por adaptador, por isso confirme o que a interface do túnel recebeu realmente antes de culpar o gateway.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Uma resposta negativa sobrevive à correção do encaminhamento na cache, e uma lista de sufixos desatualizada continua a enviar consultas para um local que nunca alojou a zona. Limpe, pergunte de novo e anote qual servidor responde.

Duas condições mais pequenas decidem se o caminho aguenta: os espaços de endereços não podem sobrepor-se, e o grupo de segurança de rede na sub-rede do resolvedor tem de admitir o conjunto de clientes, que é apenas outro intervalo de origem. Prove-o com uma verificação de rotas efetivas do lado da VM mais uma consulta direta do cliente, para que um problema de zona, um problema de sufixo ou um filtro nunca sejam confundidos com trânsito em falta.