Nagbubuklod ang SQL Server sa isang VPN address na wala sa boot

Basahin ang isang linya sa SQL Server log tungkol sa bigong pagbuklod habang tumatakbo pa ang serbisyo, at nakakita ka ng dependency sa boot order, hindi isang crash. Ang kombinasyong iyon ang palatandaan: nagsimula ang engine bago pa umiral sa makina ang address na sinabihang pakinggan. Ang VPN adapter na lumalabas pagkatapos ng pag-sign in ay mahinang paunang kondisyon para sa isang database service na walang nagbabantay, kaya sundan ang pagkabigo sa pagkakasunod-sunod na nakikita ng engine.

Magsimula sa startup log, hindi sa kliyente

Buksan ang error log ng instance at basahin ang mga entry sa paligid ng network initialization, hindi lang ang huling linya. Iniulat ng engine kung aling mga address ang sinubukan at aling mga protocol ang pinagana, at ang rekord na iyon ay mula bago pa kumonekta ang sinumang kliyente. Ngayon tingnan kung ano ang umiiral sa host sa sandaling ito. Kung ang interface na nagmamay-ari ng naka-configure na address ay lumalabas lamang pagkatapos mag-sign in ang user at magsimula ng kliyente, wala ang address sa boot at ganap na naipaliwanag ang bigong pagbuklod.

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

Isaayos ang landas ng instance sa iyong installation, at basahin ang listahan ng interface bago maghinuha. Ang address na umiiral ngunit pagmamay-ari ng maling adapter ay ibang problema kaysa sa address na wala pa.

Sundan ang pagkakasunod-sunod ng pagbuklod na talagang sinusunod ng engine

Binabasa ng engine ang configuration ng listener nito, pagkatapos hinihiling sa operating system na magbuklod. Kung ang address ay hindi lokal sa sandaling iyon, nabibigo ang pagbuklod para sa address na iyon habang ang natitirang bahagi ng instance ay maaaring magpatuloy nang normal. Kaya't ang ibang protocol o ibang address ay maaari pa ring gumana, at kaya't ang „down ang SQL Server“ ay maling buod. Itago ang eksaktong endpoint mula sa log: address, port at protocol, dahil nakasalalay sa alin sa tatlo ang mali ang pagwawasto.

Ang pag-restart ng serbisyo pagkatapos lumitaw ang adapter ay karaniwang nagpapagana sa listener, at iyon mismo ang patibong. Pinatutunayan nito ang dependency sa halip na alisin ito, at pinuputol ang bawat konektadong user sa tuwing muling kumokonekta ang tunnel.

Basahin ang listener gaya ng pagbasa ng engine

Sa SQL Server Configuration Manager, buksan ang TCP/IP properties ng instance at pansinin ang setting na Listen All bago i-edit ang mga indibidwal na address. Kapag ang Listen All ay Yes, binabalewala ang mga halagang Enabled bawat address, kaya walang nababago sa ginagamit ng listener kapag in-edit ang mga ito. Itala ang tatlong bagay sa pagkakasunod-sunod: ang address na balak mong serbisyuhan, ang port, at kung saklaw ng listener ang lahat ng address o isa lamang. Pagkatapos ilapat ang pagbabago sa pamamagitan ng sinusuportahang pamamaraan ng pag-restart at basahin ang susunod na startup log upang kumpirmahin na nabuklod ng engine ang hiniling mo.

Ang pakikinig sa bawat address ay hindi access control. Kung talagang kailangan ang malawak na listener, kailangan ng bawat maaabot na interface ang sarili nitong desisyon sa firewall at authorization ng database, kabilang ang anumang interface na nakaharap sa internet.

Bigyan ang kliyente ng matatag na destinasyon

Hindi kailangan ng kliyente na magsuot ang database host ng address mula sa pool. Gumagana ang routed na disenyo habang nakikinig ang server sa matatag nitong pribadong address at ipinapasa ng VPN gateway ang traffic ng kliyente papunta rito at ibinabalik ang sagot.

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

Kung naaabot ng kliyente ang 10.80.0.15, napatunayan ang landas at kailangan lamang ng database na pahintulutan ang kliyenteng iyon. Kung hindi, ayusin ang routing at DNS bago muling hawakan ang listener, dahil ang problema sa pagbuklod sa server ay hindi kailanman naging dahilan kung bakit hindi ito mahanap ng kliyente. Ang pagdaragdag ng pekeng address mula sa pool sa server, o ng pangalawang default gateway upang mapasaya ang listener, ay lumilikha ng bagong problema sa network sa ibabaw ng luma. Panatilihing static ang addressing ng server at hayaang dalhin ng tunnel ang mga kliyente rito.

I-verify ang endpoint na ginamit ng kliyente

Tapusin sa pagsusuring nasa antas ng application sa halip na pagsubok sa port. Kumonekta mula sa kliyente gamit ang account na ginagamit ng application at basahin ang mga detalye ng koneksyon sa panig ng server, na nagpapakita ng lokal na address kung saan lumapag ang session mo.

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"

Ihambing ang address na iyon sa listener na na-configure mo. Ang pagkakaiba ay nangangahulugan ng pangalawang listener o pangalang nareresolba sa hindi inaasahang lugar, at pareho itong dapat malaman bago subukan ng susunod na reboot ang pagwawasto mo para sa iyo. Pagkatapos i-reboot ang host na walang naka-sign in na user at kumpirmahin na nagtagumpay ang pagbuklod. Ang nag-iisang pagsubok na iyon ang pagkakaiba ng naayos na listener at ng pansamantalang solusyon na nabibigo sa susunod na gabi ng patch.