النفق المنقسم: لماذا يُفتح الرابط خارج الشبكة الافتراضية التي أعددتها
يتبع التوجيه العملية التي تفتح المقبس، لا التطبيق الذي عرض عليك الرابط. أثبت أي برنامج يتصل قبل أن توسّع استثناءاتك.
توجيه تطبيق عبر النفق لا ينقل قواعد التوجيه مع كل ما يطلقه ذلك التطبيق، حتى لو كانت الواجهة توحي بغير ذلك. الرابط يسلّم الطلب إلى برنامج آخر، وذلك البرنامج يفتح مقبسه الخاص، فتُطبّق المنصة القواعد على العملية الجديدة لا على العملية التي عرضت النص. تلك العملية الثانية هي ما تراه سياسة النفق فعلاً، وهي ليست التي أعددتها.
لذلك يمكن لتطبيق مشمول أن يفتح متصفحاً يقف خارج النفق. ويمكن لمتصفح مستثنى أن يعيد العمل إلى تطبيق يقف داخله. وكلا الاتجاهين في هذه المفاجأة سلوك عادي.
الجزء من سير العمل الذي لم يعدّه أحد
تُكتب السياسة لكل تطبيق مقابل هوية ملف تنفيذي أو حزمة، ويُقيَّم كل اتصال لحظة إنشائه. فالمتصفح وعارض المستندات ومشغل الوسائط وورقة المشاركة في النظام يحمل كل منها هويته الخاصة، ويحصل كل منها على حكمه الخاص. والرابط العميق يحمل بيانات، لا سياسة.
ولهذا تبدو الملاحظة اعتباطية: النقرة نفسها تتجه اتجاهين حسب المعالج الذي يستجيب لها. عميل بريد داخل النفق يفتح رابطاً في متصفح يعيش خارج النفق، فتُحمَّل الصفحة من عنوان منزلك. ومتصفح خارج النفق يفتح مستنداً في عارض يعيش داخله، فيصل الملف عبر المخرج. ولا واحدة من النتيجتين عيب في العميل.
المعالج الذي يعمل مسبقاً يزيد الأمر سوءاً. إذا كان المتصفح مفتوحاً بالفعل، يتحول الرابط إلى رسالة إلى عملية قائمة، وتلك العملية تحتفظ بالتوجيه الذي كان لها عند بدئها. وإغلاق المعالج وإعادة فتحه يغيّر النتيجة، ولهذا لا تتكرر المشكلة أبداً عند الطلب.
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
أي عملية أنشأت الاتصال فعلاً
قِس الجانب المستقبِل بدل أن تستنتج عنه. أبقِ النفق قائماً، وانقر رابطاً غير ضار، وانظر إلى المقابس التي يحملها البرنامج الجديد.
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
الأمر الأول يسمّي العملية وراء كل مقبس قائم على لينكس، والثاني يفعل الشيء نفسه على ويندوز بحلّ معرّف العملية المالكة. قارن اسم العملية بالأسماء في سياستك. فإن كان الاسم هو المتصفح وكان المتصفح مستثنى، فقد خرجت النقرة من النفق بالتصميم لا بالخطأ. ومطابقة قاعدة سياسة بمقبس حي هي الطريقة كلها.
أعد الفحص والمعالج يعمل مسبقاً، ثم وهو مغلق. قد تختلف النتيجتان، وهذا الاختلاف يفسّر معظم التقارير المتقطعة عن روابط تفلت من النفق.
التغطية خاصية من خصائص سير العمل
إذا كان على مهمة أن تبقى داخل النفق من البداية إلى النهاية، فكل مكوّن يمكنها الوصول إليه يحتاج إلى أن يكون داخل السياسة: المشغّل، والمعالج، والعارض، وأي وسيط تُدخله المنصة بينها. والتغطية الأوسع غالباً هي الجواب الصادق، وهي أرخص من تدقيق كل هدف مشاركة.
استثناء وسيط نظام لإصلاح تطبيق واحد خطأ شائع. الوسطاء مشتركون، فيتبع الاستثناء كل تطبيق آخر يستخدم المسار نفسه، عادةً دون أن يلاحظ أحد ذلك حتى يصل تقرير بعد أسابيع. اقرأ ما يعتمد أيضاً على المكوّن قبل أن تستثنيه.
افصل الهوية عن التوجيه كذلك. يمكن للرابط أن يحمل رمز جلسة أو معرّف حساب بغض النظر عن المخرج الذي يتلقى الطلب. والنقرة الموجّهة بشكل صحيح يمكنها مع ذلك أن تخبر الوجهة بمن تبعها بالضبط.
وثّق سير العمل، لا أول مربع اختيار. عندما تمتد مهمة عبر أربعة برامج، فالمخطط الذي يحمل أربعة برامج هو الذي يتوقع أين يذهب المرور، وإعداد التطبيق الواحد ليس إلا صفاً واحداً منه.