لماذا لا يعمل VPN في قطر رغم أن الإنترنت يعمل؟ عندما تكون المشكلة في النفق لا في سرعة الشبكة

كنت قد انتهيت تقريبًا من العمل عندما فعلت الشيء المعتاد قبل رفع ملفات عميل من شبكة فندق: شغلت الـVPN.

حتى تلك اللحظة، لم تكن لدي مشكلة إنترنت أصلًا.

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

ضغطت Connect.

انتظرت.

ثم ظهر فشل الاتصال.

جربت مرة ثانية.

وفي الثالثة بقي التطبيق يحاول فترة أطول، ثم أعادني إلى Disconnected.

أوقفت Wi-Fi وشغلته من جديد. فتحت المتصفح واختبرت عدة صفحات.

الإنترنت يعمل.

عدت إلى الـVPN.

لا اتصال.

وهنا ظهر السؤال الحقيقي: كيف يمكن للإنترنت أن يكون سليمًا بينما الـVPN نفسه لا يستطيع الاتصال؟

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

أول شيء استبعدته: أن قطر «تمنع كل VPN»

هذا تفسير سهل، لكنه لا يشرح الواقع جيدًا.

هيئة تنظيم الاتصالات القطرية نفسها دعمت سابقًا حلول عمل عن بُعد تضمنت Cisco AnyConnect للوصول الآمن إلى شبكات المؤسسات. (هيئة تنظيم الاتصالات القطرية)

إذن تقنية VPN بحد ذاتها ليست تفسيرًا كافيًا لفشل التطبيق أمامي.

وفي الوقت نفسه، توضح شروط بعض خدمات المشغلين أن حركة التطبيقات عبر VPN قد تُعامل بطريقة مختلفة عن استخدامها مباشرة؛ فمثلًا يمكن للـVPN أن يمنع الشبكة من التعرف على حركة تطبيق معيّن ضمن مزايا البيانات المخصصة. (Ooredoo Qatar)

وهذه كانت المعلومة التي احتجتها.

الاتصال العادي واتصال الـVPN ليسا الشيء نفسه من منظور الشبكة.

لذلك توقفت عن سؤال: «هل الإنترنت في الفندق جيد؟»

كنت قد أجبت عن ذلك بالفعل.

السؤال أصبح: هل يستطيع هذا التطبيق بناء نفق يعمل فوق الشبكة الموجودة أمامي؟

Speedtest كان يثبت الشيء الخطأ

مع ذلك، فتحت اختبار السرعة مرة أخرى.

النتيجة ممتازة.

ثم ضحكت من نفسي قليلًا.

للمرة الثالثة كنت أثبت أن الإنترنت يعمل، بينما المشكلة موجودة في مكان آخر.

هناك فرق بين VPN يظهر Connected ثم يكون بطيئًا، وVPN لا يصل أصلًا إلى Connected.

أنا كنت في الحالة الثانية.

إذا كان الاتصال قائمًا ثم موقع معين لا يعمل، يمكنني التفكير في عنوان IP أو الموقع أو الخادم الذي اخترته. أما إذا كان النفق نفسه لا يقوم، فلا يهمني كثيرًا أن الخدمة تملك عشرات الدول أو خادمًا أسرع على الورق.

قبل كل ذلك، يجب أن أصل إلى الشبكة من خلال الـVPN أصلًا.

وهنا أصبحت شاشة Connect أهم عندي من شاشة Speedtest.

الخدمة الكبيرة أعطتني خوادم أكثر لأكرر عليها الفشل

كنت أستخدم خدمة VPN معروفة، وهذا كان سببًا منطقيًا للثقة بها.

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

لذلك افترضت أن المشكلة في الخادم.

غيرته.

فشل.

اخترت دولة أخرى.

فشل.

غيرت البروتوكول من الإعدادات.

استمرت محاولة الاتصال فترة أطول، ثم عدت إلى النقطة نفسها.

بعدها جربت بيانات الهاتف بدل Wi-Fi الفندق.

وهنا تغير السلوك.

الاتصال نجح بصورة أفضل.

هذه كانت اللحظة التي نقلتني من التخمين إلى تشخيص أبسط.

الحساب نفسه.

الجهاز نفسه.

التطبيق نفسه.

لكن الشبكة تغيرت، فتغيرت النتيجة.

وهذا يعني أن سرعة Wi-Fi لم تكن محور المشكلة.

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

وجدت نقاشًا لمستخدم في قطر تعطلت لديه عدة خدمات VPN على Vodafone، بينما ظل بعض الأشخاص الآخرين قادرين على استخدام خدمات مشابهة. (Reddit)

لم أحتج إلى تفاصيل أكثر من ذلك.

المغزى ليس أن «Vodafone تحجب VPN» أو أن المشكلة واحدة لدى الجميع.

المغزى العملي أبسط: خدمة أو طريقة اتصال قد تتعثر على شبكة معينة بينما تنجح طريقة أخرى.

وهذا كان مطابقًا لما رأيته أمامي.

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

ومن هنا فقد عدد الخوادم جزءًا كبيرًا من أهميته.

مئات الخوادم لا تساعد إذا كنت عالقًا قبلها

عادةً تبدو خريطة الدول من أهم ميزات أي VPN.

وهذا منطقي بعد نجاح الاتصال.

عندها يمكنني مقارنة لندن بفرانكفورت أو اختيار موقع أقرب إلى الخدمة التي أريدها.

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

لذلك تغير معي معيار المقارنة:

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

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

هذه المرة لم أبدأ من اسم دولة

فتحت OnlydogVPN على شبكة الفندق نفسها.

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

ظهر Connected.

انتظرت لحظة، لأن المحاولات السابقة جعلتني أكثر حذرًا.

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

ظهرت صفحة تسجيل الدخول.

دخلت إلى الحساب.

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

استمر شريط الرفع حتى النهاية.

ثم أرسلت الرسالة.

وهنا انتهى الاختبار الذي كان يهمني فعلًا.

الخدمة السابقة جعلت الاتصال نفسه هو المهمة.

أما التطبيق الأصغر فجعل الاتصال خطوة قصيرة، ثم أعادني إلى المهمة الأصلية.

هذه بالنسبة لي كانت أفضلية أكثر عملية من وجود خوادم إضافية لن أصل إليها بثبات.

التقنية هنا تحتاج إلى سطرين فقط

الخدمة تستخدم إخفاءً إضافيًا لحركة الـVPN، مع نقل مبني على HTTP/3 فوق QUIC. (IETF / RFC Editor)

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

وهذا هو الجزء الذي يهمني.

لم أفتح التطبيق لكي أدرس البروتوكولات.

فتحته لأن Connecting لا ينتهي.

وبعد تشغيله، انتهى.

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

لكنني أستطيع مقارنة النتيجة أمامي: طريقة اتصال لم تستطع إنشاء نفق ثابت، وأخرى استطاعت.

ثم تغيرت الشبكة ولم أبدأ من الصفر

بعد أن أنهيت رفع الملف، أغلقت الكمبيوتر وغادرت الفندق.

الهاتف انتقل من Wi-Fi إلى بيانات الهاتف.

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

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

وهنا ظهرت الفائدة الثانية بصورة طبيعية.

لم تكن هي سبب اختياري للتطبيق.

السبب الأول كان أبسط بكثير: أن النفق قام أصلًا على الشبكة التي فشلت عليها المحاولة السابقة.

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

لهذا لا أبدأ بعد الآن بعبارة «جرب خادمًا آخر»

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

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

وهذا ما كنت أفعله.

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

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

إذا كان الإنترنت يعمل والـVPN لا يقوم، لا أبدأ بعدد الدول.

أبدأ بالسؤال:

هل هذه الخدمة تستطيع بناء النفق على الشبكة التي أمامي؟

إذا كان الجواب لا، فبقية المواصفات لا تساعدني في تلك اللحظة.

أين تبقى أفضلية الخدمة الكبيرة؟

الخدمة الكبيرة ما زالت تملك نقطة قوة واضحة: سجل عام أطول، ومراجعات مستقلة أكثر، وتاريخًا يمكن الرجوع إليه بسهولة.

أما الخدمة الأصغر فسجلها العام أقصر، ولذلك توجد عنها مراجعات مستقلة أقل حتى الآن.

لكنني لم أكن في الدوحة أجري مقارنة نظرية بين شركتين.

كان لدي إنترنت يعمل، وملف يجب رفعه، وVPN معروف لا يتجاوز شاشة Connecting بثبات.

الخدمة الكبيرة أعطتني خوادم أكثر لأجربها.

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

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