SQL Server bind ’n VPN-adres wat nie by die opstart bestaan nie

Lees ’n SQL Server-logreël oor ’n mislukte binding terwyl die diens steeds loop, en jy het ’n opstartorde-afhanklikheid eerder as ’n ineenstorting gevind. Daardie kombinasie is die leidraad: die enjin het begin voordat die adres waarop dit moes luister, op die masjien bestaan het. ’n VPN-adapter wat eers ná aanmelding opkom, is ’n swak voorvereiste vir ’n onbewaakte databasisdiens, so volg die mislukking in die orde waarin die enjin dit sien.

Begin by die opstartlog, nie by die kliënt nie

Maak die instansie se foutlog oop en lees die inskrywings rondom die netwerkinitialisering, nie net die laaste reël nie. Die enjin rapporteer watter adresse dit probeer het en watter protokolle dit geaktiveer het, en daardie rekord is van voordat enige kliënt gekoppel het. Kyk nou na wat op die gasheer op die oomblik bestaan. As die koppelvlak wat die gekonfigureerde adres besit, eers verskyn nadat ’n gebruiker aangemeld en ’n kliënt begin het, was die adres by die opstart afwesig en is die bindingsfout heeltemal verduidelik.

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

Pas die instansiepad aan by jou installasie, en lees die koppelvlaklys voordat jy gevolgtrekkings maak. ’n Adres wat bestaan maar deur die verkeerde adapter besit word, is ’n ander probleem as ’n adres wat nog nie bestaan nie.

Volg die bindingsorde wat die enjin werklik volg

Die enjin lees sy luisteraarkonfigurasie en vra dan die bedryfstelsel om te bind. As die adres op daardie oomblik nie plaaslik is nie, misluk die binding vir daardie adres terwyl die res van die instansie normaal kan voortgaan. Dis waarom ander protokolle of ander adresse steeds kan werk, en waarom “SQL Server is af” die verkeerde opsomming is. Bewaar die presiese eindpunt uit die log: adres, poort en protokol, want die oplossing hang daarvan af watter van die drie verkeerd is.

Om die diens te herbegin nadat die adapter verskyn, laat die luisteraar gewoonlik slaag, en dit is juis die lokval. Dit bewys die afhanklikheid eerder as om dit te verwyder, en dit onderbreek elke gekoppelde gebruiker elke keer wanneer die tonnel weer koppel.

Lees die luisteraar soos die enjin dit lees

In SQL Server Configuration Manager, maak die instansie se TCP/IP-eienskappe oop en let op die Listen All-instelling voordat jy individuele adresse wysig. Wanneer Listen All op Yes staan, word die Enabled-waardes per adres geïgnoreer, so om hulle te wysig verander niks wat die luisteraar gebruik nie. Teken drie dinge in volgorde aan: die adres wat jy wil bedien, die poort, en of die luisteraar alle adresse of net een moet dek. Pas dan die verandering toe deur die ondersteunde herbeginprosedure en lees die volgende opstartlog om te bevestig dat die enjin gebind het wat jy gevra het.

Om op elke adres te luister is nie toegangsbeheer nie. As ’n breë luisteraar werklik nodig is, het elke bereikbare koppelvlak sy eie firewall- en databasismagtigingsbesluit nodig, insluitend enige koppelvlak wat na die internet wys.

Gee die kliënt ’n stabiele bestemming

Die kliënt het nie nodig dat die databasisgasheer ’n poeladres dra nie. ’n Geroteerde ontwerp werk met die bediener wat op sy stabiele private adres luister terwyl die VPN-gateway die kliënt se verkeer daarheen stuur en die antwoord terugdra.

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

As die kliënt 10.80.0.15 bereik, is die pad bewys en hoef die databasis net daardie kliënt te magtig. As dit nie gebeur nie, herstel roetering en DNS voordat jy weer aan die luisteraar raak, want ’n bindingsprobleem op die bediener was nooit die rede waarom ’n kliënt dit nie kan vind nie. Om ’n valse poeladres by die bediener te voeg, of ’n tweede verstekgateway om die luisteraar tevrede te stel, skep ’n nuwe netwerkprobleem bo-op die ou een. Hou die bediener se adressering staties en laat die tonnel kliënte daarheen bring.

Verifieer die eindpunt wat die kliënt gebruik het

Sluit af met ’n toepassingsvlakkontrole eerder as ’n poorttoets. Koppel vanaf die kliënt met die rekening wat die toepassing gebruik en lees die bedienerkant se verbindingsbesonderhede, wat die plaaslike adres wys waarop jou sessie beland het.

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"

Vergelyk daardie adres met die luisteraar wat jy gekonfigureer het. ’n Wanverhouding beteken ’n tweede luisteraar of ’n naam wat êrens onverwags opgelos word, en albei is die moeite werd om te weet voordat die volgende herlaai jou oplossing vir jou toets. Herbegin dan die gasheer met geen gebruiker aangemeld nie en bevestig dat die binding slaag. Daardie enkele toets is die verskil tussen ’n herstelde luisteraar en ’n tydelike oplossing wat op die volgende patchnag misluk.