Dauguma žmonių SQL Server pagrindinio kompiuterio vardą laiko visu adresu, o VPN – kažkuo, kas arba leidžiama, arba ne. Praktiškai pavadinta instancija verčia klientą po DNS atlikti antrą paiešką, ir būtent tą paiešką tunelis dažniausiai sugadina. Aiškus galinis taškas jos išvengia, todėl tcp:host,port gali veikti, o host\INSTANCE baigiasi skirtuoju laiku. Skirtumas yra tarp paslaugos radimo ir leidimo ja naudotis.

Mitas: vienas pagrindinio kompiuterio vardas reiškia vieną prievadą

Pagrindinio kompiuterio vardas išsprendžiamas į adresą, ir ten jo darbas baigiasi. Pavadinta instancija prideda instancijos vardą, kurį serveris turi išversti į TCP prievadą, o klientas negali jo atspėti. 1433 prievadas yra numatytosios instancijos numatytasis, o ne kiekvienos instancijos savybė. Jei abu laikomi tuo pačiu dalyku, atsiranda klasikinis simptomas: ping veikia, DNS veikia, 1433 skenavimas nieko nerodo, ir išvada yra ta, kad tinklas blokuoja SQL.

Antra prielaida žlunga taip pat: kad atidaryti TCP 1433 pakanka. Jei instancija klausosi kitur, atidarytas 1433 tik įrodo, kad ten yra kažkas kita. Prievadas turi atitikti klausytoją, ir kad klausytojas yra serverio pusės konfigūracijos detalė to reikia klausti, o ne spėlioti.

Ką klientas iš tikrųjų daro su pavadinta instancija

Išsprendęs pagrindinį kompiuterį, klientas siunčia aptikimo užklausą SQL Server Browser per UDP 1434 ir klausia, kurį prievadą naudoja pavadinta instancija. Naršyklės paslauga atsako iš paties serverio registro, tada klientas atidaro TCP ryšį su tuo prievadu. Du protokolai ir du prievadai dalyvauja dar prieš bandant prisijungti.

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

Todėl blokuojant tik UDP gaunamas skirtasis laikas, kuris atrodo kaip miręs pagrindinis kompiuteris. Jei naršyklės paslauga sustabdyta ar išjungta, aptikimo užklausa lieka neatsakyta, nors duomenų bazės variklis veikia ir jo TCP prievadas atidarytas. Jei instancija sukonfigūruota su statiniu prievadu, klientas vis tiek klausia, nebent jam buvo duotas galinis taškas tiesiogiai. Kiekviena iš šių klaidų atrodo vienodai programos klaidos pranešime, ir joms reikia skirtingų pataisymų.

Naršyklės paslauga yra aptikimo patogumas, o ne duomenų bazė. Jos sustabdymas nesustabdo variklio, o paleidimas neatidaro instancijos TCP prievado.

Kodėl aiškus galinis taškas veikia, kai vardas neveikia

Aiškus galinis taškas pašalina paiešką iš sekos: klientas jungiasi tiesiai prie jūsų nurodyto adreso ir prievado. Tai pirmiausia diagnostika, o ne automatiškai nuolatinis sprendimas, nes prievadas gali pasikeisti, jei instancija vėliau bus perkonfigūruota į dinaminį. Prieš darydami išvadas palyginkite abi formas su tuo pačiu klientu ir ta pačia paskyra.

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

Jei aiški forma pavyksta, o pavadinta nepavyksta, aptikimo trūksta, ir galite pasirinkti, kaip jį uždaryti: leiskite UDP 1434 per tunelį arba paprašykite administratoriaus užfiksuoti statinį prievadą ir dokumentuoti galinį tašką. Abu yra sąmoningi sprendimai su skirtingomis priežiūros sąnaudomis. Atidaryti kiekvieną diapazono prievadą nėra nei vienas, nei kitas, ir tai yra variantas, kuris paprastai siūlomas ilgos dienos pabaigoje. Užrašykite pasirinkimą ten, kur gyvena jungties eilutės.

Jei nė viena forma neveikia, problema yra aukščiau aptikimo. Patikrinkite klausytoją, maršrutą ir prieigos taisyklę tam prievadui, kurį instancija iš tikrųjų naudoja, prieš kaltindami naršyklės paslaugą.

Po aptikimo: autentifikavimas ir tapatybė yra atskiri

Prisijungimo klaida yra kitas įvykis nei skirtasis laikas, ir VPN tapatybė netampa SQL prisijungimu dėl tunelio. Kai klientas pasiekia tinkamą prievadą, duomenų bazės variklis taiko savo autentifikavimą ir leidimus. Abiejų etapų sumaišymas viename biliete yra būdas, kuriuo aptikimo problema priskiriama netinkamai komandai. Prieš ką nors keisdami perskaitykite klaidos numerį.

Išsaugokite dokumentuotą pagrindinio kompiuterio vardą, jei tvarkyklė tikrina serverio sertifikatą, nes jungimasis skaitmeniniu adresu gali pakeisti tą patikrą, o ne išspręsti pradinę problemą. Naujausios Microsoft tvarkyklės pagal numatytuosius nustatymus šifruoja, todėl vardo neatitikimas pasirodo kaip sertifikato klaida po sėkmingo TCP ryšio. Tai pažanga, o ne nauja klaida.

Mitas, kurio reikia atsisakyti, yra tai, kad SQL Server pagrindinio kompiuterio vardas yra visas adresas. Tai pagrindinis kompiuteris ir, pavadintos instancijos atveju, paieška, kurios tunelis gali neperduoti. Įvardykite prievadą, įvardykite aptikimo kelią, ir kita klaida pasakys, kurį sluoksnį taisyti.

Susiję straipsniai