Por qué un punto de conexión privado sigue respondiendo con una dirección pública

El portátil se conecta, el túnel se declara activo y la cuenta de almacenamiento sigue rechazando todas las solicitudes. El punto de conexión privado existe, la ruta a su subred existe, y el nombre o bien responde con una dirección pública o bien no se resuelve. Nada falla en el túnel: nunca se le dijo al cliente qué servidor debía responder por ese nombre. Siga la consulta hacia fuera y el hueco se vuelve evidente.

Empiece por el resolutor del cliente

Pregunte al cliente a qué servidor consulta mientras el túnel está activo. Un perfil de punto a sitio proporciona esa dirección, y un perfil que no proporciona nada deja que el sistema operativo recurra a los valores predeterminados del adaptador.

Los resolutores públicos no tienen ninguna visión de una zona privada, así que responden desde internet, que es exactamente su trabajo. La primera comprobación es, por tanto, la dirección del resolutor en uso, no el túnel ni el punto de conexión.

Lea qué es realmente la respuesta

Resuelva el nombre del servicio y lea la dirección que vuelve. Una respuesta pública significa que la consulta llegó a un servidor que no puede ver la zona. Ninguna respuesta significa que el nombre solo existe de forma privada y que nada a lo que el cliente pueda llegar lo contiene.

Esos dos resultados producen errores de aplicación parecidos y pertenecen a propietarios distintos. Uno es un problema de selección de resolutor, el otro es un enlace de zona ausente.

Una entrada hosts demuestra la ruta y luego miente

Poner la dirección del punto de conexión en el archivo hosts local es la forma más rápida de demostrar que el túnel y el cortafuegos del servicio ya funcionan. Si la solicitud tiene éxito con esa entrada, solo está rota la resolución de nombres. También es un cambio por máquina que cubre exactamente un nombre.

No ayuda a la segunda cuenta, al segundo punto de conexión ni a un compañero, y se rompe sin aviso cuando el punto de conexión se recrea en una dirección nueva.

Peor aún, hace que su máquina se comporte de forma distinta a la de todos los demás, y así es como una avería del resolutor sobrevive una semana de investigación. Úsela para confirmar la ruta, luego quítela y corrija la causa.

Enlace la zona y reparta un resolutor

Dos condiciones deben cumplirse a la vez. La zona privada debe estar vinculada a la red virtual donde vive el punto de conexión, y el cliente debe enviar sus consultas a un servidor que pueda leer esa zona. Un punto de conexión de entrada de DNS Private Resolver proporciona esa dirección dentro de la red y responde a las consultas que llegan por el túnel. Ponga esa dirección en el perfil de VPN y añada el sufijo privado que el cliente debe aplicar.

Un resolutor local ya existente puede alcanzar el mismo resultado mediante un reenviador condicional dirigido a la zona.

Las reglas de red del resolutor cuentan tanto como el enrutamiento. Si la regla de entrada excluye el rango de clientes de VPN, las consultas caducan en lugar de devolver una respuesta incorrecta. Es ese tiempo de espera el que devuelve a la gente a una tabla de rutas donde nada está mal.

Compruebe nombre, puerto e identidad en orden

Trabaje en orden: resuelva el nombre, confirme que la respuesta es privada, abra el puerto y haga una solicitud autenticada. Cada etapa tiene su propio dueño y su propia firma de fallo.

Una respuesta privada seguida de un tiempo de espera apunta a una ruta o a un cortafuegos. Una respuesta pública apunta al resolutor. Una conexión completada que devuelve un error de identidad pertenece al servicio.

Otro fallo pertenece a esta lista. Un cortafuegos de servicio que permite una dirección de cliente deja de coincidir cuando el grupo asigna esa dirección a otra sesión tras reconectarse. Lea la dirección del llamante que el servicio registró, no la que el cliente cree tener. Las dos discrepan más a menudo de lo que la gente espera. La guía de Azure DNS Private Resolver cubre el enlace de zona y la disposición de reenvío.