هل توجّه مسارات DHCP حركة مرورك خارج نفق VPN؟

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

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

طريقتان يمكن لشبكة أن تؤثر بهما عليك

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

المعدات الواقعة على المسار لا تحتاج مفاتيحك لتؤثر في الحالة الثانية. إنها تحتاج فقط أن يقبل طرفك النهائي مسارًا أو مُحللًا أو قاعدة سياسة تنتج مسارًا.

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

من أين يمكن أن يأتي المسار قبل وجود النفق

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

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

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

افحص المسار الذي تختاره النواة فعليًا

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

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

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

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

قرّر أين يجب أن يكون الإلزام

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

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

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