Azure P2S VPN no puede resolver el nombre de un punto de conexión privado

Conecta el túnel de punto a sitio, hace ping a la dirección privada, abre la aplicación y recibe un 403 o un error de certificado en su lugar. Ambos síntomas apuntan al DNS, pero son fallos distintos: uno significa que el cliente resolvió la dirección pública, el otro que resolvió la dirección privada y luego ofreció un nombre que el certificado no cubre. Siga las comprobaciones siguientes en orden y deténgase en el primer fallo, porque una entrada en hosts o una respuesta en caché pueden hacer que cada comprobación posterior pase por el motivo equivocado. Tengo este orden en un archivo de texto junto a mis perfiles de VPN, porque la corrección no cambia nada del túnel y lo cambia todo de lo que sabe el cliente.

Empiece por la dirección que el cliente recibe de verdad

Pregunte al solucionador directamente en lugar de confiar en la aplicación. En Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net muestra qué vista recibió el cliente. Una respuesta pública significa que nada aguas abajo llegará al punto de conexión; la dirección privada del punto de conexión significa que el DNS ha terminado y que la siguiente comprobación es la propia conexión.

Un punto de conexión privado no cambia el nombre del servicio. La cuenta o la aplicación conserva su nombre completo habitual, y el punto de conexión solo cambia la dirección a la que ese nombre se resuelve para los clientes dentro de la red virtual. Por eso el mismo nombre de host se resuelve de forma privada desde una VM de la red y de forma pública desde un portátil al que nunca se le dio la vista privada.

Compruebe la zona, su vínculo y el registro antes del túnel

Tres condiciones deben cumplirse a la vez: la zona privada existe, está vinculada a la red virtual por la que entran en Azure la puerta de enlace de VPN y los clientes, y contiene un registro A del punto de conexión que apunta a la dirección privada. Vincule la zona a una red ajena y la puerta de enlace seguirá resolviendo el registro público mientras todo el túnel parece sano.

Los nombres de zona pertenecen a los servicios, no a los vínculos privados en general. App Service suele usar privatelink.azurewebsites.net, el almacenamiento y SQL tienen sus propios espacios de nombres, y tomar prestada la zona de otro servicio produce una zona que existe y no responde nada útil.

Dé al cliente un solucionador que realmente pueda alcanzar

168.63.129.16 responde desde máquinas virtuales de Azure y no es un servidor DNS para un portátil al otro lado de un túnel de punto a sitio. El cliente necesita un solucionador accesible por el túnel: un punto de conexión entrante de Azure DNS Private Resolver, un reenviador dentro de la red virtual o entradas de servidor DNS transportadas en el perfil del cliente VPN para que el cliente pregunte a la red virtual directamente.

Un solucionador configurado pero inalcanzable se comporta exactamente como ningún solucionador, y el síntoma es un tiempo de espera en lugar de una respuesta incorrecta, por eso se malinterpreta como un problema de firewall. Pruébelo con una consulta que el túnel deba transportar, no con un nombre público que habría funcionado por el enlace local de todos modos.

Si reenvía en lugar de insertar configuraciones, reenvíe el espacio de nombres que posee la zona privada, privatelink.azurewebsites.net en lugar de todo azurewebsites.net. Un reenviador condicional que se traga todo el sufijo padre envía a Azure cada búsqueda del servicio, incluidas las que deberían quedarse locales.

Use el nombre para el que se emitió el certificado

Cuando la dirección es correcta aparece el segundo fallo. El almacenamiento y App Service publican un alias privatelink, y ese alias no es necesariamente el nombre del certificado. Una carga con AzCopy dirigida a privatelink.blob.core.windows.net falló la validación; la misma carga a <account>.blob.core.windows.net/<container> se resolvió a la dirección privada y pasó, así que se quedó en la ruta privada sin ninguna excepción.

La regla vale en el navegador y también para App Service: conéctese con el nombre de host que cubre el certificado y deje que DNS proporcione la dirección privada. No recurra a saltarse la validación, porque convierte un error de nomenclatura en una regresión de seguridad. Un ping correcto demuestra la ruta y no dice nada del nombre dentro del saludo, por eso siguen siendo comprobaciones separadas.

Un orden de cuatro pasos que aísla cada capa

1. Confirme que el cliente VPN tiene una dirección del grupo de punto a sitio y una ruta hacia la dirección privada del punto de conexión.
2. Resuelva el nombre exacto que usa la aplicación y compare la respuesta con la dirección del punto de conexión.
3. Abra una conexión TCP al punto de conexión en el puerto del servicio y luego lea el nombre del certificado que se presenta en esa conexión.
4. Solo ahora pruebe la autorización, porque una ruta que funciona y un certificado válido todavía no dan acceso al recurso.

Una conexión rechazada con la dirección correcta apunta al grupo de seguridad de red o al estado de conexión del punto de conexión privado, no al DNS, así que compruébelos antes de volver a editar la configuración del solucionador. Un desajuste de nombre TLS le devuelve al nombre de host de la URL y al subject del certificado. Guarde juntos la salida de resolución, el nombre del certificado y la URL exacta; esos tres valores explican la mayoría de estos casos sin tocar la puerta de enlace.

Use una VM dentro de la red virtual como control. Si el nombre se resuelve de forma privada allí y de forma pública desde el túnel, la zona y el registro son correctos y la única diferencia es la ruta del solucionador del cliente, que se confirma más rápido que otra pasada por la configuración del punto de conexión.

Los clientes también almacenan en caché. Un registro que respondió de forma pública hace diez minutos sigue respondiendo después de arreglar la zona, así que vacíe la caché antes de volver a probar. En Windows, ipconfig /flushdns limpia la caché del cliente; las reglas de directiva de resolución de nombres persisten, deciden qué sufijo va a qué servidor y pueden seguir enviando el espacio de nombres al solucionador que acaba de sustituir.

Dónde encaja una entrada en hosts

Añadir la dirección del punto de conexión a un archivo hosts es un buen diagnóstico y un mal diseño. Demuestra que la correspondencia entre nombre y dirección es la pieza que falta y le deja probar todo lo posterior, pero es invisible para sus usuarios, se rompe cuando cambia la dirección del punto de conexión y oculta la zona que debería responder.

Una entrada de prueba que se queda es peor que una caché obsoleta, porque puede hacer que la ruta arreglada parezca rota o la ruta rota parezca arreglada según la dirección del error. Elimínela antes de la pasada final y resuelva solo con el solucionador de producción.

Los nombres cortos necesitan un sufijo de búsqueda y los nombres completos no, así que pruebe primero el nombre completo y luego decida si el flujo de trabajo necesita un sufijo insertado por el perfil del cliente. Microsoft documenta los nombres de zona y las formas de registro de cada servicio en sus directrices de DNS para puntos de conexión privados; lea la entrada de su servicio en lugar de copiar una zona de otro.