لا، سلسلة الاتصال لا تستطيع تشغيل نفق VPN الخاص بك

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

خرافة: سلسلة الاتصال يمكنها اختيار النفق

يفتح السائق مقبس TCP إلى مضيف ومنفذ. ليس لديه واجهة برمجية لرفع نفق، ولا حقل لملف تعريف نفق، ولا طريقة للمصادقة على بوابة VPN.

لهذا تتصرف الأدوات بالطريقة نفسها بمجرد وجود مسار. تعمل SSMS وDBeaver وEclipse Data Tools وsqlcmd العادي وكأن الخادم على الشبكة المحلية، لأن ذلك صحيح من منظور المقبس. المحول الافتراضي جعل شبكة قاعدة البيانات الفرعية قابلة للوصول، ولا يعرف السائق كيف حدث ذلك أبدًا.

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

أقم النفق قبل تشغيل السائق

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

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

افحص المسار قبل أن تلوم السائق: إذا لم يُحلّ المضيف أو لم يستجب المنفذ من الصدفة، فلن تغيّر أي سلسلة اتصال ذلك.

خرافة: فشل مصادقة Windows يعني أن المسار معطوب

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

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

يحتفظ المفتاح /netonly بهذه البيانات للمصادقة عن بعد فقط. تحقق مما وصل إلى الخادم فعلًا باستخدام SELECT SUSER_SNAME() بدلًا من الوثوق بمربع حوار الاتصال. يُذكر أن تخزين بيانات اعتماد عنوان الخادم في Windows Credential Manager يعمل مع SSMS لكن ليس دائمًا مع خدمة تعمل تحت حساب مختلف، لذا افحص الهوية التي تستخدمها العملية قبل تغيير تسجيل الدخول.

زمن الاستجابة يحوّل المؤشر من جهة الخادم إلى مهلة

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

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

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

افحص المنفذ والنسخة والمرشح المحلي

تستمع النسخة المسماة على منفذ ديناميكي، لذا تحقق من المنفذ بدلًا من افتراض 1433. في نسخة افتراضية يمكن قراءة القيمة من قيمة التسجيل TcpPort تحت مفتاح SuperSocketNetLib الخاص بالنسخة. بالنسبة إلى Oracle، تحقق من أن المضيف في tnsnames.ora يُحلّ، وأن العنوان يستجيب، وأن منفذ المستمع مسموح؛ و1521 قيمة افتراضية شائعة لا ضمان.

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

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