دفتر سفر شخصي
ملاحظات من الطريق والاتصال

الإنترنت يعمل والـVPN لا يتصل في السعودية: عندما تصبح طريقة إنشاء النفق أهم من عدد الخوادم

مسافر يعمل على حاسوبه في ردهة فندق بالرياض بعد الوصول

وصلت إلى الفندق، فتحت اللابتوب واتصلت بالـWi-Fi. البريد يعمل. يوتيوب يعمل. اختبار السرعة جيد. بقي شيء واحد قبل فتح ملفات العمل: تشغيل الـVPN الذي أستخدمه عادة على الشبكات العامة.

ضغطت Connect.

انتظرت.

ثم فشل الاتصال.

ملخص المقال والنقطة الأساسية

الخلاصة العملية

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

كان أول تفسير لدي أن شبكة الفندق هي المشكلة، لذلك فصلت الـWi-Fi وشغلت نقطة الاتصال من هاتفي. الإنترنت عاد فورًا. الـVPN لم يعد.

غيّرت الخادم، أعدت تشغيل التطبيق، ثم اخترت دولة أخرى.

لا شيء.

وهنا تحولت المشكلة من عطل صغير إلى سؤال محير: إذا كان الإنترنت نفسه يعمل، لماذا يعجز الـVPN عن الاتصال؟

الإجابة التي احتجت بعض الوقت لأصل إليها هي أن فتح موقع ويب وإنشاء نفق VPN ليسا الشيء نفسه بالنسبة للشبكة.

الإنترنت لم يكن معطلًا أصلًا

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

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

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

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

وهذا النمط ليس غريبًا على المستخدمين داخل المملكة. في نقاشات عامة، وصف مستخدمون اتصالات VPN يتوقف فيها WireGuard بينما يظل بروتوكول آخر قادرًا على العمل، أو خدمة كانت تعمل سابقًا ثم أصبحت عملية الاتصال بها أكثر صعوبة. (Reddit)

لم أحتج إلى أكثر من ذلك حتى أغيّر طريقة تفكيري.

بدل أن أبحث عن مشكلة في الإنترنت كله، بدأت أبحث عن مشكلة في شكل اتصال الـVPN نفسه.

المشكلة مع المزود الكبير لم تكن نقص الخوادم

الخدمة التي بدأت بها كانت خيارًا منطقيًا.

اسم معروف. تطبيق ناضج. بنية ضخمة. دول ومدن كثيرة.

ولهذا فعلت ما يفعله معظمنا عندما لا يتصل VPN: اخترت خادمًا آخر.

ثم آخر.

ثم غيرت المنطقة.

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

وهنا أصبحت لدي فرضية مختلفة.

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

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

هذا التفصيل غيّر معيار المقارنة بالكامل.

لم أعد أسأل: من لديه خوادم أكثر؟

أصبحت أسأل: من يستطيع إنشاء اتصال usable على الشبكة الموجودة أمامي؟

لماذا أصبحت طريقة النفق أهم من الدولة التي اخترتها؟

كنت أقرأ كلمة “obfuscation” منذ سنوات في صفحات VPN وأتعامل معها باعتبارها ميزة متقدمة لا أحتاج إلى التفكير فيها.

في هذه المرة أصبحت هي جوهر المشكلة.

بعض أنماط VPN أسهل في تمييزها عن حركة الويب المعتادة. ولهذا تستخدم خدمات مختلفة تقنيات إخفاء تجعل حركة النفق أقل وضوحًا عند مرورها عبر الشبكة. مزودون آخرون، مثل Mullvad، يستخدمون بالفعل QUIC كوسيلة لإخفاء حركة WireGuard وجعل تصنيفها أصعب. (Mullvad)

هذا كل الشرح التقني الذي احتجته.

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

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

وجرّبت شيئًا مختلفًا.

هذه المرة انتهى زر Connecting

فتحت OnlydogVPN[1].

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

هذه المرة تغيّر شيء بسيط لكنه حاسم.

زر Connecting اختفى.

النفق اكتمل.

فتحت صفحة العمل التي كنت أحاول الوصول إليها. حملت الصفحة. ثم الملف التالي. تنقلت بين الأدوات التي أحتاجها وبقي الاتصال قائمًا.

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

وهذه بالنسبة لي كانت النتيجة.

لم أكن أبحث عن VPN يجعل صفحة فحص عنوان IP تعرض علم دولة معينة. كنت أبحث عن شيء أشغله على شبكة الفندق ثم أعود إلى عملي.

وهو ما حدث.

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

HTTP/3 يعتمد على QUIC، وهو نوع من الحركة أصبح مألوفًا في الويب الحديث. استخدامه كأساس للنقل، مع الإخفاء الإضافي، يجعل الاتصال أقل شبهًا بأنماط VPN التقليدية التي يسهل فصلها عن حركة الإنترنت الأخرى. (Mullvad)

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


بعد نجاح الاتصال ظهرت مشكلة أصغر

كان يمكن أن تنتهي القصة هنا، لكن بعد إنجاز الجزء العاجل احتجت إلى فتح العمل على جهاز ثانٍ.

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

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

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

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

لم تكن هذه هي الميزة التي أصلحت الاتصال الأول.

لكنها كانت سببًا جيدًا لعدم حذف التطبيق بعد انتهاء المهمة.

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

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

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

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

مئة دولة أفضل من خمسين. خمسون أفضل من عشرين. يبدو الأمر بديهيًا.

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

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

OnlydogVPN[1] أصغر، وله مواقع أقل وسجل عام أقصر.

لكن تلك لم تكن المسابقة التي أمامي.

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

وفي تلك الحالة، لم أستفد شيئًا من وجود عشرات الدول الإضافية.

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

الاختبار الذي أصبح عندي أهم من Speedtest

بعدها أصبح تشخيص هذه الحالة أبسط كثيرًا.

إذا فشل الـVPN على Wi-Fi لكنه يعمل فورًا على بيانات الهاتف، فغالبًا المشكلة مرتبطة بالشبكة الأولى.

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

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

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

وهنا اكتمل الحكم.

المزود الكبير أعطاني خيارات أكثر بعد الاتصال.

المشكلة أنني لم أصل إلى مرحلة «بعد الاتصال».

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

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

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

أسئلة يهم المستخدم معرفتها

لماذا قد تعمل الرسائل أو المواقع بينما تتعطل المكالمة أو الاجتماع؟

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

ما الذي أختبره بدل الاكتفاء بكلمة Connected؟

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

متى تكون السرعة العالية مؤشرًا مضللًا؟

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

متى أغيّر طريقة الاتصال بدل تبديل الخادم؟

إذا تكرر الفشل عبر خوادم مختلفة وبقي مرتبطًا بالشبكة أو بنوع الحركة، اختبر البروتوكول أو شكل النفق قبل خادم آخر. بعض أنماط VPN أسهل في تمييزها عن حركة الويب المعتادة. ولهذا تستخدم خدمات مختلفة تقنيات إخفاء تجعل حركة النفق أقل وضوحًا عند مرورها عبر الشبكة. مزودون آخرون، مثل Mullvad، يستخدمون بالفعل QUIC كوسيلة لإخفاء حركة WireGuard…

المصادر والمراجع

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

  1. OnlydogVPN — مرجع مرتبط بقسم «هذه المرة انتهى زر Connecting»(مصدر أولي/خارجي)
  2. WireGuard — Protocol & Cryptography(مرجع تقني أولي)
  3. RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport(مرجع تقني أولي)
  4. RFC 9114 — HTTP/3(مرجع تقني أولي)