المثيل المُسمّى من SQL Server عبر VPN: الاكتشاف، لا المنفذ 1433

يتعامل معظم الناس مع اسم مضيف SQL Server كعنوان كامل، ومع VPN كإما مسموح أو غير مسموح. في الواقع، يجعل المثيل المُسمّى العميل يُجري بحثًا ثانيًا بعد DNS، وهذا البحث هو الجزء الذي ينكسر في النفق أكثر ما ينكسر. نقطة نهاية صريحة تتجاوز ذلك، ولهذا قد يعمل tcp:host,port بينما ينتهي host\INSTANCE بمهلة. الفرق بين العثور على الخدمة والسماح باستخدامها.

الأسطورة: اسم مضيف واحد يعني منفذًا واحدًا

يُحلّ اسم المضيف إلى عنوان، وهنا تنتهي مهمته. يضيف المثيل المُسمّى اسم مثيل يجب على الخادم ترجمته إلى منفذ TCP، ولا يستطيع العميل تخمينه. المنفذ 1433 هو الافتراضي لمثيل افتراضي، وليس خاصية لكل مثيل على الجهاز. التعامل مع الاثنين كأنهما الشيء نفسه ينتج العَرَض الكلاسيكي: ping يعمل، وDNS يعمل، وفحص 1433 لا يُظهر شيئًا، والاستنتاج أن الشبكة تحجب SQL.

يفشل افتراض ثانٍ بالطريقة نفسها: أن فتح TCP 1433 يكفي. إذا كان المثيل يستمع في مكان آخر، فإن 1433 المفتوح لا يُثبت إلا أن شيئًا آخر موجود هناك. يجب أن يطابق المنفذ المستمع، فالمستمع تفصيل في إعدادات جهة الخادم ينبغي أن تسأل عنه بدلًا من أن تستنتجه.

ما يفعله العميل فعليًا مع مثيل مُسمّى

بعد حل اسم المضيف، يرسل العميل طلب اكتشاف إلى SQL Server Browser على UDP 1434 ويسأل عن المنفذ الذي يستخدمه المثيل المُسمّى. تُجيب خدمة المتصفح من سجل الخادم نفسه، ثم يفتح العميل اتصال TCP بذلك المنفذ. بروتوكولان ومنفذان يتدخلان قبل أن تُحاوَل عملية تسجيل الدخول أصلًا.

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

لهذا يُنتج الحجب على UDP فقط مهلة تبدو كخادم ميت. إذا كانت خدمة المتصفح متوقفة أو معطّلة، يبقى طلب الاكتشاف بلا جواب رغم أن محرك قاعدة البيانات يعمل ومنفذ TCP الخاص به مفتوح. وإذا كان المثيل مُهيّأ على منفذ ثابت، فسيظل العميل يسأل ما لم تُعطَه نقطة النهاية مباشرة. كل واحد من هذه الإخفاقات يبدو متطابقًا في رسالة خطأ التطبيق، وهي تحتاج إلى إصلاحات مختلفة.

خدمة المتصفح تسهيل للاكتشاف، وليست قاعدة البيانات. إيقافها لا يوقف المحرك، وبدءها لا يفتح منفذ TCP الخاص بالمثيل.

لماذا تعمل نقطة النهاية الصريحة عندما لا يعمل الاسم

نقطة النهاية الصريحة تُزيل البحث من التسلسل: يتصل العميل مباشرة بالعنوان والمنفذ الذي سميته. هذا تشخيص أولًا، وليس إصلاحًا دائمًا تلقائيًا، لأن المنفذ قد يتغير إذا أُعيد تهيئة المثيل لاحقًا إلى منفذ ديناميكي. قارن الشكلين بالعميل نفسه والحساب نفسه قبل أن تستنتج.

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

إذا نجح الشكل الصريح وفشل الشكل المُسمّى، فالاكتشاف هو الفجوة، ويمكنك أن تختار كيف تسدّها: اسمح بمرور UDP 1434 عبر النفق، أو اطلب من المسؤول تثبيت منفذ ثابت وتوثيق نقطة النهاية. كلاهما قراران مقصودان بتكاليف صيانة مختلفة. فتح كل منفذ في النطاق ليس واحدًا منهما، وهو الخيار الذي يُقترح عادة في نهاية يوم طويل. سجّل الاختيار حيث تعيش سلاسل الاتصال.

إذا لم يعمل أي من الشكلين، فالمشكلة تقع في اتجاه المنبع قبل الاكتشاف. تحقق من المستمع والمسار وقاعدة الوصول للمنفذ الذي يستخدمه المثيل فعليًا قبل أن تلوم خدمة المتصفح.

بعد الاكتشاف: المصادقة والهوية مسألتان منفصلتان

فشل تسجيل الدخول حدث مختلف عن المهلة، وهوية VPN لا تصبح تسجيل دخول SQL بمجرد وجود النفق. عندما يصل العميل إلى المنفذ الصحيح، يطبّق محرك قاعدة البيانات مصادقته وأذوناته الخاصة. خلط المرحلتين في تذكرة واحدة هو كيف تُسنَد مشكلة اكتشاف إلى الفريق الخطأ. اقرأ رقم الخطأ قبل أن تغيّر أي شيء.

أبقِ على اسم المضيف الموثّق إذا كان المشغّل يتحقق من شهادة الخادم، لأن الاتصال بالعنوان الرقمي قد يغيّر ذلك التحقق بدلًا من أن يحل المشكلة الأصلية. مشغّلات Microsoft الحديثة تشفّر افتراضيًا، لذا يظهر عدم تطابق الاسم كخطأ شهادة بعد اتصال TCP ناجح. ذلك تقدّم وليس فشلًا جديدًا.

الأسطورة التي يجب التخلي عنها هي أن اسم مضيف SQL Server عنوان كامل. إنه مضيف، بالإضافة إلى بحث قد لا يحمله النفق في حالة المثيل المُسمّى. سمِّ المنفذ، وسمِّ مسار الاكتشاف، وسيخبرك الإخفاق التالي أي طبقة تُصلح.