VPN üzərindən SQL Server adlandırılmış instansiyası: kəşf, 1433 portu deyil
Adlandırılmış instansiya qoşulmadan əvvəl SQL Browser-dən port soruşur. Ad VPN üzərindən uğursuz olur, amma tcp:host,port işləyirsə, çatışmazlıq kəşfdədir.
Əksər insanlar SQL Server host adını tam ünvan, VPN-i isə ya icazəli ya da icazəsiz bir şey kimi qəbul edir. Praktikada adlandırılmış instansiya müştərini DNS-dən sonra ikinci bir axtarış etməyə məcbur edir və tunnelin ən çox pozduğu hissə məhz həmin axtarışdır. Açıq endpoint bunu yan keçir; buna görə tcp:host,port işləyə bilir, host\INSTANCE isə vaxt aşımına uğrayır. Fərq xidməti tapmaqla ondan istifadə etməyə icazə verilməsi arasındadır.
Mif: bir host adı bir port deməkdir
Host adı bir ünvana həll olunur və onun işi burada bitir. Adlandırılmış instansiya serverin TCP portuna çevirməli olduğu instansiya adı əlavə edir və müştəri onu təxmin edə bilməz. 1433 portu default instansiya üçün defaultdur, maşındakı hər instansiyanın xassəsi deyil. İkisini eyni şey kimi qəbul etmək klassik simptomu yaradır: ping işləyir, DNS işləyir, 1433-ün skanı heç nə göstərmir və nəticə belə olur ki, şəbəkə SQL-i bloklayır.
İkinci bir fərziyyə də eyni şəkildə uğursuz olur: TCP 1433-ü açmağın kifayət etməsi. Əgər instansiya başqa yerdə dinləyirsə, açıq 1433 yalnız orada başqa bir şeyin olduğunu sübut edir. Port dinləyiciyə uyğun olmalıdır, dinləyici server tərəfində konfiqurasiya detalıdır və bunu təxmin etmək əvəzinə soruşmaq lazımdır.
Müştəri adlandırılmış instansiya ilə faktiki olaraq nə edir
Hostu həll etdikdən sonra müştəri UDP 1434 üzərindən SQL Server Browser-ə kəşf sorğusu göndərir və adlandırılmış instansiyanın hansı portu istifadə etdiyini soruşur. Browser xidməti serverin öz reyestrindən cavab verir, sonra müştəri həmin porta TCP bağlantısı açır. Giriş cəhdi edilməzdən əvvəl iki protokol və iki port iştirak edir.
nslookup sqlhost.corp.example
nc -vzu sqlhost.corp.example 1434
Get-Service -Name SQLBrowser
Buna görə yalnız UDP-nin bloklanması ölü host kimi görünən vaxt aşımı yaradır. Browser xidməti dayandırılıb və ya söndürülübsə, verilənlər bazası mühərriki işlədiyi və TCP portu açıq olduğu halda kəşf sorğusu cavabsız qalır. İnstansiya statik portla konfiqurasiya edilibsə, endpoint birbaşa verilmədiyi halda müştəri yenə də soruşur. Bu uğursuzluqların hər biri tətbiqin xəta mesajında eyni görünür və onlar fərqli düzəlişlər tələb edir.
Browser xidməti kəşf üçün rahatlıqdır, verilənlər bazası deyil. Onu dayandırmaq mühərriki dayandırmır, işə salmaq isə instansiyanın TCP portunu açmır.
Açıq endpoint niyə ad işləmədiyi halda işləyir
Açıq endpoint axtarışı ardıcıllıqdan çıxarır: müştəri birbaşa adını çəkdiyiniz ünvana və porta qoşulur. Bu ilk növbədə diaqnostikadır, avtomatik daimi həll deyil, çünki instansiya sonradan dinamik porta yenidən konfiqurasiya edilərsə, port dəyişə bilər. Nəticə çıxarmazdan əvvəl iki formanı eyni müştəri və eyni hesabla müqayisə edin.
sqlcmd -S "tcp:sqlhost.corp.example,51433" -U app_login -Q "SELECT @@SERVERNAME"
Test-NetConnection sqlhost.corp.example -Port 51433
Açıq forma işləyib adlandırılmış forma uğursuz olursa, çatışmazlıq kəşfdədir və onu necə bağlayacağınızı özünüz seçirsiniz: tunnel vasitəsilə UDP 1434-ə icazə verin, ya da administrator statik port təyin etsin və endpoint-i sənədləşdirsin. Hər ikisi fərqli texniki xidmət xərcləri olan qəsdən verilmiş qərarlardır. Aralıqdakı hər portu açmaq onların heç biri deyil və uzun günün sonunda təklif edilməyə meyilli variantdır. Seçimi bağlantı sətirlərinin saxlandığı yerdə qeyd edin.
Heç bir forma işləmirsə, problem kəşfdən yuxarıda yerləşir. Browser xidmətini günahlandırmazdan əvvəl instansiyanın faktiki istifadə etdiyi port üçün dinləyicini, marşrutu və giriş qaydasını yoxlayın.
Kəşfdən sonra: autentifikasiya və şəxsiyyət ayrı şeylərdir
Giriş uğursuzluğu vaxt aşımından fərqli hadisədir və VPN şəxsiyyəti tunnel sayəsində SQL girişinə çevrilmir. Müştəri düzgün porta çatdıqdan sonra verilənlər bazası mühərriki öz autentifikasiyasını və icazələrini tətbiq edir. İki mərhələni bir bilettə qarışdırmaq kəşf probleminin səhv komandaya verilməsinin yoludur. Bir şeyi dəyişməzdən əvvəl xəta nömrəsini oxuyun.
Sürücü server sertifikatını yoxlayırsa, sənədləşdirilmiş host adını saxlayın, çünki rəqəm ünvanla qoşulmaq ilkin problemi həll etmək əvəzinə həmin yoxlamanı dəyişə bilər. Son Microsoft sürücüləri default olaraq şifrələyir, ona görə ad uyğunsuzluğu uğurlu TCP bağlantısından sonra sertifikat xətası kimi üzə çıxır. Bu yeni uğursuzluq deyil, irəliləyişdir.
Tərk edilməli mif SQL Server host adının tam ünvan olmasıdır. O, hostdur və adlandırılmış instansiya üçün tunnelin daşımayacağı bir axtarış da əlavə olunur. Portu adlandırın, kəşf yolunu adlandırın və növbəti uğursuzluq hansı qatı düzəltməli olduğunuzu deyəcək.