SQL Server se veže na naslov VPN, ki ga ob zagonu ni

Preberite vrstico v dnevniku SQL Serverja o neuspešni vezavi, medtem ko storitev še teče, in našli ste odvisnost od vrstnega reda zagona, ne sesutja. Prav ta kombinacija je namig: motor se je zagnal, preden je na stroju obstajal naslov, na katerem naj bi poslušal. VPN vmesnik, ki se pojavi šele po prijavi, je slaba predpostavka za podatkovno bazo brez nadzora, zato sledite napaki v vrstnem redu, v katerem jo vidi motor.

Začnite pri zagonskem dnevniku, ne pri odjemalcu

Odprite dnevnik napak primerka in preberite vnose okoli inicializacije omrežja, ne le zadnje vrstice. Motor poroča, katere naslove je poskusil in katere protokole je omogočil, in ta zapis je iz časa, preden se je povezal kateri koli odjemalec. Zdaj poglejte, kaj na gostitelju obstaja prav zdaj. Če se vmesnik, ki ima konfigurirani naslov, pojavi šele potem, ko se uporabnik prijavi in zažene odjemalca, naslova ob zagonu ni bilo in napaka vezave je popolnoma pojasnjena.

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

Prilagodite pot primerka svoji namestitvi in preberite seznam vmesnikov, preden sklepate. Naslov, ki obstaja, a pripada napačnemu vmesniku, je druga težava kot naslov, ki ga še ni.

Pojdite skozi vrstni red vezave, ki se ga motor dejansko drži

Motor prebere konfiguracijo poslušalca in nato zahteva od operacijskega sistema, da veže. Če naslov v tistem trenutku ni lokalen, vezava za ta naslov ne uspe, medtem ko lahko preostanek primerka nadaljuje normalno. Zato lahko drugi protokoli ali drugi naslovi še vedno delujejo in zato je „SQL Server je padel“ napačen povzetek. Ohranite točno končno točko iz dnevnika: naslov, vrata in protokol, ker je popravek odvisen od tega, katera od treh je napačna.

Ponovni zagon storitve po pojavu vmesnika bo običajno poskrbel, da bo poslušalec uspešen, in prav to je past. Dokazuje odvisnost, namesto da bi jo odstranil, in prekine vsakega povezanega uporabnika vsakič, ko se tunel znova poveže.

Berite poslušalca tako, kot ga bere motor

V SQL Server Configuration Manager odprite lastnosti TCP/IP primerka in pred urejanjem posameznih naslovov upoštevajte nastavitev Listen All. Ko je Listen All nastavljen na Yes, se vrednosti Enabled za posamezne naslove ignorirajo, zato njihovo urejanje ne spremeni ničesar, kar uporablja poslušalec. Zapišite tri stvari po vrsti: naslov, ki ga nameravate streči, vrata in ali naj poslušalec pokriva vse naslove ali samo enega. Nato spremembo uporabite s podprtim postopkom ponovnega zagona in preberite naslednji zagonski dnevnik, da potrdite, da je motor vezal, kar ste zahtevali.

Poslušanje na vseh naslovih ni nadzor dostopa. Če je širok poslušalec res potreben, potrebuje vsak dosegljiv vmesnik svojo odločitev o požarnem zidu in avtorizaciji podatkovne baze, vključno z vsakim vmesnikom, obrnjenim v internet.

Dajte odjemalcu stabilno ciljno točko

Odjemalec ne potrebuje, da bi gostitelj podatkovne baze nosil naslov iz zbirke. Usmerjena zasnova deluje tako, da strežnik posluša na svojem stabilnem zasebnem naslovu, medtem ko VPN prehod posreduje promet odjemalca k njemu in prinese odgovor nazaj.

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

Če odjemalec doseže 10.80.0.15, je pot dokazana in podatkovna baza mora le avtorizirati tega odjemalca. Če ne, popravite usmerjanje in DNS, preden se znova dotaknete poslušalca, ker težava z vezavo na strežniku nikoli ni bila razlog, da ga odjemalec ne more najti. Dodajanje lažnega naslova iz zbirke strežniku ali drugega privzetega prehoda, da bi zadovoljili poslušalca, ustvari novo omrežno težavo na stari. Ohranite naslavljanje strežnika statično in pustite tunelu, da pripelje odjemalce k njemu.

Preverite končno točko, ki jo je uporabil odjemalec

Zaključite s preverjanjem na ravni aplikacije, ne s preskusom vrat. Povežite se z odjemalca z računom, ki ga uporablja aplikacija, in preberite podrobnosti povezave na strani strežnika, ki prikazujejo lokalni naslov, na katerega je pristala vaša seja.

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"

Primerjajte ta naslov s poslušalcem, ki ste ga konfigurirali. Neskladje pomeni drugi poslušalec ali ime, ki se razrešuje nekje nepričakovano, in oboje je vredno vedeti, preden naslednji ponovni zagon preizkusi vaš popravek namesto vas. Nato znova zaženite gostitelja brez prijavljenega uporabnika in potrdite, da vezava uspe. Ta en sam preskus je razlika med popravljenim poslušalcem in obhodno rešitvijo, ki odpove naslednjo noč popravkov.