SQL Server binder en VPN-adresse som ikke finnes ved oppstart

Les en SQL Server-logglinje om en mislykket binding mens tjenesten fortsatt kjører, og du har funnet en avhengighet av oppstartsrekkefølgen, ikke en krasj. Den kombinasjonen er ledetråden: motoren startet før adressen den skulle lytte på fantes på maskinen. En VPN-adapter som først kommer opp etter pålogging er en dårlig forutsetning for en uovervåket databasetjeneste, så følg feilen i den rekkefølgen motoren ser den.

Start ved oppstartsloggen, ikke ved klienten

Åpne feilloggen til instansen og les oppføringene rundt nettverksinitialiseringen, ikke bare den siste linjen. Motoren rapporterer hvilke adresser den forsøkte og hvilke protokoller den aktiverte, og den registreringen er fra før noen klient koblet til. Se nå på hva som finnes på verten akkurat nå. Hvis grensesnittet som eier den konfigurerte adressen, først dukker opp etter at en bruker logger på og starter en klient, manglet adressen ved oppstart, og bindingsfeilen er fullt forklart.

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

Tilpass instansens bane til installasjonen din, og les grensesnittlisten før du trekker konklusjoner. En adresse som finnes, men eies av feil adapter, er et annet problem enn en adresse som ikke finnes ennå.

Gå gjennom bindingsrekkefølgen motoren faktisk følger

Motoren leser listener-konfigurasjonen sin og ber deretter operativsystemet om å binde. Hvis adressen ikke er lokal i det øyeblikket, mislykkes bindingen for den adressen, mens resten av instansen kan fortsette normalt. Derfor kan andre protokoller eller andre adresser fortsatt virke, og derfor er „SQL Server er nede“ det feil sammendraget. Bevar det nøyaktige endepunktet fra loggen: adresse, port og protokoll, fordi rettelsen avhenger av hvilken av de tre som er feil.

Å starte tjenesten på nytt etter at adapteren dukker opp, vil vanligvis gjøre listeneren vellykket, og det er nettopp fellen. Det beviser avhengigheten i stedet for å fjerne den, og det bryter hver tilkoblet bruker hver gang tunnelen kobler til på nytt.

Les listeneren slik motoren leser den

I SQL Server Configuration Manager, åpne TCP/IP-egenskapene til instansen og legg merke til innstillingen Listen All før du redigerer enkeltadresser. Når Listen All er Yes, ignoreres Enabled-verdiene per adresse, så det endrer ingenting som listeneren bruker. Noter tre ting i rekkefølge: adressen du har tenkt å betjene, porten, og om listeneren skal dekke alle adresser eller bare én. Bruk deretter endringen gjennom den støttede omstartprosedyren og les den neste oppstartsloggen for å bekrefte at motoren bandt det du ba om.

Å lytte på hver adresse er ikke tilgangskontroll. Hvis en bred listener virkelig er nødvendig, trenger hvert tilgjengelige grensesnitt sin egen beslutning om brannmur og databaseautorisasjon, inkludert ethvert grensesnitt som vender mot internett.

Gi klienten en stabil destinasjon

Klienten trenger ikke at databaseverten bærer en pooladresse. Et rutet design fungerer med serveren som lytter på sin stabile private adresse, mens VPN-gatewayen videresender klientens trafikk til den og bærer svaret tilbake.

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

Hvis klienten når 10.80.0.15, er banen bevist, og databasen trenger bare å autorisere den klienten. Hvis ikke, rett opp ruting og DNS før du rører listeneren igjen, fordi et bindingsproblem på serveren aldri var grunnen til at en klient ikke finner den. Å legge til en falsk pooladresse på serveren, eller en ekstra standard gateway for å gjøre listeneren fornøyd, skaper et nytt nettverksproblem oppå det gamle. Hold serverens adressering statisk og la tunnelen føre klientene til den.

Bekreft endepunktet klienten brukte

Avslutt med en kontroll på applikasjonsnivå i stedet for en porttest. Koble til fra klienten med kontoen applikasjonen bruker, og les tilkoblingsdetaljene på serversiden, som viser den lokale adressen økten din landet 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 adressen med listeneren du konfigurerte. Et avvik betyr en ekstra listener eller et navn som løses opp et uventet sted, og begge er verdt å vite før den neste omstarten tester rettelsen din for deg. Start deretter verten på nytt uten noen pålogget bruker og bekreft at bindingen lykkes. Den ene testen er forskjellen mellom en reparert listener og en omvei som feiler på den neste patchnatten.