Pinangalanang instance ng SQL Server sa VPN: pagtuklas, hindi port 1433

Karamihan ng tao ay tinatrato ang hostname ng SQL Server bilang kumpletong address, at ang VPN bilang pinapayagan o hindi. Sa praktika, ang pinangalanang instance ay nagpipilit sa kliyente na gumawa ng pangalawang paghahanap pagkatapos ng DNS, at iyon ang bahaging madalas sirain ng tunnel. Ang tahasang endpoint ay lumalampas doon, kaya gumagana ang tcp:host,port habang nag-expire ang host\INSTANCE. Ang pagkakaiba ay nasa pagitan ng paghahanap ng serbisyo at pagkuha ng pahintulot na gamitin ito.

Mito: isang hostname ay isang port

Ang hostname ay nireresolba sa isang address, at doon nagtatapos ang trabaho nito. Ang pinangalanang instance ay nagdaragdag ng pangalan ng instance na kailangang isalin ng server sa isang TCP port, at hindi ito mahuhulaan ng kliyente. Ang port 1433 ay default para sa default na instance, hindi katangian ng bawat instance sa makina. Ang pagtrato sa dalawa bilang isa ay lumilikha ng klasikong sintomas: gumagana ang ping, gumagana ang DNS, walang ipinapakita ang scan ng 1433, at ang konklusyon ay hinaharangan ng network ang SQL.

Nabigo rin ang pangalawang palagay sa parehong paraan: na sapat ang pagbukas ng TCP 1433. Kung nakikinig ang instance sa ibang lugar, ang bukas na 1433 ay nagpapatunay lamang na may iba pang bagay doon. Dapat tumugma ang port sa tagapakinig, at na ang tagapakinig ay isang detalye ng configuration sa panig ng server dapat itong itanong sa halip na hulaan.

Ano ang aktwal na ginagawa ng kliyente sa pinangalanang instance

Pagkatapos i-resolve ang host, nagpapadala ang kliyente ng kahilingan sa pagtuklas sa SQL Browser sa UDP 1434 at nagtatanong kung aling port ang ginagamit ng pinangalanang instance. Sumasagot ang serbisyo ng browser mula sa registry ng server mismo, at pagkatapos ay nagbubukas ang kliyente ng TCP na koneksyon sa port na iyon. Dalawang protocol at dalawang port ang kasangkot bago pa man subukan ang pag-login.

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

Kaya ang pag-block ng UDP lamang ay gumagawa ng timeout na mukhang patay na host. Kung ang serbisyo ng browser ay naka-stop o naka-disable, ang kahilingan sa pagtuklas ay nananatiling walang sagot kahit tumatakbo ang engine ng database at bukas ang TCP port nito. Kung naka-configure ang instance sa static na port, nagtatanong pa rin ang kliyente maliban kung direktang ibinigay ang endpoint. Ang bawat isa sa mga pagkabigong ito ay magkamukha sa mensahe ng error ng application, at kailangan nila ng magkaibang pagwawasto.

Ang serbisyo ng browser ay kaginhawahan sa pagtuklas, hindi ang database. Ang paghinto nito ay hindi humihinto sa engine, at ang pagsisimula nito ay hindi nagbubukas ng TCP port ng instance.

Bakit gumagana ang tahasang endpoint kapag hindi gumagana ang pangalan

Ang tahasang endpoint ay nag-aalis ng paghahanap mula sa pagkakasunod-sunod: direktang kumokonekta ang kliyente sa address at port na pinangalanan mo. Ito ay una isang diagnostic, hindi awtomatikong permanenteng pagwawasto, dahil maaaring magbago ang port kung ang instance ay muling i-configure sa dynamic sa hinaharap. Ihambing ang dalawang anyo gamit ang parehong kliyente at parehong account bago gumawa ng konklusyon.

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

Kung magtagumpay ang tahasang anyo at mabigo ang pinangalanang anyo, ang pagtuklas ang puwang, at maaari mong piliin kung paano ito isasara: payagan ang UDP 1434 sa tunnel, o hilingin sa administrator na i-pin ang static na port at idokumento ang endpoint. Pareho silang sadyang desisyon na may magkaibang gastos sa maintenance. Ang pagbukas ng bawat port sa saklaw ay wala sa dalawa, at ito ang opsyong madalas imungkahi sa dulo ng mahabang araw. Itala ang pinili sa kung saan nakatira ang mga string ng koneksyon.

Kung wala sa dalawang anyo ang gumagana, ang problema ay nasa itaas ng pagtuklas. Suriin ang tagapakinig, ang ruta at ang tuntunin sa pag-access para sa port na aktwal na ginagamit ng instance bago sisihin ang serbisyo ng browser.

Pagkatapos ng pagtuklas: hiwalay ang authentication at identity

Ang pagkabigo sa pag-login ay ibang pangyayari kaysa sa timeout, at ang identity ng VPN ay hindi nagiging pag-login sa SQL dahil sa tunnel. Kapag naabot ng kliyente ang tamang port, inilalapat ng engine ng database ang sarili nitong authentication at mga pahintulot. Ang paghahalo ng dalawang yugto sa isang ticket ay ang paraan kung paano napupunta ang problema sa pagtuklas sa maling koponan. Basahin ang numero ng error bago baguhin ang anuman.

Panatilihin ang dokumentadong hostname kung vine-validate ng driver ang certificate ng server, dahil ang pagkonekta sa numeric na address ay maaaring baguhin ang pagsusuring iyon sa halip na lutasin ang orihinal na problema. Ang mga bagong driver ng Microsoft ay nag-encrypt bilang default, kaya lumilitaw ang hindi pagkakatugma ng pangalan bilang error sa certificate pagkatapos ng matagumpay na TCP na koneksyon. Iyon ay pag-unlad, hindi bagong pagkabigo.

Ang mitong dapat iwanan ay na ang hostname ng SQL Server ay kumpletong address. Ito ay host kasama ng, para sa pinangalanang instance, isang paghahanap na maaaring hindi dalhin ng tunnel. Pangalanan ang port, pangalanan ang landas ng pagtuklas, at sasabihin ng susunod na pagkabigo kung aling layer ang aayusin.