Imenovana instanca SQL Serverja prek VPN: odkrivanje, ne vrata 1433
Imenovana instanca pred povezavo vpraša SQL Browser za vrata. Če ime prek VPN ne uspe, tcp:host,port pa deluje, je vrzel v odkrivanju.
Večina ljudi obravnava ime gostitelja SQL Serverja kot popoln naslov, VPN pa kot nekaj, kar je dovoljeno ali ne. V praksi imenovana instanca prisili odjemalca, da po DNS opravi drugo iskanje, in prav to iskanje tunel najpogosteje zlomi. Izrecna končna točka se mu izogne, zato tcp:host,port lahko deluje, medtem ko host\INSTANCE poteče. Razlika je med najti storitev in dobiti dovoljenje za njeno uporabo.
Mit: eno ime gostitelja pomeni ena vrata
Ime gostitelja se razreši v naslov in tam se njegovo delo konča. Imenovana instanca doda ime instance, ki ga mora strežnik prevesti v vrata TCP, odjemalec pa ga ne more uganiti. Vrata 1433 so privzeta za privzeto instanco, ne lastnost vsake instance na stroju. Če oboje obravnavamo kot isto stvar, nastane klasičen simptom: ping deluje, DNS deluje, skeniranje 1433 ne pokaže ničesar, sklep pa je, da omrežje blokira SQL.
Druga predpostavka spodleti enako: da je dovolj odpreti TCP 1433. Če instanca posluša drugje, odprta 1433 dokazuje le, da je tam nekaj drugega. Vrata se morajo ujemati s poslušalcem, in da je poslušalec podrobnost konfiguracije na strani strežnika o tem se je treba vprašati, ne ugibati.
Kaj odjemalec v resnici počne z imenovano instanco
Po razrešitvi gostitelja odjemalec pošlje zahtevo za odkrivanje SQL Server Browserju prek UDP 1434 in vpraša, katera vrata uporablja imenovana instanca. Storitev brskalnika odgovori iz strežnikovega lastnega registra, nato odjemalec odpre povezavo TCP na ta vrata. Pred poskusom prijave sodelujeta dva protokola in dvoje vrat.
nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser
Zato blokada samo UDP povzroči časovno omejitev, ki izgleda kot mrtev gostitelj. Če je storitev brskalnika ustavljena ali onemogočena, zahteva za odkrivanje ostane brez odgovora, čeprav motor baze podatkov deluje in so njegova vrata TCP odprta. Če je instanca nastavljena s statičnimi vrati, odjemalec vseeno vpraša, razen če mu je bila končna točka dana neposredno. Vsaka od teh napak je v sporočilu o napaki aplikacije videti enako, potrebujejo pa različne popravke.
Storitev brskalnika je priročnost za odkrivanje, ne baza podatkov. Če jo ustavimo, motor se ne ustavi, če jo zaženemo, pa se vrata TCP instance ne odprejo.
Zakaj izrecna končna točka deluje, ko ime ne
Izrecna končna točka odstrani iskanje iz zaporedja: odjemalec se poveže neposredno na naslov in vrata, ki ste jih navedli. To je najprej diagnostika, ne samodejno trajna rešitev, ker se vrata lahko spremenijo, če se instanca pozneje prekonfigurira na dinamična. Preden sklepate, primerjajte obe obliki z istim odjemalcem in istim računom.
sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433
Če izrecna oblika uspe, imenovana pa spodleti, je vrzel v odkrivanju in lahko izberete, kako jo zapreti: dovolite UDP 1434 skozi tunel ali prosite skrbnika, da pripne statična vrata in dokumentira končno točko. Oboje so namerne odločitve z različnimi stroški vzdrževanja. Odpreti vsaka vrata v obsegu ni ne eno ne drugo in to je možnost, ki se običajno predlaga na koncu dolgega dne. Zapišite izbiro tam, kjer živijo povezovalni nizi.
Če nobena oblika ne deluje, je težava višje od odkrivanja. Preverite poslušalca, pot in pravilo dostopa za vrata, ki jih instanca dejansko uporablja, preden krivite storitev brskalnika.
Po odkrivanju: preverjanje pristnosti in identiteta sta ločeni
Neuspešna prijava je drugačen dogodek kot časovna omejitev in identiteta VPN zaradi tunela ne postane prijava SQL. Ko odjemalec doseže prava vrata, motor baze podatkov uporabi svoje preverjanje pristnosti in svoja dovoljenja. Mešanje obeh stopenj v enem zahtevku je način, kako težava z odkrivanjem pride do napačne ekipe. Preden karkoli spremenite, preberite številko napake.
Ohranite dokumentirano ime gostitelja, če gonilnik preverja strežnikovo potrdilo, ker povezava prek številčnega naslova lahko spremeni to preverjanje, namesto da bi rešila prvotno težavo. Novejši gonilniki Microsofta privzeto šifrirajo, zato se neujemanje imena pokaže kot napaka potrdila po uspešni povezavi TCP. To je napredek, ne nova okvara.
Mit, ki se mu je treba odpovedati, je, da je ime gostitelja SQL Serverja popoln naslov. To je gostitelj plus, za imenovano instanco, iskanje, ki ga tunel morda ne prenese. Poimenujte vrata, poimenujte pot odkrivanja, in naslednja okvara vam bo povedala, kateri sloj popraviti.