El DNS de Azure P2S falla cuando el solucionador está en una VNet emparejada

Haga ping a la VM y responde; pregunte su nombre y el cliente dice que el host es desconocido. Cuando el solucionador está en una red virtual emparejada en lugar de la que contiene la puerta de enlace VPN, ese par de resultados es lo esperado, y ninguna cantidad de diagnóstico del solucionador lo cambia. Falta un contrato de enrutamiento que el emparejamiento retiene por defecto. Dos topologías parecen casi idénticas sobre el papel, y la diferencia entre funcionar y fallar es un par de interruptores de emparejamiento colocados en la dirección correcta.

Imagine un portátil que tuneliza hacia una puerta de enlace en VNet2, con el controlador de dominio que sirve DNS en VNet1.

Dos topologías, una diferencia

Ponga el solucionador dentro de la propia red virtual de la puerta de enlace y el nombre se resuelve en el momento en que el túnel sube. Ningún ajuste de emparejamiento participa en esa consulta.

Mueva el mismo solucionador al otro lado de un emparejamiento y el cliente sigue recibiendo respuesta de la VM mientras el nombre permanece desconocido. Certificado, túnel y cliente no han cambiado. Lo único que se movió es dónde vive el solucionador. El emparejamiento le dio una ruta hacia esa dirección, no autoridad a la puerta de enlace para llevar tráfico hasta allí.

Lado A: permita el tránsito de puerta de enlace en el propietario de la puerta de enlace

Un emparejamiento une dos redes virtuales, pero la unión no es transitiva para el tráfico que llega a través de una puerta de enlace, y una solicitud de punto a sitio llega exactamente así. La puerta de enlace en VNet2 no tiene, por tanto, potestad para entregar la consulta a VNet1 hasta que el diseño se lo conceda. El permiso es un interruptor en el emparejamiento que posee la red que contiene la puerta de enlace.

Establezca Allow gateway transit en el emparejamiento de VNet2 hacia VNet1. La propiedad pertenece al objeto de emparejamiento, no al recurso de puerta de enlace, así que se lee y se cambia en la hoja de emparejamiento. Eso es todo el lado A.

Lado B: use puertas de enlace remotas en el par

La otra mitad es la imagen especular: en el emparejamiento de VNet1 de vuelta hacia VNet2, habilite Use remote gateways. Activar el mismo indicador en ambos extremos, o solo en uno, deja un camino a medio construir y el síntoma original intacto. Solo la red con la puerta de enlace VPN permite el tránsito, y el par es el lado que lo usa.

Lea ambas propiedades en ambas redes en lugar de confiar en la hoja del portal que abrió 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 el par uno al lado del otro es la forma más rápida de detectar un ajuste invertido. Un emparejamiento que informa AllowGatewayTransit false en el lado de la puerta de enlace explica todo el fallo sin capturar un paquete.

Qué debe recibir aún el cliente

El enrutamiento es necesario y no suficiente, porque el perfil de punto a sitio también debe entregar al cliente una dirección DNS que responda una vez que funcione el tránsito. El solucionador de la plataforma no es esa dirección: responde a las zonas de Azure Private DNS vinculadas a la red virtual, pero nada para una zona alojada en sus propios servidores de directorio, que es lo que usa este despliegue. Apunte un cliente a él y los nombres públicos se resuelven alegremente mientras el host interno sigue desconocido.

Consulte el solucionador desde el portátil conectado antes de cambiar cualquier otra cosa.

nslookup dc01.corp.example 10.1.0.4

Un tiempo de espera dice que el camino sigue faltando. Una respuesta autoritativa devuelve el problema al cliente, normalmente un sufijo que nunca se añade, así que los nombres cortos viajan a un solucionador público que los falla alegremente.

Compare el mismo contrato en el lado de sitio a sitio

Nada de esto es propio de los portátiles. Cambie el cliente por una sucursal en sitio a sitio y el requisito de dos lados vuelve: la sucursal llega directamente a la red de la puerta de enlace, y un servicio a dos redes de distancia sigue detrás del emparejamiento.

El tránsito debe concederse en ambos emparejamientos, y el interruptor que lo concede vive en el emparejamiento y no en el tipo de cliente.

Antes de culpar a la puerta de enlace

Windows mantiene una lista de solucionadores por adaptador, así que confirme qué recibió realmente la interfaz del túnel antes de culpar a la puerta de enlace.

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

Una respuesta negativa sobrevive a la corrección del enrutamiento en la caché, y una lista de sufijos obsoleta sigue enviando consultas a un lugar que nunca alojó la zona. Vacíe, pregunte de nuevo y anote qué servidor responde.

Dos condiciones más pequeñas deciden si el camino aguanta: los espacios de direcciones no deben solaparse, y el grupo de seguridad de red en la subred del solucionador debe admitir el grupo de clientes, que es solo otro rango de origen. Demuéstrelo con una comprobación de rutas efectivas desde el lado de la VM más una consulta directa desde el cliente, para que un problema de zona, un problema de sufijo o un filtro nunca se confundan con tránsito ausente.