O DNS de Azure P2S falla cando o resolvedor está nunha VNet emparellada

Faga ping á VM e responde; pregunte o seu nome e o cliente di que o host é descoñecido. Cando o resolvedor está nunha rede virtual emparellada en lugar da que contén a pasarela VPN, ese par de resultados é o esperado, e ningunha cantidade de diagnóstico do resolvedor o cambia. Falta un contrato de encamiñamento que o emparellamento retén por defecto. Dúas topoloxías parecen case idénticas sobre o papel, e a diferenza entre funcionar e fallar é un par de interruptores de emparellamento colocados na dirección correcta.

Imaxine un portátil que tuneliza cara a unha pasarela en VNet2, co controlador de dominio que serve DNS en VNet1.

Dúas topoloxías, unha diferenza

Pon o resolvedor dentro da propia rede virtual da pasarela e o nome resólvese no momento en que o túnel sobe. Ningún axuste de emparellamento participa nesa consulta.

Mova o mesmo resolvedor ao outro lado dun emparellamento e o cliente segue recibindo resposta da VM mentres o nome permanece descoñecido. Certificado, túnel e cliente non cambiaron. O único que se moveu é onde vive o resolvedor. O emparellamento deulle unha ruta cara a ese enderezo, non autoridade á pasarela para levar tráfico ata alí.

Lado A: permita o tránsito de pasarela no propietario da pasarela

Un emparellamento une dúas redes virtuais, pero a unión non é transitiva para o tráfico que chega a través dunha pasarela, e unha solicitude de punto a sitio chega exactamente así. A pasarela en VNet2 non ten, por tanto, potestade para entregar a consulta a VNet1 ata que o deseño llo conceda. O permiso é un interruptor no emparellamento que posúe a rede que contén a pasarela.

Estableza Allow gateway transit no emparellamento de VNet2 cara a VNet1. A propiedade pertence ao obxecto de emparellamento, non ao recurso de pasarela, así que se le e se cambia na folla de emparellamento. Iso é todo o lado A.

Lado B: use pasarelas remotas no par

A outra metade é a imaxe especular: no emparellamento de VNet1 de volta cara a VNet2, active Use remote gateways. Activar o mesmo indicador en ambos os extremos, ou só nun, deixa un camiño a medio construír e o síntoma orixinal intacto. Só a rede coa pasarela VPN permite o tránsito, e o par é o lado que o usa.

Lea ambas as propiedades en ambas as redes en lugar de confiar na folla do portal que abriu por última vez.

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 un ao lado do outro é a forma máis rápida de detectar un axuste invertido. Un emparellamento que informa AllowGatewayTransit false no lado da pasarela explica todo o fallo sen capturar un paquete.

Que debe recibir aínda o cliente

O encamiñamento é necesario e non suficiente, porque o perfil de punto a sitio tamén debe entregar ao cliente un enderezo DNS que responda unha vez que funcione o tránsito. O resolvedor da plataforma non é ese enderezo: responde ás zonas de Azure Private DNS vinculadas á rede virtual, pero nada para unha zona aloxada nos seus propios servidores de directorio, que é o que usa este despregamento. Apunte un cliente a el e os nomes públicos resólvense alegremente mentres o host interno segue descoñecido.

Consulte o resolvedor desde o portátil conectado antes de cambiar calquera outra cousa.

nslookup dc01.corp.example 10.1.0.4

Un tempo de espera di que o camiño segue faltando. Unha resposta autoritativa devolve o problema ao cliente, normalmente un sufixo que nunca se engade, así que os nomes curtos viaxan a un resolvedor público que os falla alegremente.

Compare o mesmo contrato no lado de sitio a sitio

Nada disto é propio dos portátiles. Cambie o cliente por unha sucursal en sitio a sitio e o requisito de dous lados volve: a sucursal chega directamente á rede da pasarela, e un servizo a dúas redes de distancia segue detrás do emparellamento.

O tránsito debe concederse en ambos os emparellamentos, e o interruptor que o concede vive no emparellamento e non no tipo de cliente.

Antes de culpar a pasarela

Windows mantén unha lista de resolvedores por adaptador, así que confirme que recibiu realmente a interface do túnel antes de culpar a pasarela.

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

Unha resposta negativa sobrevive á corrección do encamiñamento na caché, e unha lista de sufixos obsoleta segue enviando consultas a un lugar que nunca aloxou a zona. Baleire, pregunte de novo e anote que servidor responde.

Dúas condicións máis pequenas deciden se o camiño aguanta: os espazos de enderezos non deben solaparse, e o grupo de seguridade de rede na subrede do resolvedor debe admitir o grupo de clientes, que é só outro rango de orixe. Demóstroo cunha comprobación de rutas efectivas desde o lado da VM máis unha consulta directa desde o cliente, para que un problema de zona, un problema de sufixo ou un filtro nunca se confundan con tránsito ausente.