O SQL Server associa a um endereço VPN que não existe no arranque

Leia uma linha do registo do SQL Server sobre uma associação falhada enquanto o serviço ainda está a correr, e encontrou uma dependência da ordem de arranque, não um crash. É essa combinação a pista: o motor arrancou antes de o endereço onde devia escutar existir na máquina. Um adaptador VPN que surge depois do início de sessão é um mau pré-requisito para um serviço de base de dados sem supervisão, por isso percorra a falha na ordem em que o motor a vê.

Comece pelo registo de arranque, não pelo cliente

Abra o registo de erros da instância e leia as entradas em torno da inicialização da rede, não apenas a última linha. O motor relata que endereços tentou e que protocolos ativou, e esse registo é de antes de qualquer cliente se ligar. Agora veja o que existe no anfitrião neste momento. Se a interface que possui o endereço configurado só aparecer depois de o utilizador iniciar sessão e arrancar um cliente, o endereço estava ausente no arranque e a falha de associação fica totalmente explicada.

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 o caminho da instância à sua instalação e leia a lista de interfaces antes de tirar conclusões. Um endereço que existe mas pertence ao adaptador errado é um problema diferente de um endereço que ainda não existe.

Percorra a ordem de associação que o motor realmente segue

O motor lê a configuração do listener e depois pede ao sistema operativo para associar. Se o endereço não for local nesse momento, a associação falha para esse endereço enquanto o resto da instância pode continuar normalmente. É por isso que outros protocolos ou outros endereços ainda podem funcionar, e é por isso que «o SQL Server está em baixo» é o resumo errado. Guarde o endpoint exato do registo: endereço, porta e protocolo, porque a correção depende de qual dos três está errado.

Reiniciar o serviço depois de o adaptador aparecer fará normalmente o listener ter sucesso, e é exatamente essa a armadilha. Prova a dependência em vez de a remover, e corta cada utilizador ligado sempre que o túnel se volta a ligar.

Leia o listener como o motor o lê

No SQL Server Configuration Manager, abra as propriedades TCP/IP da instância e repare na definição Listen All antes de editar endereços individuais. Quando Listen All está em Yes, os valores Enabled por endereço são ignorados, por isso editá-los não altera nada do que o listener usa. Registe três coisas por ordem: o endereço que pretende servir, a porta e se o listener deve cobrir todos os endereços ou apenas um. Depois aplique a alteração através do procedimento de reinício suportado e leia o registo de arranque seguinte para confirmar que o motor associou o que pediu.

Escutar em todos os endereços não é controlo de acesso. Se um listener amplo for realmente necessário, cada interface alcançável precisa da sua própria decisão de firewall e autorização de base de dados, incluindo qualquer interface virada para a internet.

Dê ao cliente um destino estável

O cliente não precisa que o anfitrião da base de dados use um endereço do pool. Um desenho encaminhado funciona com o servidor a escutar no seu endereço privado estável enquanto o gateway VPN encaminha o tráfego do cliente para ele e traz a resposta de volta.

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

Se o cliente chegar a 10.80.0.15, o caminho está provado e a base de dados só tem de autorizar esse cliente. Se não chegar, corrija o encaminhamento e o DNS antes de voltar a tocar no listener, porque um problema de associação no servidor nunca foi a razão pela qual um cliente não o encontra. Acrescentar um endereço de pool falso ao servidor, ou um segundo gateway predefinido para agradar ao listener, cria um novo problema de rede por cima do antigo. Mantenha o endereçamento do servidor estático e deixe o túnel levar os clientes até ele.

Verifique o endpoint que o cliente usou

Termine com uma verificação ao nível da aplicação em vez de um teste de porta. Ligue-se a partir do cliente com a conta que a aplicação usa e leia os detalhes da ligação do lado do servidor, que mostram o endereço local onde a sua sessão aterrou.

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 esse endereço com o listener que configurou. Uma divergência significa um segundo listener ou um nome resolvido num local inesperado, e ambos vale a pena conhecer antes de o próximo reinício testar a sua correção por si. Depois reinicie o anfitrião sem nenhum utilizador com sessão iniciada e confirme que a associação tem sucesso. Esse único teste é a diferença entre um listener reparado e uma solução provisória que falha na próxima noite de patches.