تغيّر عنوان VPN: لماذا ما زال عميل OpenVPN يتصل بالعنوان القديم

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

انظر إلى ما يتصل به الملف الشخصي، لا إلى ما يقوله DNS

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

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

ملفان، نقطة نهاية واحدة: هذا هو الاستنتاج المعتاد هنا.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

اقرأ محاولة الاتصال التالية للعميل

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

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

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

اعرف أي إعادة تشغيل تقوم بها

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

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

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

الخيارات الأربعة ومهامها المنفصلة

remote مع اسم مضيف هو الإعداد الذي يجعل إعادة الحل ممكنة أصلاً؛ العنوان الحرفي في ذلك السطر يلغيها. يتحكم resolv-retry في ما يحدث عند فشل البحث، والإصدار 2.6 يجعله افتراضياً بلا نهاية. لذا فإن إضافته لا تغيّر شيئاً، وهو لا يجدول أبداً فحصاً دورياً لجواب مختلف. من يقول إنه يستقصي عناوين جديدة فقد خلط بين الاستعادة والحداثة.

persist-remote-ip يتعلق بالاستمرارية لا بالحداثة: إنه يعيد استخدام نقطة النهاية التي صادقت آخر مرة، عبر عمليات إعادة التشغيل الناعمة التي يدعمها. أثناء اختبار نقل، هذا عكس ما تريده. عطّله للاختبار إذا كانت نسختك تفعّله، ثم أعده بمجرد إثبات نقطة النهاية الجديدة. إذا بقي مفعّلاً، فقد لا يخبرك اتصال ناجح بشيء عن DNS.

float يقبل نظيراً مصادقاً تغيّر عنوانه في منتصف الجلسة، وفقط في الترتيبات التي تدعم ذلك. إنه لا يجدّد DNS، ولن يتبع تغيير المزوّد من تلقاء نفسه. تعامل معه كميزة مرونة للنظراء المتجولين، لا كآلية عنوان ديناميكي للخوادم.

أكّد نقطة النهاية الجديدة قبل لوم العميل

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

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

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