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

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 računalu. VPN adapter koji se pojavi nakon prijave loš je preduvjet 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 je zapis od prije nego što se povezao ijedan klijent. Sada pogledajte što postoji na hostu upravo sada. Ako se sučelje koje posjeduje konfiguriranu 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 popis sučelja 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 operacijskog sustava 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 točnu krajnju točku iz dnevnika: adresu, port i protokol, jer popravak zavisi od toga što 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 ponovno 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 ignoriraju, 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 treba li slušač 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, svako dostupno sučelje treba vlastitu odluku o vatrozidu i autorizaciji baze podataka, uključujući svako sučelje okrenuto internetu.

Dajte klijentu stabilno odredište

Klijentu ne treba da host baze podataka nosi adresu iz pula. Rutirano rješenje radi dok poslužitelj 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 usmjeravanje i DNS prije nego ponovo dirate slušač, jer problem vezivanja na poslužitelju nikada nije bio razlog zašto ga klijent ne može naći. Dodavanje lažne adrese iz pula poslužitelju, ili drugog zadanog gatewaya da bi slušač bio zadovoljan, stvara novi mrežni problem povrh starog. Držite adresiranje poslužitelja statičnim i pustite tunel da dovodi klijente do njega.

Provjerite krajnju točku koju je klijent koristio

Završite provjerom na razini aplikacije, a ne testom porta. Povežite se s klijenta računom koji aplikacija koristi i pročitajte pojedinosti veze na strani poslužitelja, koje 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"

Usporedite tu adresu sa slušačem koji ste konfigurirali. 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š popravak umjesto vas. Zatim ponovno 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.