التقسيم الانتقائي القائم على التطبيق مقابل القائم على الوجهة: أيهما تختار

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

القاعدتان تعملان على طبقتين مختلفتين

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

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

قواعد التطبيق تناسب العملاء المحمولين والعملاء المُدارين

يكشف Android الخيار مباشرة: VpnService.Builder.addAllowedApplication() وaddDisallowedApplication() تأخذان أسماء الحزم وتفرضان القرار لكل UID، كما هو موضح في دليل مطوري VPN في Android. ولدى iOS ما يعادلها عبر قواعد VPN لكل تطبيق مرتبطة بمعرّفات الحزم، تُسلَّم عادةً عبر ملف MDM لا بالكتابة اليدوية.

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

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

قواعد الوجهة تناسب قوائم الشبكات الفرعية ووصول المواقع

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

يبلغ OpenVPN النتيجة نفسها عبر جدول التوجيه المدفوع. يمنع route-nopull الخادم من فرض المسارات، وبعد ذلك يغطي route 10.20.0.0 255.255.0.0 vpn_gateway على جانب العميل بادئة المكتب بالضبط. IPv6 عبارة منفصلة في كل واحد من هؤلاء العملاء، ونسيانها هو الطريقة الأكثر شيوعًا للتسريب حول تقسيم IPv4 يبدو سليمًا.

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

حيث تنكسر كلتا الطريقتين: العمليات المساعدة والخدمات المشتركة والمحلّلات

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

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

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

دليل التشغيل: اختر، طبّق، تحقق

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

طبّق أضيق صيغة تستطيع التعبير عنها، ثم تحقق بسؤال جدول التوجيه لا أيقونة حالة العميل:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

يسمّي السطران الأولان الواجهة التي سيستخدمها وجهة حقيقية؛ wg show يطبع قائمة البادئات المضبوطة؛ وعلى Windows يجيب Find-NetRoute عن السؤال نفسه الذي ستجيب عنه الحزمة عند الإرسال. إذا كانت الواجهة هي النفق، فقد طابقت القاعدة.

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