SQL Server se leagă de o adresă VPN care nu există la pornire

Citiți o linie din jurnalul SQL Server despre o legare eșuată în timp ce serviciul încă rulează și ați găsit o dependență de ordinea de pornire, nu un crash. Exact această combinație este indiciul: motorul a pornit înainte ca adresa pe care trebuia să asculte să existe pe mașină. Un adaptor VPN care apare după autentificare este o premisă slabă pentru un serviciu de bază de date nesupravegheat, așa că urmăriți eșecul în ordinea în care îl vede motorul.

Începeți cu jurnalul de pornire, nu cu clientul

Deschideți jurnalul de erori al instanței și citiți intrările din jurul inițializării rețelei, nu doar ultima linie. Motorul raportează ce adrese a încercat și ce protocoale a activat, iar acea înregistrare este de dinainte ca vreun client să se conecteze. Acum uitați-vă ce există pe gazdă chiar în acest moment. Dacă interfața care deține adresa configurată apare doar după ce un utilizator se autentifică și pornește un client, adresa lipsea la pornire, iar eșecul legării este pe deplin explicat.

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

Adaptați calea instanței la instalarea dumneavoastră și citiți lista interfețelor înainte de a trage concluzii. O adresă care există, dar aparține adaptorului greșit, este o problemă diferită de o adresă care încă nu există.

Parcurgeți ordinea de legare pe care motorul o urmează cu adevărat

Motorul citește configurația listenerului și apoi cere sistemului de operare să lege. Dacă adresa nu este locală în acel moment, legarea eșuează pentru acea adresă, în timp ce restul instanței poate continua normal. De aceea alte protocoale sau alte adrese pot funcționa în continuare și de aceea „SQL Server este căzut“ este rezumatul greșit. Păstrați endpointul exact din jurnal: adresă, port și protocol, pentru că remedierea depinde de care dintre cele trei este greșit.

Repornirea serviciului după apariția adaptorului va face de obicei listenerul să reușească, și exact aceasta este capcana. Dovedește dependența în loc să o elimine și întrerupe fiecare utilizator conectat de fiecare dată când tunelul se reconectează.

Citiți listenerul așa cum îl citește motorul

În SQL Server Configuration Manager, deschideți proprietățile TCP/IP ale instanței și observați setarea Listen All înainte de a edita adrese individuale. Când Listen All este Yes, valorile Enabled pe adresă sunt ignorate, așa că editarea lor nu schimbă nimic din ce folosește listenerul. Notați trei lucruri în ordine: adresa pe care intenționați să o deserviți, portul și dacă listenerul trebuie să acopere toate adresele sau doar una. Apoi aplicați schimbarea prin procedura de repornire acceptată și citiți următorul jurnal de pornire pentru a confirma că motorul a legat ceea ce ați cerut.

Ascultarea pe fiecare adresă nu este control de acces. Dacă un listener larg este cu adevărat necesar, fiecare interfață accesibilă are nevoie de propria decizie privind firewallul și autorizarea bazei de date, inclusiv orice interfață orientată spre internet.

Dați clientului o destinație stabilă

Clientul nu are nevoie ca gazda bazei de date să poarte o adresă din pool. Un design rutat funcționează cu serverul ascultând pe adresa sa privată stabilă, în timp ce gateway-ul VPN redirecționează traficul clientului către el și aduce răspunsul înapoi.

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

Dacă clientul ajunge la 10.80.0.15, calea este dovedită și baza de date trebuie doar să autorizeze acel client. Dacă nu, corectați rutarea și DNS-ul înainte de a atinge din nou listenerul, pentru că o problemă de legare pe server nu a fost niciodată motivul pentru care un client nu îl poate găsi. Adăugarea unei adrese false din pool la server, sau a unui al doilea gateway implicit pentru a mulțumi listenerul, creează o nouă problemă de rețea peste cea veche. Păstrați adresarea serverului statică și lăsați tunelul să aducă clienții la el.

Verificați endpointul pe care l-a folosit clientul

Încheiați cu o verificare la nivel de aplicație în loc de un test de port. Conectați-vă din client cu contul pe care îl folosește aplicația și citiți detaliile conexiunii din partea serverului, care arată adresa locală pe care a aterizat sesiunea dumneavoastră.

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"

Comparați acea adresă cu listenerul pe care l-ați configurat. O nepotrivire înseamnă un al doilea listener sau un nume rezolvat într-un loc neașteptat, iar ambele merită știute înainte ca următoarea repornire să vă testeze remedierea în locul dumneavoastră. Apoi reporniți gazda fără niciun utilizator autentificat și confirmați că legarea reușește. Acel singur test este diferența dintre un listener reparat și o soluție ocolitoare care eșuează în următoarea noapte de patch-uri.