أفضل VPN مع Split Tunneling؟ عندما كان الاتصال الجيد أفضل من إدارة مسارين

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

فكرة Split Tunneling تبدو مصممة تمامًا لهذا الموقف.

بدل إرسال كل شيء عبر الـVPN، يمكنك تمرير بعض التطبيقات من خلاله وترك البقية على اتصال الإنترنت العادي. المتصفح يحصل على عنوان الـVPN، بينما تسلك مكالمة الفيديو الطريق المباشر.

والفكرة لها أساس عملي قوي. Microsoft نفسها توصي باستخدام Split Tunneling في بعض بيئات العمل عن بُعد مع Microsoft 365، لأن إجبار حركة Teams الحساسة لزمن الاستجابة على المرور بمسار VPN أطول قد يضر بالأداء. Microsoft Learn

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

الحل الأول نجح، ثم أعطاني وظيفة جديدة

بدأت بمزود معروف يدعم Split Tunneling فعلًا. كان اختيارًا منطقيًا. تطبيق ناضج، تاريخ طويل، وتحكم دقيق في التطبيقات التي تمر داخل النفق أو خارجه. فتحت الإعدادات. Split Tunneling. Exclude apps. أضفت Teams إلى قائمة الاستثناءات، وأبقيت المتصفح داخل الـVPN. أعدت الاتصال.

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

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

كلما زادت التطبيقات، زادت القرارات

في الاستخدام البسيط، الأمر سهل. Teams خارج الـVPN. Chrome داخله. انتهى. لكن يوم العمل لا يبقى بهذه البساطة. مكالمة فيديو، تخزين سحابي، متصفحان، أداة مراسلة، برنامج شركة، تطبيق بنكي، وربما خدمة محلية تريد عنوان IP من البلد الذي توجد فيه. وعندها لا تصبح قيمة Split Tunneling في مجرد وجوده، بل في قدرتك على تذكر القواعد التي وضعتها له.

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

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

جربت هذه المرة ألا أقسم شيئًا

في الاختبار التالي فتحت OnlydogVPN^↗. لم أبدأ بقائمة تطبيقات. اخترت حالة الاستخدام وشغّلت اتصالًا كاملًا. ثم بدأت Teams. الصوت بقي مستقرًا. فتحت الموقع الذي كنت أحتاج الـVPN من أجله. عمل. فتحت المستند المشترك. عمل أيضًا. وتركت المكالمة مستمرة بينما انتقلت بين صفحات العمل.

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

الفرق الذي شعرت به لم يكن في عدد الإعدادات

الخدمة تستخدم نقلًا مبنيًا على HTTP/3 وتركز على الحفاظ على اتصال عملي حتى مع تغير ظروف الشبكة. بالنسبة إلي، التفسير التقني انتهى هنا. المهم أن مكالمة Teams لم تصبح الثمن الذي أدفعه مقابل إبقاء بقية حركة العمل داخل الـVPN. وهذا جعل بساطة التطبيق نفسها ميزة. بدل:

Teams خارج. المتصفح داخل. التخزين خارج. أداة الشركة داخل. كان القرار الوحيد:

اتصل.

ثم أعمل.

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

عندها فهمت أنني كنت أقارن عدد الوظائف بينما الشيء الذي يهمني أكثر هو عدد المرات التي أحتاج فيها إلى لمس الإعدادات.

الاختبار الأفضل حدث عندما خرجت من الشقة

بعد الظهر حملت الحاسوب وذهبت إلى مقهى قريب. أغلقته وهو على Wi-Fi الشقة، ثم فتحته على شبكة جديدة. مع إعداد Split Tunneling القديم، كنت عادة أبدأ بفحص الحالة: هل الـVPN ما زال يعمل؟ هل Teams ما زال خارج النفق؟ هل التطبيق الجديد الذي فتحته يحتاج إلى قاعدة أخرى؟ هذه المرة لم أفعل شيئًا من ذلك.

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

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

بعد ذلك احتجت الاتصال على الهاتف

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

لم تكن هذه هي الميزة التي حسمت المقارنة. سبب اختياري بقي كما هو: كنت أريد التخلص من الحاجة إلى تقسيم تطبيقاتي يدويًا. لكن إضافة الجهاز الثاني أكملت الفكرة نفسها. قرارات أقل. خطوات أقل. ووقت أقل داخل تطبيق الـVPN نفسه.

هل يعني ذلك أن Split Tunneling غير مهم؟ لا

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

في هذه الحالات، تحتاج Split Tunneling حقيقيًا، وأدوات متقدمة مثل Proton VPN تمنحك تحكمًا دقيقًا في التطبيقات والعناوين التي تدخل النفق أو تخرج منه. Proton VPN ويدعم Android نفسه مفهوم per-app VPN عندما يوفره تطبيق الـVPN. Google Android Enterprise

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

هذه تنازلات حقيقية، لكنها لم تكن الشيء الذي كان يعرقل يومي.

الميزة التي أردتها، والمشكلة التي كنت أحاول حلها

Split Tunneling ميزة ممتازة عندما يكون التقسيم نفسه ضرورة. لكنني اكتشفت أنني كنت أبحث عنه كحل لمشكلة مختلفة: VPN كامل كان يجعل جزءًا من يومي أسوأ. المزود التقليدي حل المشكلة بأن أعطاني تحكمًا دقيقًا في من يدخل النفق ومن يخرج منه. أما التطبيق الأصغر فحلها بطريقة أبسط: الاتصال الكامل نفسه كان جيدًا بما يكفي لأن أتوقف عن بناء الاستثناءات.

وهذا غيّر معياري. لم أعد أسأل فقط:

هل يوجد Split Tunneling؟

أصبحت أسأل:

كم مرة سأضطر إلى استخدامه فعلًا؟

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