Split Tunneling في VPN: متى يفيد تمرير تطبيق واحد ومتى تصبح المهمة الكاملة أهم من قائمة الاستثناءات؟

في البداية، بدا Split Tunneling كأنه الحل الدقيق لمشكلتي.

كنت أريد تطبيق العمل عبر الـVPN.

ولا أريد تطبيق البنك عبره.

ولا خدمة التوصيل المحلية.

ولا المواقع التي أحتاج أن تراني على اتصالي المحلي المعتاد.

الفكرة نفسها بسيطة: بعض تطبيقات VPN على Android تستطيع تحديد التطبيقات التي تمر عبر النفق، أو استثناء تطبيقات منه لتستخدم الاتصال العادي. (Android Developers)

لذلك صنعت القاعدة التي بدت مثالية:

تطبيق العمل → VPN.

البنك → اتصال مباشر.

الخدمات المحلية → اتصال مباشر.

ضغطت Connect.

فتحت البنك.

عمل.

فتحت خدمة محلية.

عملت أيضًا.

ثم فتحت تطبيق العمل.

وهنا بدأت الخطة تتفكك.

«تطبيق واحد» لم يكن في الحقيقة تطبيقًا واحدًا

وصلت إلى شاشة تسجيل الدخول داخل تطبيق العمل.

ضغطت Continue.

فُتح المتصفح.

لكن المتصفح لم يكن ضمن التطبيقات التي مررتها عبر النفق.

أكملت تسجيل الدخول وعدت إلى التطبيق.

بعدها ضغطت ملفًا داخل المشروع.

فُتح تطبيق التخزين السحابي.

هو أيضًا خارج النفق.

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

المشكلة لم تكن أن الميزة فشلت.

المشكلة أنني كنت أسأل:

أي تطبيق يجب أن يمر عبر الـVPN؟

بينما السؤال الأصح كان:

ما الذي تتكون منه المهمة التي أريد تمريرها؟

وهذا فرق صغير في الصياغة، لكنه غيّر الطريقة التي استخدمت بها الـVPN كله.

Split Tunneling ممتاز عندما تكون الحدود واضحة

الميزة نفسها مفيدة جدًا.

مزودون كبار يدعمون استثناء تطبيقات من النفق، وبعضهم يتيح أيضًا العكس: تحديد التطبيقات التي يجب أن تمر عبره فقط. (Proton VPN)

إذا كانت مهمتي بسيطة، فهذا رائع.

لعبة واحدة عبر اتصال مباشر.

تطبيق معين داخل الـVPN.

البنك خارج النفق.

خدمة محلية مباشرة.

انتهى الأمر.

لكن تطبيق العمل الذي أمامي لم يكن جزيرة منفصلة.

كان التطبيق يفتح متصفحًا للمصادقة.

المتصفح يعيدني إلى التطبيق.

الملف ينتقل إلى خدمة سحابية.

ورابط الاجتماع قد يفتح برنامجًا آخر.

كلما أضفت استثناء أو تطبيقًا جديدًا، ظهرت خطوة أخرى لم أفكر فيها.

وهنا بدأ التحكم الدقيق يتحول إلى عبء تشخيصي.

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

لم أكن أستثني البنك لأن الخدمات المالية «لا تعمل مع VPN» كقاعدة عامة.

لكن بعض العمليات المالية قد تطلب سياق اتصال محليًا أكثر مباشرة. Wise، مثلًا، تنصح بإيقاف VPN عند بعض مشكلات CAPTCHA، وتمنع استخدامه في عملية Video KYC محددة تتطلب وجود المستخدم فعليًا داخل الهند. (Wise Help Centre)

بالنسبة لي، النتيجة العملية أبسط.

إذا كنت سأدفع فاتورة محلية أو أراجع حسابي البنكي، فلا أحتاج إلى تمرير هذه المهمة عبر موقع خروج خارجي لمجرد أن جلسة العمل الأخرى تحتاج VPN.

لذلك كان إبقاء البنك والخدمات المحلية مباشرة منطقيًا.

المشكلة بدأت عندما حاولت في الوقت نفسه رسم حدود يدوية حول كل جزء صغير من جلسة العمل.

المزود الكبير أعطاني تحكمًا دقيقًا جدًا

وهذه كانت قوته الحقيقية.

واجهة Split Tunneling واضحة.

أضفت البنك إلى الاستثناءات.

أضفت التطبيق المحلي.

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

ثم اكتشفت أن المتصفح يحتاج إلى المرور معه.

أضفته.

لكن عندها أصبح تصفحي العادي أيضًا داخل الـVPN.

فقلت: سأخصص متصفحًا ثانيًا للعمل.

نجح ذلك.

ثم ظهر تطبيق التخزين السحابي.

أضفته أيضًا.

وبعد قليل أصبحت القائمة تعمل، لكنني أنا الذي أصبحت أديرها.

كلما تغيرت المهمة، تغيرت القاعدة.

وكلما استدعى التطبيق خدمة أخرى، كان عليّ أن أعرف مسبقًا أي طريق يجب أن تسلكه.

هنا لم أعد أبحث عن تحكم أكبر.

كنت أبحث عن عدد أقل من القرارات أثناء العمل.

تجربة المستخدمين أكدت لي الجزء البسيط فقط

في نقاشات المستخدمين، يظهر Split Tunneling كثيرًا كحل عندما يتوقف موقع أو تطبيق محدد مع VPN: يُستثنى من النفق ويعود إلى الاتصال المباشر. (Reddit)

وهذه نقطة مفيدة بما يكفي.

إذا كان لدي استثناء واحد واضح، فالميزة ممتازة.

أما إذا كانت المهمة نفسها تقفز باستمرار بين تطبيقات متعددة، فإن القائمة تبدأ بالنمو أسرع من المشكلة.

وهذا هو بالضبط ما كان يحدث معي.

عندها قسمت المهمة بدل أن أقسم التطبيقات

فتحت التطبيق الأصغر.

لم أحاول إعادة بناء جدول توجيه جديد.

شغلت الاتصال عندما بدأت جلسة العمل.

ثم تركت المهمة كلها تمشي بالطريق نفسه.

فتحت تطبيق العمل.

انتقلت إلى صفحة تسجيل الدخول في المتصفح.

عدت إلى لوحة المشروع.

فتحت التخزين السحابي.

نزلت الملف.

عدلت النسخة.

رفعتها.

ظهر تأكيد اكتمال الرفع.

ثم دخلت اجتماعًا قصيرًا.

اتصل.

هذه المرة لم أحتج أثناء المهمة إلى التوقف والسؤال:

هل هذا التطبيق موجود في القائمة؟

هل المتصفح داخل النفق؟

هل خدمة التخزين مستثناة؟

المهمة كلها بقيت متماسكة.

وهذا كان أهم بالنسبة لي من التحكم بتطبيقاتها واحدًا واحدًا.

وبعد انتهاء العمل، خرجت من النفق

هنا ظهر الجزء الذي جعل الطريقة مناسبة لي.

انتهيت من رفع الملف والاجتماع.

فصلت الاتصال.

فتحت البنك.

دفعت الفاتورة.

ثم فتحت خدمة محلية.

وعادت التطبيقات إلى الاتصال العادي.

لم يكن هذا Split Tunneling متزامنًا.

ولم أحاول تقديمه كبديل تقني مطابق له.

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

وهذا هو التحول الذي لم أتوقعه عندما بدأت.

كنت أظن أن التحكم الأدق هو دائمًا الخيار الأفضل.

ثم اكتشفت أن التحكم الأدق يصبح أقل راحة عندما تكون حدود المهمة نفسها غير واضحة.

الواجهة القائمة على الحالة ساعدت هنا أكثر من قائمة الشبكات

التطبيق الأصغر مصمم حول ما أحاول فعله، بدل أن يبدأ من الجغرافيا والتفاصيل الشبكية.

وهذا جعل الاستخدام القصير حسب الحاجة عمليًا.

أبدأ جلسة العمل.

أشغل الاتصال.

أكمل المهمة.

ثم أعود إلى اتصالي المحلي للبنك والخدمات القريبة.

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

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

وفي حالتي، هذا قلل الأخطاء أكثر من إضافة قاعدة توجيه أخرى.

لكنني لم أتخل عن Split Tunneling

أعدت الاختبار لاحقًا بمهمة مختلفة.

هذه المرة كان لدي تطبيق مستقل.

لا يفتح متصفحًا للمصادقة.

لا يرسلني إلى تطبيق تخزين.

ولا يستدعي خدمة ثانية.

مررته وحده عبر Split Tunneling في المزود الكبير.

أبقيت البنك وكل الخدمات المحلية خارجه.

وعمل الأمر تمامًا كما ينبغي.

وهنا أصبح الحكم واضحًا:

إذا كانت حدود التطبيق هي حدود المهمة، فـSplit Tunneling ممتاز.

أما إذا كانت أيقونة واحدة تفتح نصف النظام أثناء العمل، فعبارة «مرر تطبيقًا واحدًا» تصبح أقل دقة مما تبدو.

لذلك أصبحت أختبر المهمة قبل بناء الاستثناءات

قبل أن أفتح قائمة Split Tunneling، أسأل نفسي:

هل المهمة فعلًا داخل تطبيق واحد؟

أم أن التطبيق سيفتح المتصفح؟

هل سيستدعي خدمة تخزين؟

هل تسجيل الدخول منفصل؟

هل الاجتماع يفتح تطبيقًا آخر؟

إذا كانت السلسلة قصيرة وواضحة، أستخدم التوجيه حسب التطبيق.

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

هذا أسهل في الفهم.

وأسهل في الاختبار.

وأقل اعتمادًا على أن أتذكر قائمة استثناءات صنعتها قبل أسابيع.

الشيء الوحيد الذي لا أستطيع رؤيته من القائمة

لا أستطيع من الخارج رؤية كل قواعد التوجيه والاتصالات الداخلية التي يستخدمها كل تطبيق أو كل خدمة مساعدة في كل لحظة.

لذلك لا أعتبر وجود التطبيق في قائمة Split Tunneling دليلًا كافيًا.

أختبر المهمة.

أسجل الدخول.

أفتح الملف.

أرفعه.

أدخل الاجتماع.

ثم أختبر البنك والخدمات المحلية.

إذا نجح كل شيء بالطريق الذي أريده، انتهى التشخيص.

هذا أكثر فائدة من محاولة فهم كل اتصال فرعي يصنعه التطبيق.

المزود الكبير بقي الأفضل في التحكم الدقيق

الخدمة الكبيرة التي استخدمتها تملك ميزة حقيقية لا أنسبها إلى التطبيق الأصغر من دون دليل: Split Tunneling صريح وتحكم أدق في التطبيقات.

ولديها أيضًا مواقع أكثر، وتاريخ عام أطول، ومراجعات مستقلة أكثر.

أما الخدمة الأصغر فلديها مواقع أقل وسجل عام أقصر.

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

لكن هذا لم يعد وصفي للمشكلة.

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

في هذه الحالة، أعطاني المزود الكبير قدرة أكبر على بناء القواعد.

أما التطبيق الأصغر فأعطاني ما كان أكثر قيمة لي في تلك اللحظة:

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

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