هل ما زال الوكيل على عنوان النفق القديم بعد إعادة اتصال VPN؟

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

هذا الفشل الثاني هو الأخطر: النفق قائم، والصفحات تُحمَّل، والعنوان الخارجي وحده هو الخطأ.

ابدأ من المستمع، لا من النفق

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

البحث عن IP العام يجيب عن السؤال الأخير فقط. ولا يمكنه أن يخبرك بالعنوان المحلي الذي ينبغي للمُمرِّر أن يرتبط به، لأن خروجًا عامًا واحدًا قد يخفي عدة مصادر داخلية. اقرأ العنوان ممن يملك الاتصال: مخرجات حالة العميل، أو الواجهة نفسها، أو مساحة الأسماء التي يعيش فيها النفق. أما أخذ أول واجهة يبدو اسمها كنفق فيعطي جوابًا خاطئًا بمجرد وجود ملف تعريف ثانٍ.

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

أربعة فحوص قبل أن تعدّل أي شيء

امضِ في هذه بالترتيب. أول فحص يفشل هو مكان توقفك، لأن الفحوص اللاحقة تفترض أن السابقة سليمة.

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

عنوان الجهاز سهل: ip -4 addr show dev tun0 يطبع العنوان الحالي، ثم يعرض ip -4 route get 1.1.1.1 الواجهة التي ستختارها النواة لذلك الهدف. والمُمرِّر الذي يرتبط بعنوان محدد يفشل بصوت عالٍ عندما يختفي العنوان. أما الذي يرتبط بجهاز، أو يتراجع إلى المصدر الافتراضي، فيبقى يعمل ويُسرّب، وهذه هي النتيجة الصامتة.

طابق التوثيق مع الإصدار الذي تشغّله، لا مع أول نتيجة بحث. فتعليمة العنوان الصادر في Squid موثّقة حتى الإصدار v7، وتوثيق v8 ينص صراحة على أن التعليمة غير متاحة هناك، لذا لا يعبر سكربت مبني عليها تلك الحدود (انظر مرجع Squid tcp_outgoing_address). تحقق بمحلل المنتج نفسه قبل إعادة تحميل أي شيء: squid -k parse يبلّغ عن الأخطاء ويخرج دون أن يمس العملية الجارية.

رقّم كل نفق واطرح التبديلات القديمة

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

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

المقابس المفتوحة لن تتبع العنوان الجديد

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

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

أثبت الخروج الجديد بطلب جديد

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

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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