Instanță numită SQL Server prin VPN: descoperire, nu portul 1433

Majoritatea oamenilor tratează un nume de gazdă SQL Server ca pe o adresă completă și un VPN ca pe ceva fie permis, fie nu. În practică, o instanță numită obligă clientul să facă o a doua căutare după DNS, iar acea căutare este partea pe care un tunel o rupe cel mai des. Un punct final explicit o ocolește, de aceea tcp:host,port poate funcționa în timp ce host\INSTANCE expiră. Diferența este între a găsi serviciul și a avea permisiunea de a-l folosi.

Mitul: un nume de gazdă înseamnă un port

Numele de gazdă se rezolvă într-o adresă, și acolo se termină treaba lui. O instanță numită adaugă un nume de instanță pe care serverul trebuie să îl traducă într-un port TCP, iar clientul nu îl poate ghici. Portul 1433 este implicit pentru o instanță implicită, nu o proprietate a fiecărei instanțe de pe mașină. Tratarea celor două ca același lucru produce simptomul clasic: ping funcționează, DNS funcționează, scanarea portului 1433 nu arată nimic, iar concluzia este că rețeaua blochează SQL.

O a doua presupunere eșuează la fel: că deschiderea TCP 1433 este suficientă. Dacă instanța ascultă în altă parte, un 1433 deschis dovedește doar că acolo este altceva. Portul trebuie să corespundă ascultătorului, iar că ascultătorul este un detaliu de configurare din partea serverului acest lucru trebuie întrebat, nu presupus.

Ce face de fapt clientul cu o instanță numită

După rezolvarea gazdei, clientul trimite o cerere de descoperire către SQL Server Browser pe UDP 1434 și întreabă ce port folosește instanța numită. Serviciul de browser răspunde din registrul serverului însuși, apoi clientul deschide o conexiune TCP către acel port. Două protocoale și două porturi sunt implicate înainte de a se încerca măcar o autentificare.

nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser

De aceea o blocare doar pe UDP produce un timeout care arată ca o gazdă moartă. Dacă serviciul de browser este oprit sau dezactivat, cererea de descoperire rămâne fără răspuns, deși motorul bazei de date rulează și portul său TCP este deschis. Dacă instanța este configurată cu un port static, clientul întreabă în continuare, dacă nu i s-a dat punctul final direct. Fiecare dintre aceste eșecuri arată la fel în mesajul de eroare al aplicației, și au nevoie de corecții diferite.

Serviciul de browser este o comoditate de descoperire, nu baza de date. Oprirea lui nu oprește motorul, iar pornirea lui nu deschide portul TCP al instanței.

De ce punctul final explicit funcționează când numele nu funcționează

Un punct final explicit scoate căutarea din secvență: clientul se conectează direct la adresa și portul pe care le-ați numit. Aceasta este mai întâi o diagnoză, nu automat o corecție permanentă, deoarece portul se poate schimba dacă instanța este reconfigurată ulterior pe unul dinamic. Comparați cele două forme cu același client și același cont înainte de a trage concluzii.

sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433

Dacă forma explicită reușește și forma numită eșuează, descoperirea este lipsa, iar dumneavoastră puteți alege cum o închideți: permiteți UDP 1434 prin tunel, sau rugați administratorul să fixeze un port static și să documenteze punctul final. Ambele sunt decizii deliberate cu costuri de întreținere diferite. Deschiderea fiecărui port din interval nu este niciuna dintre ele, și este opțiunea care tinde să fie propusă la sfârșitul unei zile lungi. Notați alegerea acolo unde trăiesc șirurile de conexiune.

Dacă niciuna dintre forme nu funcționează, problema este mai sus de descoperire. Verificați ascultătorul, ruta și regula de acces pentru portul pe care instanța îl folosește efectiv înainte de a da vina pe serviciul de browser.

După descoperire: autentificarea și identitatea sunt separate

O eroare de autentificare este un eveniment diferit de un timeout, iar identitatea VPN nu devine o autentificare SQL datorită tunelului. Când clientul ajunge la portul corect, motorul bazei de date aplică propria autentificare și propriile permisiuni. Amestecarea celor două etape într-un singur tichet este modul în care o problemă de descoperire ajunge la echipa greșită. Citiți numărul erorii înainte de a schimba ceva.

Păstrați numele de gazdă documentat dacă driverul validează certificatul serverului, deoarece conectarea prin adresă numerică poate schimba acea verificare în loc să rezolve problema inițială. Driverele Microsoft recente criptează implicit, așa că o nepotrivire de nume apare ca eroare de certificat după o conexiune TCP reușită. Acesta este un progres, nu un eșec nou.

Mitul de care trebuie să scăpăm este că un nume de gazdă SQL Server este o adresă completă. Este o gazdă plus, pentru o instanță numită, o căutare pe care tunelul poate să nu o transporte. Numiti portul, numiti calea de descoperire, iar următorul eșec vă va spune ce strat să reparați.