SQL Server يربط عنوان VPN غير موجود عند الإقلاع

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

ابدأ من سجل بدء التشغيل لا من العميل

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

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

عدّل مسار المثيل وفق تثبيتك، واقرأ قائمة الواجهات قبل استنتاج أي شيء. العنوان الموجود لكن المملوك لمحوّل خاطئ مشكلة مختلفة عن عنوان لم يوجد بعد.

تتبّع ترتيب الربط الذي يتبعه المحرك فعليًا

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

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

اقرأ المستمع كما يقرأه المحرك

في SQL Server Configuration Manager، افتح خصائص TCP/IP للمثيل ولاحظ إعداد Listen All قبل تحرير العناوين الفردية. عندما يكون Listen All على Yes، تُهمَل قيم Enabled لكل عنوان، فتعديلها لا يغيّر شيئًا يستخدمه المستمع. سجّل ثلاثة أمور بالترتيب: العنوان الذي تنوي خدمته، والمنفذ، وهل يُقصد أن يغطي المستمع كل العناوين أو عنوانًا واحدًا فقط. ثم طبّق التغيير عبر إجراء إعادة التشغيل المدعوم واقرأ سجل بدء التشغيل التالي لتتأكد من أن المحرك ربط ما طلبته.

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

امنح العميل وجهة ثابتة

لا يحتاج العميل إلى أن يرتدي مضيف قاعدة البيانات عنوانًا من تجمّع. يعمل التصميم الموجّه بينما يستمع الخادم على عنوانه الخاص الثابت وتوجّه بوابة VPN حركة العميل إليه وتعيد الرد.

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

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

تحقّق من نقطة النهاية التي استخدمها العميل

اختم بفحص على مستوى التطبيق لا باختبار منفذ. اتصل من العميل بالحساب الذي يستخدمه التطبيق واقرأ تفاصيل الاتصال من جهة الخادم، التي تُظهر العنوان المحلي الذي هبطت عليه جلستك.

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"

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