SQL Server lidhet me një adresë VPN që nuk ekziston në nisje

Lexoni një rresht në regjistrin e SQL Server për një lidhje të dështuar ndërsa shërbimi është ende në punë, dhe keni gjetur një varësi nga rendi i nisjes, jo një rrëzim. Pikërisht ai kombinim është të dhëna: motori filloi para se adresa ku duhej të dëgjonte të ekzistonte në makinë. Një përshtatës VPN që shfaqet pas identifikimit është një parakusht i dobët për një shërbim baze të dhënash pa mbikëqyrje, prandaj ndiqni dështimin në rendin që e sheh motori.

Filloni nga regjistri i nisjes, jo nga klienti

Hapni regjistrin e gabimeve të instancës dhe lexoni hyrjet rreth inicializimit të rrjetit, jo vetëm rreshtin e fundit. Motori raporton cilat adresa provoi dhe cilat protokolle aktivizoi, dhe ai regjistrim është nga para se të lidhej ndonjë klient. Tani shikoni çfarë ekziston në host në këtë moment. Nëse ndërfaqja që zotëron adresën e konfiguruar shfaqet vetëm pasi përdoruesi identifikohet dhe nis një klient, adresa mungonte në nisje dhe dështimi i lidhjes shpjegohet plotësisht.

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

Përshtatni shtegun e instancës me instalimin tuaj dhe lexoni listën e ndërfaqeve para se të nxirrni përfundime. Një adresë që ekziston por i përket përshtatësit të gabuar është problem tjetër nga një adresë që nuk ekziston ende.

Kaloni nëpër rendin e lidhjes që motori ndjek në të vërtetë

Motori lexon konfigurimin e dëgjuesit dhe më pas i kërkon sistemit operativ të lidhë. Nëse adresa nuk është lokale në atë moment, lidhja dështon për atë adresë, ndërsa pjesa tjetër e instancës mund të vazhdojë normalisht. Kjo është arsyeja pse protokollet ose adresat e tjera mund të vazhdojnë të punojnë, dhe kjo është arsyeja pse „SQL Server është jashtë“ është përmbledhja e gabuar. Ruani pikën fundore të saktë nga regjistri: adresa, porta dhe protokolli, sepse rregullimi varet nga cila e të trejave është e gabuar.

Rinisja e shërbimit pasi shfaqet përshtatësi zakonisht do ta bëjë dëgjuesin të ketë sukses, dhe pikërisht kjo është kurthi. E vërteton varësinë në vend që ta heqë, dhe shkëput çdo përdorues të lidhur sa herë që tuneli rilidhet.

Lexoni dëgjuesin ashtu siç e lexon motori

Në SQL Server Configuration Manager, hapni vetitë TCP/IP të instancës dhe vini re cilësimin Listen All përpara se të redaktoni adresa individuale. Kur Listen All është Yes, vlerat Enabled për çdo adresë injorohen, kështu që redaktimi i tyre nuk ndryshon asgjë që përdor dëgjuesi. Shënoni tre gjëra me radhë: adresën që synoni të shërbeni, portën dhe nëse dëgjuesi duhet të mbulojë të gjitha adresat ose vetëm një. Më pas zbatoni ndryshimin përmes procedurës së mbështetur të rinisjes dhe lexoni regjistrin e ardhshëm të nisjes për të konfirmuar që motori lidhi atë që kërkuat.

Dëgjimi në çdo adresë nuk është kontroll aksesi. Nëse një dëgjues i gjerë është vërtet i nevojshëm, çdo ndërfaqe e arritshme ka nevojë për vendimin e vet të murit të zjarrit dhe autorizimit të bazës së të dhënave, duke përfshirë çdo ndërfaqe që shikon nga interneti.

Jepini klientit një destinacion të qëndrueshëm

Klienti nuk ka nevojë që hosti i bazës së të dhënave të mbajë një adresë pishine. Një dizajn i rrugëzuar funksionon me serverin që dëgjon në adresën e tij private të qëndrueshme, ndërsa porta VPN përcjell trafikun e klientit drejt tij dhe kthen përgjigjen.

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

Nëse klienti arrin 10.80.0.15, rruga është vërtetuar dhe baza e të dhënave duhet vetëm të autorizojë atë klient. Nëse jo, rregulloni rrugëzimin dhe DNS-në përpara se të prekni përsëri dëgjuesin, sepse një problem lidhjeje në server nuk ishte kurrë arsyeja pse një klient nuk mund ta gjejë atë. Shtimi i një adrese të rreme pishine te serveri, ose i një porte të dytë të parazgjedhur për të kënaqur dëgjuesin, krijon një problem të ri rrjeti mbi atë të vjetrin. Mbani adresimin e serverit statik dhe lërini tunelin t'i sjellë klientët tek ai.

Verifikoni pikën fundore që përdori klienti

Përfundoni me një kontroll në nivel aplikacioni në vend të një testi porte. Lidhuni nga klienti me llogarinë që përdor aplikacioni dhe lexoni detajet e lidhjes në anën e serverit, të cilat tregojnë adresën lokale ku ateroi sesioni juaj.

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"

Krahasoni atë adresë me dëgjuesin që konfiguruat. Një mospërputhje do të thotë një dëgjues i dytë ose një emër që zgjidhet diku të papritur, dhe të dyja ia vlen t'i dini përpara se rinisja tjetër të provojë rregullimin tuaj në vend tuajin. Më pas rinisni hostin pa asnjë përdorues të identifikuar dhe konfirmoni që lidhja ka sukses. Ai test i vetëm është ndryshimi midis një dëgjuesi të riparuar dhe një zgjidhjeje të përkohshme që dështon natën tjetër të arnimeve.