SQL Server se enlaza a una dirección VPN que no existe al arrancar

Lea una línea del registro de SQL Server sobre un enlace fallido mientras el servicio sigue en ejecución y habrá encontrado una dependencia del orden de arranque, no un bloqueo. Esa combinación es la pista: el motor arrancó antes de que existiera en la máquina la dirección en la que se le dijo que escuchara. Un adaptador VPN que aparece después del inicio de sesión es un mal requisito previo para un servicio de base de datos sin supervisión, así que recorra el fallo en el orden en que lo ve el motor.

Empiece por el registro de inicio, no por el cliente

Abra el registro de errores de la instancia y lea las entradas alrededor de la inicialización de la red, no solo la última línea. El motor informa qué direcciones intentó y qué protocolos habilitó, y ese registro es de antes de que se conectara cualquier cliente. Ahora mire qué existe en el host en este momento. Si la interfaz que posee la dirección configurada solo aparece después de que un usuario inicie sesión y arranque un cliente, la dirección faltaba al arrancar y el fallo de enlace queda totalmente explicado.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Ajuste la ruta de la instancia a su instalación y lea la lista de interfaces antes de sacar conclusiones. Una dirección que existe pero pertenece al adaptador equivocado es un problema distinto de una dirección que aún no existe.

Recorra el orden de enlace que el motor sigue realmente

El motor lee su configuración de receptor y luego pide al sistema operativo que enlace. Si la dirección no es local en ese momento, el enlace falla para esa dirección mientras el resto de la instancia puede continuar con normalidad. Por eso otros protocolos u otras direcciones pueden seguir funcionando, y por eso «SQL Server está caído» es el resumen equivocado. Conserve el punto final exacto del registro: dirección, puerto y protocolo, porque la corrección depende de cuál de los tres es incorrecto.

Reiniciar el servicio después de que aparezca el adaptador normalmente hará que el receptor tenga éxito, y esa es precisamente la trampa. Demuestra la dependencia en lugar de eliminarla, y corta a cada usuario conectado cada vez que el túnel se reconecta.

Lea el receptor tal como lo lee el motor

En SQL Server Configuration Manager, abra las propiedades TCP/IP de la instancia y fíjese en el ajuste Listen All antes de editar direcciones individuales. Cuando Listen All es Yes, los valores Enabled por dirección se ignoran, así que editarlos no cambia nada de lo que usa el receptor. Anote tres cosas en orden: la dirección que pretende servir, el puerto y si el receptor debe cubrir todas las direcciones o solo una. Después aplique el cambio mediante el procedimiento de reinicio admitido y lea el siguiente registro de inicio para confirmar que el motor enlazó lo que pidió.

Escuchar en todas las direcciones no es control de acceso. Si realmente se necesita un receptor amplio, cada interfaz accesible necesita su propia decisión de cortafuegos y autorización de base de datos, incluida cualquier interfaz que mire a internet.

Dé al cliente un destino estable

El cliente no necesita que el host de la base de datos lleve una dirección del grupo. Un diseño enrutado funciona con el servidor escuchando en su dirección privada estable mientras la puerta de enlace VPN reenvía el tráfico del cliente hacia él y devuelve la respuesta.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

Si el cliente llega a 10.80.0.15, la ruta está probada y la base de datos solo tiene que autorizar a ese cliente. Si no llega, corrija el enrutamiento y el DNS antes de tocar de nuevo el receptor, porque un problema de enlace en el servidor nunca fue la razón por la que un cliente no puede encontrarlo. Añadir una dirección de grupo falsa al servidor, o una segunda puerta de enlace predeterminada para contentar al receptor, crea un nuevo problema de red encima del anterior. Mantenga el direccionamiento del servidor estático y deje que el túnel lleve a los clientes hasta él.

Verifique el punto final que usó el cliente

Termine con una comprobación a nivel de aplicación en lugar de una prueba de puerto. Conéctese desde el cliente con la cuenta que usa la aplicación y lea los detalles de conexión del lado del servidor, que muestran la dirección local en la que aterrizó su sesión.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Compare esa dirección con el receptor que configuró. Una discrepancia significa un segundo receptor o un nombre que se resuelve en un lugar inesperado, y ambos merece la pena conocerlos antes de que el siguiente reinicio pruebe su corrección por usted. Después reinicie el host sin ningún usuario con sesión iniciada y confirme que el enlace se realiza. Esa única prueba es la diferencia entre un receptor reparado y una solución provisional que falla la próxima noche de parches.