SQL Server binder en VPN-adresse, der ikke findes ved opstart

Læs en SQL Server-loglinje om en mislykket binding, mens tjenesten stadig kører, og du har fundet en afhængighed af opstartsrækkefølgen frem for et nedbrud. Den kombination er ledetråden: motoren startede, før den adresse, den skulle lytte på, fandtes på maskinen. En VPN-adapter, der først kommer op efter login, er en dårlig forudsætning for en uovervåget databasetjeneste, så følg fejlen i den rækkefølge, motoren ser den.

Start ved opstartsloggen, ikke ved klienten

Åbn instansens fejllog, og læs indlæggene omkring netværksinitialiseringen, ikke kun den sidste linje. Motoren rapporterer, hvilke adresser den forsøgte, og hvilke protokoller den aktiverede, og den registrering er fra før nogen klient koblede til. Se nu på, hvad der findes på værten lige nu. Hvis det interface, der ejer den konfigurerede adresse, først dukker op, efter en bruger logger ind og starter en klient, var adressen fraværende ved opstart, og bindingsfejlen er fuldt forklaret.

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

Tilpas instansens sti til din installation, og læs interfacelisten, før du drager konklusioner. En adresse, der findes, men ejes af den forkerte adapter, er et andet problem end en adresse, der ikke findes endnu.

Følg den bindingsrækkefølge, motoren faktisk bruger

Motoren læser sin listenerkonfiguration og beder derefter styresystemet om at binde. Hvis adressen ikke er lokal på det tidspunkt, mislykkes bindingen for den adresse, mens resten af instansen kan fortsætte normalt. Derfor kan andre protokoller eller andre adresser stadig virke, og derfor er „SQL Server er nede“ det forkerte resumé. Bevar det præcise endpoint fra loggen: adresse, port og protokol, fordi rettelsen afhænger af, hvilken af de tre der er forkert.

At genstarte tjenesten, efter adapteren vises, vil normalt få listeneren til at lykkes, og det er netop fælden. Det beviser afhængigheden i stedet for at fjerne den, og det afbryder hver tilsluttet bruger, hver gang tunnelen genopretter forbindelsen.

Læs listeneren, som motoren læser den

I SQL Server Configuration Manager skal du åbne instansens TCP/IP-egenskaber og bemærke indstillingen Listen All, før du redigerer enkelte adresser. Når Listen All er Yes, ignoreres Enabled-værdierne pr. adresse, så det ændrer intet, som listeneren bruger. Noter tre ting i rækkefølge: den adresse, du vil betjene, porten, og om listeneren skal dække alle adresser eller kun én. Anvend derefter ændringen via den understøttede genstartsprocedure, og læs den næste opstartslog for at bekræfte, at motoren bandt det, du bad om.

At lytte på hver adresse er ikke adgangskontrol. Hvis en bred listener virkelig er nødvendig, har hvert tilgængeligt interface brug for sin egen firewall- og databaseautorisationsbeslutning, inklusive ethvert interface, der vender mod internettet.

Giv klienten en stabil destination

Klienten har ikke brug for, at databaseværten bærer en pooladresse. Et routet design fungerer med serveren lyttende på sin stabile private adresse, mens VPN-gatewayen videresender klientens trafik til den og bærer svaret tilbage.

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

Hvis klienten når 10.80.0.15, er stien bevist, og databasen skal blot autorisere den klient. Hvis ikke, skal du rette routing og DNS, før du rører listeneren igen, fordi et bindingsproblem på serveren aldrig var årsagen til, at en klient ikke kan finde den. At tilføje en falsk pooladresse til serveren eller en ekstra standardgateway for at gøre listeneren tilfreds skaber et nyt netværksproblem oven på det gamle. Hold serverens adressering statisk, og lad tunnelen føre klienterne til den.

Bekræft det endpoint, klienten brugte

Afslut med et programniveau-tjek i stedet for en porttest. Forbind fra klienten med den konto, applikationen bruger, og læs forbindelsesdetaljerne på serversiden, som viser den lokale adresse, din session landede 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"

Sammenlign den adresse med den listener, du konfigurerede. En uoverensstemmelse betyder en ekstra listener eller et navn, der opløses et uventet sted, og begge er værd at kende, før den næste genstart tester din rettelse for dig. Genstart derefter værten uden nogen bruger logget ind, og bekræft, at bindingen lykkes. Den ene test er forskellen mellem en repareret listener og en omvej, der fejler på den næste patchnat.