هل Multi-Hop يساعد على الحجب؟ العقدة الثانية لا تفيد إذا تعذر الوصول إلى الأولى

الخيار بدا أقوى، لذلك افترضت أنه سيكون أصعب في الحجب.

بدل أن يمر اتصالي عبر خادم VPN واحد، شغلت Multi-Hop:

الهاتف → الخادم الأول → الخادم الثاني → الإنترنت.

خادمان بدل واحد.

وطبقة إضافية تبدو، على الشاشة على الأقل، أكثر تقدمًا.

كنت على Wi-Fi يتعثر عليه اتصال الـVPN العادي، وأحتاج خلال دقائق إلى فتح لوحة عمل وإرسال ملف.

شغلت Multi-Hop.

Connecting.

انتظرت.

ثم فشل.

غيرت خادم الخروج.

لا شيء.

غيرت الدولة.

لا شيء.

وهنا ظهر السؤال الذي كان يجب أن أطرحه قبل كل هذه المحاولات:

إذا لم أصل إلى الخادم الأول أصلًا، ماذا سيفعل لي الخادم الثاني؟

Multi-Hop يحل مشكلة مختلفة

الفكرة الأساسية وراء Multi-Hop مرتبطة بالخصوصية: تمر الحركة عبر أكثر من خادم بدل الاعتماد على نقطة واحدة.

Proton، مثلًا، تستخدم Secure Core لتمرير الحركة عبر خادم أول قبل خادم الخروج، بينما تصف Mullvad Multihop بالطريقة نفسها تقريبًا: خادم دخول ثم خادم خروج، مع تكلفة محتملة في زمن الاستجابة والأداء.

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

لكن مشكلتي لم تكن:

«هل أحتاج إلى خادم ثانٍ؟»

كانت:

«لماذا لا يبدأ اتصال الـVPN من هذه الشبكة أصلًا؟»

وبمجرد أن فصلت السؤالين، أصبح فشل Multi-Hop أقل غموضًا.

العقدة الثانية تأتي متأخرة جدًا عن مشكلتي

في Multi-Hop، جهازي ما زال يحتاج أولًا إلى إنشاء اتصال مع عقدة الدخول.

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

ولهذا كان تغيير دولة الخروج في محاولاتي الأولى يشبه تعديل النصف الأخير من رحلة لم تبدأ بعد.

وهناك حالة يمكن أن يساعد فيها Multi-Hop فعلًا مع القيود: إذا كنت أستطيع الوصول إلى خادم دخول معين، لكنني أريد الخروج عبر موقع لا أستطيع الوصول إليه مباشرة، يمكن للخادم الأول أن يصبح بوابة إلى الثاني. (Mullvad)

لكن لاحظ الفرق.

الاتصال الأول نجح بالفعل.

وهذا جعل معياري أوضح:

في الحجب، القدرة على الوصول إلى العقدة الأولى أهم من عدد العقد الموجودة بعدها.

كنت أستخدم ميزة خصوصية لإصلاح مشكلة وصول

هذا الالتباس شائع بما يكفي لأن يظهر في نقاشات المستخدمين: شخص على Wi-Fi مقيد يسأل إن كان Multi-Hop سيجعله يتجاوز الجدار الناري الذي يمنع خدمات VPN. (Reddit)

السؤال منطقي.

Double VPN وMulti-Hop وSecure Core كلها أسماء توحي بأن الاتصال أصبح «أقوى».

لكن القوة هنا ليست من النوع نفسه.

إضافة عقدة يمكن أن تغير ما يعرفه كل طرف عن المسار.

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

ومن هنا انتقلت من البحث عن Hop إضافية إلى البحث عن طريقة دخول مختلفة.

حتى التطبيقات الكبيرة تفصل بين Multi-Hop ومقاومة الحجب

هذا الفصل يظهر بوضوح في تصميم الخدمات نفسها.

Mullvad تضع Multihop كميزة منفصلة، بينما تستخدم أدوات مثل QUIC وShadowsocks للتعامل مع البيئات التي يصعب فيها إنشاء VPN. (Mullvad)

NordVPN تفصل بالطريقة نفسها بين Double VPN وبين الخوادم المموهة المخصصة للشبكات التي تحاول تقييد حركة VPN. (NordVPN)

وهذه كانت الإشارة التي احتجتها.

إذا كانت Multi-Hop وحدها هي أداة تجاوز الحجب، لما احتاجت هذه الخدمات إلى فئة منفصلة للإخفاء أصلًا.

السؤال لم يعد:

«خادم واحد أم خادمان؟»

بل:

«هل طريقة الاتصال إلى الخادم الأول مناسبة للشبكة أمامي؟»

عندما أضفت خادمًا ثانيًا، أضفت قرارات أيضًا

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

خادم دخول مختلف.

خادم خروج مختلف.

ثم اتصال أحادي.

ثم Multi-Hop من جديد.

في اتصال عادي كان لدي خادم واحد لأفكر فيه.

الآن لدي دخول وخروج، وكل فشل يخلق سؤالًا جديدًا:

هل المشكلة في الأول؟

هل الثاني؟

هل أغير الدولة؟

هل أعود إلى اتصال عادي؟

الخدمة الكبيرة لديها نقطة قوة واضحة: بنية ناضجة وخيارات خصوصية متقدمة.

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

كنت أحتاج إلى أن يصبح أول جزء من المسار قابلًا للعبور.

وهنا أصبحت المحاولة التالية أبسط عمدًا.

بدأت من الشبكة بدل عدد العقد

فتحت OnlydogVPN^[1].

لم أبحث عن Multi-Hop.

ولم أختر خادم دخول ثم خادم خروج.

اخترت الوضع المخصص للشبكات الأكثر تقييدًا، ثم ضغطت Connect.

ظهر الاتصال.

فتحت لوحة العمل.

اكتملت صفحة تسجيل الدخول.

مررت المصادقة.

فتحت المشروع.

رفعت الملف.

وصل شريط الرفع إلى النهاية.

ثم دخلت المكالمة.

وهنا انتهت المشكلة التي جعلتني أفتح إعدادات الـVPN أصلًا.

الفرق بالنسبة لي لم يكن أن الخدمة استخدمت عددًا أقل من الخوادم.

الفرق أنني توقفت عن محاولة حماية مسار لم أكن قادرًا على بدئه.

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

الإخفاء كان أهم من Hop إضافية

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

وهذا هو القدر الكافي من التقنية هنا.

Multi-Hop يغير ما يحدث بعد أن تدخل إلى شبكة الـVPN.

أما في الحجب، فأنا أحتاج أولًا إلى جعل الدخول نفسه يعمل.

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

لكن النتيجة العملية كانت مباشرة:

إضافة خادم ثانٍ لم تجعلني أصل.

تغيير طريقة الاتصال جعلني أصل وأكمل المهمة.

ومن هنا أصبح واضحًا لماذا كان Multi-Hop أداة صحيحة لمشكلة خاطئة.

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

هناك سبب آخر جعل الفكرة أكثر وضوحًا بعد أن نجحت المهمة.

Multi-Hop يضيف مسارًا إضافيًا، ولذلك يمكن أن يرفع latency ويخفض الأداء.

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

لكنني كنت أرفع ملفًا وأدخل مكالمة.

لم تكن مشكلتي أن الاتصال يمر عبر خادم واحد.

كانت مشكلتي أنه لا يمر أصلًا.

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

صار لكل أداة سؤالها الخاص:

أريد فصل الدخول عن الخروج لأسباب خصوصية؟ Multi-Hop منطقي.

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

وهذا الفصل وفر عليّ الكثير من المحاولات.

Multi-Hop قد يساعد على الحجب، لكن بعد شرط مهم

هذا لا يجعل Multi-Hop عديم الفائدة في الشبكات المقيدة.

إذا كانت الشبكة تسمح لي بالوصول إلى عدد محدود من خوادم الدخول، يمكنني استخدام واحد منها ثم الخروج عبر خادم ثانٍ في موقع آخر. Mullvad توثق هذا السيناريو مباشرة. (Mullvad)

لكن Multi-Hop هنا يبني على اتصال ناجح.

لا يستبدل الحاجة إليه.

وهذه هي النقطة التي كنت أفتقدها عندما بدأت المقال.

كنت أفكر:

خادمان أقوى من واحد.

والأدق هو:

خادمان لا يفيدان إذا كان الحاجز موجودًا قبل الخادم الأول.

الخصوصية ومقاومة الحجب تتقاطعان، لكنهما ليستا الشيء نفسه

بعد التجربة، أصبحت قيمة Multi-Hop عندي أوضح لا أقل.

إنه مفيد عندما أحتاج إلى فصل نقاط المسار أو تقليل الاعتماد على خادم واحد.

لكن هذا ليس بالضرورة ما يحل شبكة تقول لاتصال الـVPN: لن تبدأ من هنا.

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

أما التطبيق الأصغر فبدأ من المكان الذي كان يفشل فعلًا: الاتصال بين جهازي والشبكة المقيدة.

محدوديته الواضحة أن سجله العام أقصر، ولذلك توجد عنه مراجعات مستقلة أقل من المزودين الأقدم.

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

احتجت إلى المسار الذي يبدأ أصلًا.

لهذا، عندما يكون الـVPN محجوبًا، لا أسأل أولًا إن كان بإمكاني إضافة Hop ثانية؛ أسأل إن كانت الـHop الأولى ستعبر الشبكة من دون أن أجعل مقاومة الحجب مشروع إعداد يدويًا.