SQL Server enllaça una adreça VPN que no hi és en l’arrencada

Llegiu una línia del registre de SQL Server sobre un enllaç fallit mentre el servei encara funciona i haureu trobat una dependència de l’ordre d’arrencada, no una fallada. Aquesta combinació és la pista: el motor va arrencar abans que l’adreça on se li havia dit que escoltés existís a la màquina. Un adaptador VPN que apareix després de l’inici de sessió és un mal requisit previ per a un servei de base de dades sense supervisió, així que recorreu la fallada en l’ordre en què la veu el motor.

Comenceu pel registre d’inici, no pel client

Obriu el registre d’errors de la instància i llegiu les entrades al voltant de la inicialització de la xarxa, no només l’última línia. El motor informa quines adreces va provar i quins protocols va habilitar, i aquest registre és d’abans que es connectés cap client. Ara mireu què existeix a l’amfitrió en aquest moment. Si la interfície que posseeix l’adreça configurada només apareix després que un usuari iniciï sessió i engegui un client, l’adreça era absent a l’arrencada i la fallada d’enllaç queda del tot 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

Ajusteu el camí de la instància a la vostra instal·lació i llegiu la llista d’interfícies abans de treure conclusions. Una adreça que existeix però pertany a l’adaptador equivocat és un problema diferent d’una adreça que encara no existeix.

Recorreu l’ordre d’enllaç que el motor segueix realment

El motor llegeix la configuració del receptor i després demana al sistema operatiu que enllaci. Si l’adreça no és local en aquell moment, l’enllaç falla per a aquesta adreça mentre la resta de la instància pot continuar amb normalitat. Per això altres protocols o altres adreces encara poden funcionar, i per això «SQL Server està caigut» és un resum equivocat. Conserveu el punt de connexió exacte del registre: adreça, port i protocol, perquè la solució depèn de quin dels tres és incorrecte.

Reiniciar el servei després que aparegui l’adaptador normalment farà que el receptor tingui èxit, i aquest és precisament el parany. Demostra la dependència en lloc d’eliminar-la, i trenca cada usuari connectat cada cop que el túnel es torna a connectar.

Llegiu el receptor tal com el llegeix el motor

A SQL Server Configuration Manager, obriu les propietats TCP/IP de la instància i fixeu-vos en el paràmetre Listen All abans d’editar adreces individuals. Quan Listen All és Yes, els valors Enabled per adreça s’ignoren, així que editar-los no canvia res del que fa servir el receptor. Anoteu tres coses per ordre: l’adreça que voleu servir, el port i si el receptor ha de cobrir totes les adreces o només una. Després apliqueu el canvi mitjançant el procediment de reinici suportat i llegiu el següent registre d’inici per confirmar que el motor ha enllaçat el que heu demanat.

Escoltar a totes les adreces no és control d’accés. Si un receptor ampli és realment necessari, cada interfície accessible necessita la seva pròpia decisió de tallafocs i autorització de base de dades, incloent-hi qualsevol interfície que miri a internet.

Doneu al client una destinació estable

El client no necessita que l’amfitrió de la base de dades porti una adreça de l’pool. Un disseny encaminat funciona amb el servidor escoltant a la seva adreça privada estable mentre la passarel·la VPN reenvia el trànsit del client cap a ell i porta la resposta de tornada.

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

Si el client arriba a 10.80.0.15, el camí queda demostrat i la base de dades només ha d’autoritzar aquell client. Si no hi arriba, arregleu l’encaminament i el DNS abans de tornar a tocar el receptor, perquè un problema d’enllaç al servidor mai no va ser el motiu que un client no el trobi. Afegir una adreça de l’pool falsa al servidor, o una segona passarel·la predeterminada per fer feliç el receptor, crea un problema de xarxa nou a sobre de l’antic. Manteniu l’adreçament del servidor estàtic i deixeu que el túnel porti els clients cap a ell.

Verifiqueu el punt de connexió que va fer servir el client

Acabeu amb una comprovació a nivell d’aplicació en lloc d’una prova de port. Connecteu-vos des del client amb el compte que fa servir l’aplicació i llegiu els detalls de connexió del costat del servidor, que mostren l’adreça local on ha aterrat la vostra sessió.

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"

Compareu aquesta adreça amb el receptor que heu configurat. Una discrepància significa un segon receptor o un nom que es resol en un lloc inesperat, i tots dos val la pena saber-los abans que el proper reinici provi la vostra solució per vosaltres. Després reinicieu l’amfitrió sense cap usuari amb la sessió iniciada i confirmeu que l’enllaç té èxit. Aquesta única prova és la diferència entre un receptor reparat i una solució provisional que falla la propera nit de pedaços.