لماذا توقفت قاعدة النفق المنقسم عن مطابقة إحدى الخدمات

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

ما الذي تثبّته القاعدة وما الذي يعيده DNS

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

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

ثلاث طرق تنكسر بها المطابقة

الحالة الواضحة هي خدمة انتقلت: أعاد المشغّل تعيين عنوانها، فتبع DNS، ولم يتبع الاستثناء. والثانية عائلة عناوين لم تغطّها القاعدة قط، وهذا يحدث عندما يبدأ اسم في إرجاع سجلات AAAA يتجاهلها استثناء يعمل بـ v4 فقط. والثالثة فرق في المُحلِّل: يمكن أن تعيد رؤية داخلية ورؤية عامة عنوانين مختلفين للاسم نفسه، فلا يكون العنوان الذي يستخدمه تطبيقك هو الذي اختبرت به.

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

اقرأ الوجهة التي يستخدمها التطبيق فعلاً

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

أصلح الآلية لا العَرَض

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

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

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

تحقّق من نصفي النية

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

دوّن العنوان الجديد والآلية التي اخترتها والتاريخ. تلك الملاحظة هي ما يمنع الشخص التالي من الاستنتاج بأن VPN تجاهل إعداداته عشوائياً.