Instancia con nombre de SQL Server por VPN: descubrimiento, no el puerto 1433

La mayoría de la gente trata un nombre de host de SQL Server como una dirección completa, y una VPN como algo permitido o no. En la práctica, una instancia con nombre obliga al cliente a hacer una segunda consulta después del DNS, y esa consulta es la parte que un túnel rompe con más frecuencia. Un extremo explícito la evita, por eso tcp:host,port puede funcionar mientras host\INSTANCE agota el tiempo. La distinción está entre encontrar el servicio y tener permiso para usarlo.

El mito: un nombre de host significa un puerto

El nombre de host se resuelve en una dirección, y ahí termina su trabajo. Una instancia con nombre añade un nombre de instancia que el servidor debe traducir a un puerto TCP, y el cliente no puede adivinarlo. El puerto 1433 es el predeterminado de una instancia predeterminada, no una propiedad de cada instancia de la máquina. Tratar ambas cosas como la misma produce el síntoma clásico: el ping funciona, el DNS funciona, el escaneo del 1433 no muestra nada, y la conclusión es que la red bloquea SQL.

Una segunda suposición falla de la misma manera: que abrir TCP 1433 es suficiente. Si la instancia escucha en otro sitio, un 1433 abierto solo demuestra que hay otra cosa allí. El puerto tiene que coincidir con el escucha, y el escucha es un detalle de configuración del lado del servidor, eso conviene preguntarlo en lugar de suponerlo.

Qué hace realmente el cliente con una instancia con nombre

Tras resolver el host, el cliente envía una solicitud de descubrimiento a SQL Server Browser por UDP 1434 y pregunta qué puerto usa la instancia con nombre. El servicio de explorador responde desde el registro del propio servidor, y luego el cliente abre una conexión TCP a ese puerto. Intervienen dos protocolos y dos puertos antes de que se intente siquiera un inicio de sesión.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

Por eso un bloqueo solo de UDP produce un tiempo de espera que parece un host muerto. Si el servicio de explorador está detenido o deshabilitado, la solicitud de descubrimiento queda sin respuesta aunque el motor de base de datos esté funcionando y su puerto TCP esté abierto. Si la instancia está configurada con un puerto estático, el cliente sigue preguntando a menos que se le haya dado el extremo directamente. Cada uno de esos fallos se ve idéntico en el mensaje de error de la aplicación, y necesitan correcciones distintas.

El servicio de explorador es una comodidad para el descubrimiento, no la base de datos. Detenerlo no detiene el motor, y arrancarlo no abre el puerto TCP de la instancia.

Por qué el extremo explícito funciona cuando el nombre no

Un extremo explícito elimina la consulta de la secuencia: el cliente se conecta directamente a la dirección y el puerto que nombró. Eso es primero un diagnóstico, no automáticamente una solución permanente, porque el puerto puede cambiar si más adelante la instancia se reconfigura a uno dinámico. Compare las dos formas con el mismo cliente y la misma cuenta antes de sacar conclusiones.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Si la forma explícita funciona y la forma con nombre falla, el descubrimiento es el hueco, y puedes elegir cómo cerrarlo: permitir UDP 1434 a través del túnel, o pedir al administrador que fije un puerto estático y documente el extremo. Ambas son decisiones deliberadas con costes de mantenimiento distintos. Abrir todos los puertos del rango no es ninguna de las dos, y es la opción que suele proponerse al final de un día largo. Anota la elección donde viven las cadenas de conexión.

Si no funciona ninguna de las dos formas, el problema está más arriba del descubrimiento. Comprueba el escucha, la ruta y la regla de acceso para el puerto que la instancia usa realmente antes de culpar al servicio de explorador.

Después del descubrimiento: autenticación e identidad son cosas separadas

Un fallo de inicio de sesión es un evento distinto de un tiempo de espera, y la identidad VPN no se convierte en un inicio de sesión SQL por tener el túnel. Cuando el cliente llega al puerto correcto, el motor de base de datos aplica su propia autenticación y sus permisos. Mezclar las dos etapas en un solo ticket es como un problema de descubrimiento acaba asignado al equipo equivocado. Lee el número de error antes de cambiar nada.

Mantén el nombre de host documentado si el controlador valida el certificado del servidor, porque conectarse por dirección numérica puede cambiar esa comprobación en lugar de resolver el problema original. Los controladores recientes de Microsoft cifran por defecto, así que una discrepancia de nombre aparece como un error de certificado tras una conexión TCP correcta. Eso es avance, no un fallo nuevo.

El mito que hay que retirar es que un nombre de host de SQL Server sea una dirección completa. Es un host más, para una instancia con nombre, una consulta que el túnel puede no transportar. Nombra el puerto, nombra la ruta de descubrimiento, y el siguiente fallo te dirá qué capa hay que arreglar.