SQL Server yuklanishda mavjud bo‘lmagan VPN manziliga bog‘lanadi

Xizmat hali ishlab turgan paytda muvaffaqiyatsiz bog‘lanish haqidagi SQL Server jurnal satrini o‘qing va siz halokat emas, yuklanish tartibiga bog‘liqlikni topdingiz. Aynan shu birikma ishoradir: dvigatel tinglashi buyurilgan manzil mashinada paydo bo‘lishidan oldin ishga tushgan. Kirishdan keyin ko‘tariladigan VPN adapteri nazoratsiz ma’lumotlar bazasi xizmati uchun yomon shartdir, shuning uchun nosozlikni dvigatel ko‘radigan tartibda kuzatib boring.

Mijozdan emas, ishga tushish jurnalidan boshlang

Nusxa xato jurnalini oching va faqat oxirgi satrni emas, tarmoq ishga tushirilishi atrofidagi yozuvlarni o‘qing. Dvigatel qaysi manzillarni sinab ko‘rgani va qaysi protokollarni yoqqanini bildiradi, va bu yozuv har qanday mijoz ulanishidan oldingi. Endi xostda hozir nima borligini ko‘ring. Agar sozlangan manzilga ega interfeys foydalanuvchi kirib, mijozni ishga tushirgandan keyingina paydo bo‘lsa, manzil yuklanishda yo‘q edi va bog‘lanish nosozligi to‘liq tushuntiriladi.

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

Nusxa yo‘lini o‘z o‘rnatishingizga moslang va xulosa qilishdan oldin interfeyslar ro‘yxatini o‘qing. Mavjud, lekin noto‘g‘ri adapterga tegishli manzil hali mavjud bo‘lmagan manzildan boshqa muammo.

Dvigatel amalda amal qiladigan bog‘lanish tartibini bosib o‘ting

Dvigatel tinglovchi konfiguratsiyasini o‘qiydi, so‘ng operatsion tizimdan bog‘lanishni so‘raydi. Agar manzil o‘sha paytda mahalliy bo‘lmasa, o‘sha manzil uchun bog‘lanish muvaffaqiyatsiz bo‘ladi, nusxaning qolgan qismi odatdagidek davom etishi mumkin. Shuning uchun boshqa protokollar yoki boshqa manzillar hali ham ishlashi mumkin, va shuning uchun „SQL Server ishlamayapti“ noto‘g‘ri xulosa. Jurnaldan aniq oxirgi nuqtani saqlang: manzil, port va protokol, chunki tuzatish uchtadan qaysi biri noto‘g‘ri ekanligiga bog‘liq.

Adapter paydo bo‘lgandan keyin xizmatni qayta ishga tushirish odatda tinglovchini muvaffaqiyatli qiladi va aynan shu tuzoq. Bu bog‘liqlikni olib tashlash o‘rniga isbotlaydi va tunnel har safar qayta ulanganda har bir ulangan foydalanuvchini uzadi.

Tinglovchini dvigatel o‘qiganidek o‘qing

SQL Server Configuration Manager da nusxa TCP/IP xususiyatlarini oching va alohida manzillarni tahrirlashdan oldin Listen All sozlamasiga e’tibor bering. Listen All Yes bo‘lganda har bir manzil uchun Enabled qiymatlari e’tiborsiz qoldiriladi, shuning uchun ularni tahrirlash tinglovchi ishlatadigan hech narsani o‘zgartirmaydi. Uch narsani tartib bilan yozib oling: xizmat ko‘rsatmoqchi bo‘lgan manzil, port va tinglovchi barcha manzillarni yoki faqat bittasini qamrab olishi kerakmi. So‘ng o‘zgartirishni qo‘llab-quvvatlanadigan qayta ishga tushirish tartibi orqali qo‘llang va dvigatel siz so‘ragan narsani bog‘laganini tasdiqlash uchun keyingi ishga tushish jurnalini o‘qing.

Har bir manzilda tinglash kirishni boshqarish emas. Agar haqiqatan keng tinglovchi kerak bo‘lsa, har bir erishiladigan interfeys o‘zining tarmoq devori va ma’lumotlar bazasi ruxsati qaroriga muhtoj, internetga qaragan har qanday interfeys ham.

Mijozga barqaror manzil bering

Mijoz ma’lumotlar bazasi xosti pul manzilini kiyishini talab qilmaydi. Marshrutlangan dizayn server o‘zining barqaror shaxsiy manzilida tinglaganda ishlaydi, VPN shlyuzi esa mijoz trafigini unga yo‘naltirib javobni qaytaradi.

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

Agar mijoz 10.80.0.15 ga yetsa, yo‘l isbotlangan va ma’lumotlar bazasi faqat shu mijozga ruxsat berishi kerak. Yetmasa, tinglovchiga qayta tegishdan oldin marshrutlash va DNS ni tuzating, chunki serverdagi bog‘lanish muammosi mijozning uni topa olmasligiga hech qachon sabab bo‘lmagan. Serverga soxta pul manzili yoki tinglovchini xursand qilish uchun ikkinchi standart shlyuz qo‘shish eskisining ustiga yangi tarmoq muammosini yaratadi. Server manzillashini statik saqlang va tunnel mijozlarni unga yetkazsin.

Mijoz ishlatgan oxirgi nuqtani tekshiring

Port sinovi o‘rniga amaliyot darajasidagi tekshiruv bilan yakunlang. Mijozdan amaliyot ishlatadigan hisob bilan ulanib, server tomonidagi ulanish tafsilotlarini o‘qing, ular sessiyangiz tushgan mahalliy manzilni ko‘rsatadi.

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"

Bu manzilni sozlagan tinglovchingiz bilan solishtiring. Nomuvofiqlik ikkinchi tinglovchi yoki kutilmagan joyda hal qilinadigan nom demakdir, va keyingi qayta yuklash tuzatishingizni sizning o‘rningizda sinashdan oldin ikkalasini ham bilish arziydi. So‘ng xostni kirgan foydalanuvchisiz qayta yuklang va bog‘lanish muvaffaqiyatli ekanini tasdiqlang. O‘sha bitta sinov tuzatilgan tinglovchi va keyingi yamoq kechasida muvaffaqiyatsiz bo‘ladigan vaqtinchalik yechim o‘rtasidagi farqdir.