SQL Server yükləmə zamanı mövcud olmayan VPN ünvanına bağlanır

Xidmət hələ işləyərkən uğursuz bağlanma haqqında SQL Server jurnal sətrini oxuyun və siz qəza deyil, yükləmə ardıcıllığından asılılıq tapdınız. Bu birləşmə ipucudur: mühərrik dinləməli olduğu ünvan maşında mövcud olmadan əvvəl başlamışdı. Girişdən sonra qalxan VPN adapteri nəzarətsiz verilənlər bazası xidməti üçün zəif ilkin şərtdir, ona görə uğursuzluğu mühərrikin gördüyü sıra ilə izləyin.

Müştəridən deyil, başlanğıc jurnalından başlayın

İnstansiyanın səhv jurnalını açın və yalnız sonuncu sətri deyil, şəbəkə işə salınması ətrafındakı qeydləri oxuyun. Mühərrik hansı ünvanları sınadığını və hansı protokolları aktivləşdirdiyini bildirir və bu qeyd hər hansı müştəri qoşulmadan əvvəlkindir. İndi hostda hazırda nə olduğuna baxın. Əgər konfiqurasiya edilmiş ünvana sahib interfeys yalnız istifadəçi daxil olub müştəri başlatdıqdan sonra görünürsə, ünvan yükləmə zamanı yox idi və bağlanma xətası tam izah olunur.

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

İnstansiya yolunu quraşdırmanıza uyğunlaşdırın və nəticə çıxarmazdan əvvəl interfeys siyahısını oxuyun. Mövcud olan, lakin səhv adapterə aid ünvan hələ mövcud olmayan ünvandan fərqli problemdir.

Mühərrikin həqiqətən izlədiyi bağlanma sırasını addımlayın

Mühərrik dinləyici konfiqurasiyasını oxuyur, sonra əməliyyat sistemindən bağlanmağı xahiş edir. Əgər ünvan o anda lokal deyilsə, instansiyanın qalan hissəsi normal davam edə bilsə də, həmin ünvan üçün bağlanma uğursuz olur. Buna görə digər protokollar və ya digər ünvanlar hələ də işləyə bilər və buna görə «SQL Server işləmir» yanlış xülasədir. Jurnaldakı dəqiq son nöqtəni qoruyun: ünvan, port və protokol, çünki düzəliş üçündən hansının səhv olduğundan asılıdır.

Adapter göründükdən sonra xidməti yenidən başlatmaq adətən dinləyicini uğurlu edir və bu, məhz tələdir. Bu, asılılığı aradan qaldırmaq əvəzinə sübut edir və tunel hər dəfə yenidən qoşulanda bütün qoşulmuş istifadəçiləri kəsir.

Dinləyicini mühərrikin oxuduğu kimi oxuyun

SQL Server Configuration Manager-də instansiyanın TCP/IP xassələrini açın və ayrı-ayrı ünvanları redaktə etməzdən əvvəl Listen All parametrini qeyd edin. Listen All Yes olduqda, hər ünvan üzrə Enabled dəyərləri nəzərə alınmır, ona görə onları redaktə etmək dinləyicinin istifadə etdiyi heç nəyi dəyişmir. Üç şeyi sıra ilə qeyd edin: xidmət etmək istədiyiniz ünvan, port və dinləyicinin bütün ünvanları yoxsa yalnız birini əhatə etməli olduğunu. Sonra dəyişikliyi dəstəklənən yenidən başlatma proseduru ilə tətbiq edin və mühərrikin istədiyinizi bağladığını təsdiqləmək üçün növbəti başlanğıc jurnalını oxuyun.

Hər ünvanda dinləmək giriş nəzarəti deyil. Geniş dinləyici həqiqətən tələb olunursa, hər əlçatan interfeys öz firewall və verilənlər bazası avtorizasiyası qərarına ehtiyac duyur, internetə baxan hər hansı interfeys də daxil olmaqla.

Müştəriyə sabit təyinat verin

Müştərinin verilənlər bazası hostunun hovuz ünvanı daşımasına ehtiyacı yoxdur. Marşrutlaşdırılmış dizayn server sabit özəl ünvanında dinləyərkən, VPN şlüzü müştərinin trafikini ona yönləndirib cavabı geri daşıyır.

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

Əgər müştəri 10.80.0.15-ə çatırsa, yol sübut olunub və verilənlər bazası yalnız həmin müştəriyə icazə verməlidir. Çatmırsa, dinləyiciyə yenidən toxunmazdan əvvəl marşrutlaşdırmanı və DNS-i düzəldin, çünki serverdəki bağlanma problemi heç vaxt müştərinin onu tapa bilməməsinin səbəbi deyildi. Serverə saxta hovuz ünvanı, ya da dinləyicini razı salmaq üçün ikinci defolt şlüz əlavə etmək köhnənin üstünə yeni şəbəkə problemi yaradır. Serverin ünvanlaşdırmasını statik saxlayın və tunelin müştəriləri ona çatdırmasına icazə verin.

Müştərinin istifadə etdiyi son nöqtəni yoxlayın

Port testi deyil, tətbiq səviyyəsində yoxlama ilə bitirin. Müştəridən tətbiqin istifadə etdiyi hesabla qoşulun və sessiyanızın hansı yerli ünvana düşdüyünü göstərən server tərəfli əlaqə detallarını oxuyun.

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"

Həmin ünvanı konfiqurasiya etdiyiniz dinləyici ilə müqayisə edin. Uyğunsuzluq ikinci dinləyici və ya gözlənilməz yerdə həll olunan ad deməkdir və hər ikisi növbəti yenidən başlatmanın düzəlişinizi sizin əvəzinizə yoxlamasından əvvəl bilinməyə dəyər. Sonra hostu heç bir istifadəçi daxil olmadan yenidən başladın və bağlanmanın uğurlu olduğunu təsdiqləyin. Bu tək test təmir edilmiş dinləyici ilə növbəti yamaq gecəsində uğursuz olan müvəqqəti həll arasındakı fərqdir.