SQL Server binder en VPN-adress som inte finns vid start

Läs en rad i SQL Server-loggen om ett misslyckat bindningsförsök medan tjänsten fortfarande körs, och du har hittat ett beroende av startordningen, inte en krasch. Just den kombinationen är ledtråden: motorn startade innan adressen den skulle lyssna på fanns på maskinen. En VPN-adapter som kommer upp först efter inloggning är en dålig förutsättning för en oövervakad databastjänst, så följ felet i den ordning motorn ser det.

Börja i startloggen, inte hos klienten

Öppna instansens fellogg och läs posterna kring nätverksinitieringen, inte bara sista raden. Motorn rapporterar vilka adresser den försökte och vilka protokoll den aktiverade, och den posten är från innan någon klient anslöt. Titta nu på vad som finns på värden just nu. Om gränssnittet som äger den konfigurerade adressen dyker upp först efter att en användare loggat in och startat en klient, saknades adressen vid start och bindningsfelet är fullt förklarat.

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

Anpassa instansens sökväg till din installation och läs gränssnittslistan innan du drar slutsatser. En adress som finns men ägs av fel adapter är ett annat problem än en adress som ännu inte finns.

Gå igenom den bindningsordning som motorn faktiskt följer

Motorn läser sin lyssnarkonfiguration och ber sedan operativsystemet att binda. Om adressen inte är lokal i det ögonblicket misslyckas bindningen för den adressen, medan resten av instansen kan fortsätta normalt. Det är därför andra protokoll eller andra adresser fortfarande kan fungera, och det är därför „SQL Server är nere“ är den felaktiga sammanfattningen. Bevara den exakta slutpunkten från loggen: adress, port och protokoll, eftersom åtgärden beror på vilken av de tre som är fel.

Att starta om tjänsten efter att adaptern dyker upp får vanligtvis lyssnaren att lyckas, och det är precis fällan. Det bevisar beroendet i stället för att ta bort det, och det bryter varje ansluten användare varje gång tunneln återansluter.

Läs lyssnaren så som motorn läser den

I SQL Server Configuration Manager, öppna instansens TCP/IP-egenskaper och notera inställningen Listen All innan du redigerar enskilda adresser. När Listen All är Yes ignoreras Enabled-värdena per adress, så att redigera dem ändrar ingenting som lyssnaren använder. Notera tre saker i ordning: adressen du tänker betjäna, porten och om lyssnaren ska täcka alla adresser eller bara en. Tillämpa sedan ändringen via den stödda omstartsproceduren och läs nästa startlogg för att bekräfta att motorn band det du bad om.

Att lyssna på varje adress är inte åtkomstkontroll. Om en bred lyssnare verkligen behövs behöver varje nåbart gränssnitt sitt eget beslut om brandvägg och databasbehörighet, inklusive varje gränssnitt som vetter mot internet.

Ge klienten en stabil destination

Klienten behöver inte att databasvärden bär en pooldress. En routad design fungerar med servern lyssnande på sin stabila privata adress medan VPN-gatewayen vidarebefordrar klientens trafik till den och bär svaret tillbaka.

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

Om klienten når 10.80.0.15 är vägen bevisad och databasen behöver bara auktorisera den klienten. Om inte, rätta routning och DNS innan du rör lyssnaren igen, eftersom ett bindningsproblem på servern aldrig var anledningen till att en klient inte kan hitta den. Att lägga till en falsk pooldress på servern, eller en extra standardgateway för att göra lyssnaren nöjd, skapar ett nytt nätverksproblem ovanpå det gamla. Håll serverns adressering statisk och låt tunneln föra klienterna till den.

Verifiera slutpunkten som klienten använde

Avsluta med en kontroll på applikationsnivå i stället för ett porttest. Anslut från klienten med kontot som applikationen använder och läs anslutningsdetaljerna på serversidan, som visar den lokala adressen som din session landade på.

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"

Jämför den adressen med lyssnaren du konfigurerade. En avvikelse betyder en andra lyssnare eller ett namn som löses upp någonstans oväntat, och båda är värda att känna till innan nästa omstart testar din åtgärd åt dig. Starta sedan om värden utan någon inloggad användare och bekräfta att bindningen lyckas. Det enda testet är skillnaden mellan en reparerad lyssnare och en kringgående lösning som misslyckas nästa patchnatt.