SQL Server veže VPN adresu koje nema pri podizanju sistema

Pročitajte red u dnevniku SQL Servera o neuspješnom vezivanju dok servis još radi i otkrit ćete zavisnost od redoslijeda podizanja, a ne pad. Ta kombinacija je trag: mehanizam je startao prije nego što je adresa na kojoj mu je rečeno da sluša postojala na mašini. VPN adapter koji se pojavi nakon prijave loš je preduslov za bazom podataka bez nadzora, zato pratite kvar redom kojim ga mehanizam vidi.

Počnite od dnevnika pokretanja, ne od klijenta

Otvorite dnevnik grešaka instance i pročitajte unose oko inicijalizacije mreže, ne samo posljednji red. Mehanizam navodi koje je adrese pokušao i koje je protokole omogućio, a taj zapis je od prije nego što se povezao ijedan klijent. Sada pogledajte šta postoji na hostu upravo sada. Ako se interfejs koji posjeduje konfigurisanu adresu pojavljuje tek nakon što se korisnik prijavi i pokrene klijent, adresa je nedostajala pri podizanju i neuspjeh vezivanja je potpuno objašnjen.

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 putanju instance svojoj instalaciji i pročitajte listu interfejsa prije zaključivanja. Adresa koja postoji ali pripada pogrešnom adapteru drugi je problem od adrese koje još nema.

Prođite redoslijed vezivanja koji mehanizam zaista slijedi

Mehanizam pročita konfiguraciju slušača, a zatim zatraži od operativnog sistema da veže. Ako adresa u tom trenutku nije lokalna, vezivanje za tu adresu ne uspijeva dok ostatak instance može nastaviti normalno. Zato drugi protokoli ili druge adrese i dalje mogu raditi i zato je „SQL Server je pao“ pogrešan sažetak. Sačuvajte tačnu krajnju tačku iz dnevnika: adresu, port i protokol, jer popravka zavisi od toga šta je od to troje pogrešno.

Ponovno pokretanje servisa nakon pojave adaptera obično će učiniti da slušač uspije, i to je upravo zamka. To dokazuje zavisnost umjesto da je ukloni i prekida svakog povezanog korisnika svaki put kada se tunel ponovo poveže.

Čitajte slušač onako kako ga čita mehanizam

U SQL Server Configuration Manageru otvorite svojstva TCP/IP instance i zabilježite postavku Listen All prije uređivanja pojedinačnih adresa. Kada je Listen All postavljen na Yes, vrijednosti Enabled po adresama se ignorišu, pa njihovo uređivanje ne mijenja ništa što slušač koristi. Zabilježite tri stvari po redu: adresu koju namjeravate opsluživati, port i da li slušač treba pokrivati sve adrese ili samo jednu. Zatim primijenite promjenu kroz podržani postupak ponovnog pokretanja i pročitajte sljedeći dnevnik pokretanja da potvrdite da je mehanizam vezao ono što ste tražili.

Slušanje na svakoj adresi nije kontrola pristupa. Ako je široki slušač zaista potreban, svaki dostupni interfejs treba vlastitu odluku o firewallu i autorizaciji baze podataka, uključujući svaki interfejs okrenut internetu.

Dajte klijentu stabilno odredište

Klijentu ne treba da host baze podataka nosi adresu iz pula. Rutirano rješenje radi dok server sluša na svojoj stabilnoj privatnoj adresi, a VPN gateway prosljeđuje promet klijenta do njega i vraća odgovor nazad.

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

Ako klijent dosegne 10.80.0.15, putanja je dokazana i baza podataka samo treba autorizirati tog klijenta. Ako ne dosegne, popravite rutiranje i DNS prije nego ponovo dirate slušač, jer problem vezivanja na serveru nikada nije bio razlog zašto ga klijent ne može naći. Dodavanje lažne adrese iz pula serveru, ili drugog podrazumijevanog gatewaya da bi slušač bio zadovoljan, stvara novi mrežni problem povrh starog. Držite adresiranje servera statičnim i pustite tunel da dovodi klijente do njega.

Provjerite krajnju tačku koju je klijent koristio

Završite provjerom na nivou aplikacije, a ne testom porta. Povežite se s klijenta računom koji aplikacija koristi i pročitajte detalje veze na strani servera, koji pokazuju lokalnu adresu na koju je vaša sesija sletjela.

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"

Uporedite tu adresu sa slušačem koji ste konfigurisali. Neslaganje znači drugi slušač ili ime koje se razrješava negdje neočekivano, a oboje je vrijedno znati prije nego sljedeće ponovno pokretanje testira vašu popravku umjesto vas. Zatim ponovo pokrenite host bez prijavljenog korisnika i potvrdite da vezivanje uspijeva. Taj jedini test razlika je između popravljenog slušača i zaobilaznog rješenja koje pada sljedeće noći zakrpa.