SQL Server enlaza unha dirección VPN que non existe ao arrincar

Lea unha liña do rexistro de SQL Server sobre un enlace fallido mentres o servizo aínda se executa, e atopou unha dependencia da orde de arrinque, non un fallo. Esa combinación é a pista: o motor arrincou antes de que existise na máquina a dirección na que se lle dixo que escoitase. Un adaptador VPN que aparece despois do inicio de sesión é un mal requisito previo para un servizo de base de datos sen supervisión, así que percorra o fallo na orde en que o ve o motor.

Comece polo rexistro de inicio, non polo cliente

Abra o rexistro de erros da instancia e lea as entradas arredor da inicialización da rede, non só a última liña. O motor informa que direccións intentou e que protocolos habilitou, e ese rexistro é de antes de que se conectase calquera cliente. Agora mire que existe no host neste momento. Se a interface que posúe a dirección configurada só aparece despois de que un usuario inicie sesión e arranque un cliente, a dirección faltaba ao arrincar e o 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

Axuste a ruta da instancia á súa instalación e lea a lista de interfaces antes de sacar conclusións. Unha dirección que existe pero pertence ao adaptador equivocado é un problema distinto dunha dirección que aínda non existe.

Percorra a orde de enlace que o motor segue realmente

O motor le a súa configuración de receptor e despois pide ao sistema operativo que enlace. Se a dirección non é local nese momento, o enlace falla para esa dirección mentres o resto da instancia pode continuar con normalidade. Por iso outros protocolos ou outras direccións aínda poden funcionar, e por iso «SQL Server está caído» é o resumo equivocado. Conserve o punto final exacto do rexistro: dirección, porto e protocolo, porque a corrección depende de cal dos tres é incorrecto.

Reiniciar o servizo despois de que apareza o adaptador normalmente fará que o receptor teña éxito, e esa é precisamente a trampa. Demostra a dependencia en lugar de eliminarla, e corta a cada usuario conectado cada vez que o túnel se reconecta.

Lea o receptor tal como o le o motor

En SQL Server Configuration Manager, abra as propiedades TCP/IP da instancia e fíxese no axuste Listen All antes de editar direccións individuais. Cando Listen All é Yes, os valores Enabled por dirección ignóranse, así que editalos non cambia nada do que usa o receptor. Anote tres cousas por orde: a dirección que pretende servir, o porto e se o receptor debe cubrir todas as direccións ou só unha. Despois aplique o cambio mediante o procedemento de reinicio admitido e lea o seguinte rexistro de inicio para confirmar que o motor enlazou o que pediu.

Escoitar en todas as direccións non é control de acceso. Se realmente se necesita un receptor amplo, cada interface accesible necesita a súa propia decisión de devasas e autorización de base de datos, incluída calquera interface que mire a internet.

Dea ao cliente un destino estable

O cliente non necesita que o host da base de datos leve unha dirección do grupo. Un deseño encamiñado funciona co servidor escoitando na súa dirección privada estable mentres a pasarela VPN reenvía o tráfico do cliente cara a el e devolve a resposta.

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

Se o cliente chega a 10.80.0.15, a ruta está probada e a base de datos só ten que autorizar a ese cliente. Se non chega, corrixa o encamiñamento e o DNS antes de tocar de novo o receptor, porque un problema de enlace no servidor nunca foi a razón pola que un cliente non o pode atopar. Engadir unha dirección de grupo falsa ao servidor, ou unha segunda pasarela predeterminada para contentar o receptor, crea un novo problema de rede por riba do anterior. Mantéñase o direccionamento do servidor estático e deixe que o túnel leve os clientes ata el.

Verifique o punto final que usou o cliente

Remate cunha comprobación a nivel de aplicación en lugar dunha proba de porto. Conéctese desde o cliente coa conta que usa a aplicación e lea os detalles de conexión do lado do servidor, que mostran a dirección local na que aterrou a súa 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 co receptor que configurou. Unha discrepancia significa un segundo receptor ou un nome que se resolve nun lugar inesperado, e ambos paga a pena coñecelos antes de que o seguinte reinicio proba a súa corrección por vostede. Despois reinicie o host sen ningún usuario con sesión iniciada e confirme que o enlace se realiza. Esa única proba é a diferenza entre un receptor reparado e unha solución provisional que falla a próxima noite de parches.