كيف يحدد النفق المنقسم أي حركة مرور تستخدم VPN

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

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

العميل يثبّت القواعد والنواة تتخذ القرار

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

لهذا قد يبدو النفق المنقسم عشوائيًا۔ قد تتخذ وجهتان في تطبيق واحد مسارين مختلفين لمجرد أن إحدى البادئتين أضيق من الأخرى۔

الاختيار نفسه موجود على كل منصة، وإن تغيّرت الأسماء۔ يدفع Windows القرار إلى منصة الفلترة الخاصة به، ويعرض Android قائمة سماح لكل تطبيق عبر خدمة VPN، ويربط macOS النفق بجهاز ما يزال يطيع جدول التوجيه۔ ملاحظات التوجيه من Microsoft جديرة بالقراءة في حالة Windows، والدليل المكتوب لمنصة واحدة نادرًا ما ينتقل دون تغيير إلى أخرى۔

ربط التطبيقات وبادئات الوجهة أداتان مختلفتان

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

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

DNS ومفتاح الإيقاف يتبعان قواعدهما الخاصة

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

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

افحص الانقسام من الجانبين

اختبر المسار المشمول والمسار المستبعد كلًا على حدة، واحكم على النتيجة باسم الواجهة لا بعنوان عام۔ تفترض هذه الأوامر مضيف Linux وجهاز النفق قائمًا بالفعل۔ استبدل 203.0.113.10 بوجهة توجّه سياستك إليها الداخل، و198.51.100.25 بواحدة ترسلها إلى الخارج۔

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

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

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