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

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

اقرأ الإعداد الافتراضي من العميل، لا من الكتيّب

يجعل WireGuard القرار ظاهرًا على نحو غير معتاد، لأن AllowedIPs قائمة شمول ولا شيء غير ذلك. النظير الذي يحمل 0.0.0.0/0, ::/0 ينفق كل شيء؛ والنظير الذي يحمل 10.20.0.0/16 ينفق ذلك النطاق وحده. لا توجد صيغة استبعاد، لذا إن أردت استثناء شبكة فرعية واحدة فعليك إما تعداد كل بادئة أخرى أو إضافة توجيه سياسي خارج الواجهة.

OpenVPN يصل إلى النتيجة نفسها من الاتجاه المعاكس، إذ يثبّت redirect-gateway def1 نفقًا كاملًا وتضيف توجيهات route الصريحة بادئات محددة أو تتجاوزها. والعملاء التجاريون يخفون الاثنين عادة خلف مربع اختيار وجدول وجهات، فاقرأ أيّهما يعدّله الجدول فعلًا قبل أن تثق بالعنوان.

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

تتبّع تطبيقًا لم يذكره أحد

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

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

QuestionInclude-onlyExclude-only
Unlisted new appgoes directgoes through the tunnel
A site that breaks over the VPNadd it to the listcarve it out
Internal names still resolveonly if routed and servedusually, until split DNS says otherwise
Upkeepone entry per internal serviceone entry per misbehaving public service

لاحظ نوع الكائن الذي تسرده المنصة

يكشف VpnService.Builder في Android عن قائمة تطبيقات مسموحة وقائمة تطبيقات ممنوعة كنموذجين منفصلين، وقواعد كل تطبيق تختار بحسب الحزمة لا بحسب الوجهة. والمتصفح الموضوع في قائمة كهذه يحمل كل وجهة يفتحها، وهي حبيبية مختلفة عن جدول مسارات ولا يمكنها إصلاح موقع معطل واحد داخل تطبيق عامل.

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

اختبر حالة الفشل، لا المسار السعيد وحده

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

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

دوّن الإعداد الافتراضي حيث يجده الشخص التالي

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

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

مقالات ذات صلة