SQL Server bind ein VPN-adresse som ikkje finst ved oppstart

Les ei SQL Server-logglinje om ei mislukka binding medan tenesta framleis køyrer, og du har funne ein avhengnad av oppstartsrekkjefølgja, ikkje ein krasj. Den kombinasjonen er leietråden: motoren starta før adressa han skulle lytta på fanst på maskina. Ein VPN-adapter som først kjem opp etter pålogging er eit dårleg føresetnad for ei uovervaka databaseteneste, så følg feilen i den rekkjefølgja motoren ser han.

Start ved oppstartsloggen, ikkje ved klienten

Opne feilloggen til instansen og les oppføringane rundt nettverksinitialiseringa, ikkje berre den siste linja. Motoren rapporterer kva adresser han prøvde og kva protokollar han slo på, og den registreringa er frå før nokon klient kopla til. Sjå no på kva som finst på verten akkurat no. Viss grensesnittet som eig den konfigurerte adressa først dukkar opp etter at ein brukar loggar på og startar ein klient, mangla adressa 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 banen til instansen til installasjonen din, og les grensesnittlista før du dreg konklusjonar. Ei adresse som finst, men som vert eigd av feil adapter, er eit anna problem enn ei adresse som ikkje finst enno.

Gå gjennom bindingsrekkjefølgja motoren faktisk følgjer

Motoren les lyttarkonfigurasjonen sin og ber deretter operativsystemet om å binda. Viss adressa ikkje er lokal i det augneblinken, mislukkast bindinga for den adressa, medan resten av instansen kan halda fram normalt. Derfor kan andre protokollar eller andre adresser framleis verka, og derfor er „SQL Server er nede“ det feil samandraget. Ta vare på det nøyaktige endepunktet frå loggen: adresse, port og protokoll, fordi rettinga er avhengig av kva av dei tre som er feil.

Å starta tenesta på nytt etter at adapteren dukkar opp, vil vanlegvis gjera lyttaren vellukka, og det er nettopp fella. Det beviser avhengnaden i staden for å fjerna han, og det bryt kvar tilkopla brukar kvar gong tunnelen koplar til på nytt.

Les lyttaren slik motoren les han

I SQL Server Configuration Manager, opne TCP/IP-eigenskapane til instansen og legg merke til innstillinga Listen All før du redigerer enkeltadresser. Når Listen All er Yes, vert Enabled-verdiane per adresse ignorerte, så det endrar ingenting som lyttaren brukar. Noter tre ting i rekkjefølgje: adressa du har tenkt å tena, porten, og om lyttaren skal dekkja alle adresser eller berre éi. Bruk deretter endringa gjennom den støtta omstartprosedyren og les den neste oppstartsloggen for å stadfesta at motoren batt det du bad om.

Å lytta på kvar adresse er ikkje tilgangskontroll. Viss ein brei lyttar verkeleg er nødvendig, treng kvart tilgjengeleg grensesnitt si eiga avgjerd om brannmur og databaseautorisasjon, inkludert kvart grensesnitt som vender mot internett.

Gje klienten ein stabil destinasjon

Klienten treng ikkje at databaseverten ber ei pooladresse. Eit ruta design verkar med serveren som lyttar på si stabile private adresse, medan VPN-gatewayen videresender trafikken til klienten til han og ber svaret tilbake.

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

Viss klienten når 10.80.0.15, er banen bevist, og databasen treng berre å autorisera den klienten. Viss ikkje, rett opp ruting og DNS før du rører lyttaren igjen, fordi eit bindingsproblem på serveren var aldri grunnen til at ein klient ikkje finn han. Å leggja til ei falsk pooladresse på serveren, eller ein ekstra standard gateway for å gjera lyttaren nøgd, skapar eit nytt nettverksproblem oppå det gamle. Hald adresseringa til serveren statisk og lat tunnelen føra klientane til han.

Stadfest endepunktet klienten brukte

Avslutt med ein kontroll på applikasjonsnivå i staden for ein porttest. Kople til frå klienten med kontoen applikasjonen brukar, og les tilkoplingsdetaljane på serversida, som viser den lokale adressa økta di landa 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"

Samanlikn den adressa med lyttaren du konfigurerte. Eit avvik tyder på ein ekstra lyttar eller eit namn som vert løyst opp ein uventa stad, og begge er verd å vita før den neste omstarten testar rettinga di for deg. Start deretter verten på nytt utan nokon pålogga brukar og stadfest at bindinga lukkast. Den eine testen er skilnaden mellom ein reparert lyttar og ein omveg som feilar på den neste patchnatta.