كيف أعرف أن الشبكة تحجب خادم VPN نفسه؟ اختبر النفق قبل أن تلوم الموقع

الموقع لا يفتح.

هذه عادةً اللحظة التي أفتح فيها VPN.

لكن هذه المرة ظهرت مشكلة أغرب:

الموقع لا يفتح، والـVPN نفسه لا يتصل.

ضغطت Connect.

انتظرت.

Connecting…

ثم عاد التطبيق إلى وضعه السابق.

غيرت الخادم.

Connecting…

لا شيء.

فتحت المتصفح من دون VPN.

Google يعمل.

البريد يعمل.

ومواقع أخرى تفتح طبيعيًا.

رجعت إلى الموقع الذي أريده.

لا يفتح.

كان استنتاجي الأول بسيطًا: الموقع محجوب، إذن أحتاج إلى خادم VPN آخر.

وبعد ثلاثة خوادم بدأت أشك في التطبيق.

لكنني كنت أخلط بين مرحلتين مختلفتين.

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

وهذا غير طريقة التشخيص كلها.

أول شيء أراقبه ليس الموقع، بل زر Connect

الفرق يبدو صغيرًا، لكنه يوفر كثيرًا من الوقت.

عندما أضغط Connect، يحاول تطبيق VPN الوصول إلى بنيته الخاصة وإنشاء النفق.

بعد نجاح ذلك فقط يبدأ طلبي إلى الموقع بالمرور عبر VPN.

إذن إذا بقي التطبيق عند Connecting قبل أن أفتح الموقع، فمن غير المنطقي أن ألوم الموقع على فشل النفق.

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

وهذه لم تعد حالة نظرية نادرة.

خلال 2026 استمر تصعيد حجب خدمات VPN في روسيا، مع تقارير عن حجب مئات الخدمات إلى جانب قيود أوسع على الإنترنت. (Reuters)

كما وثقت OONI سابقًا حالات أكثر دقة: شبكات عطلت OpenVPN وIKEv2 بينما ظلت عناوين خوادم الـVPN نفسها قابلة للوصول. (OONI)

أي أن الشبكة لا تحتاج دائمًا إلى حجب «موقع VPN».

يمكنها استهداف الطريق الذي يستخدمه النفق.

ومن هنا أصبح لدي اختبار أبسط بكثير من تبديل الدول عشوائيًا.

أخذت الـVPN نفسه إلى شبكة أخرى

أوقفت Wi-Fi المقيد.

شغلت نقطة اتصال الهاتف.

لم أغير تطبيق VPN.

لم أغير الخادم الذي فشل قبل دقيقة.

ضغطت Connect.

اتصل.

فتحت موقعًا عاديًا أولًا.

عمل.

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

فتح أيضًا.

هذه الخطوة كانت أهم من عشر محاولات داخل قائمة الخوادم.

لأنها نقلت المتغير الحقيقي من VPN إلى الشبكة.

على الشبكة الأولى:

الخادم نفسه لا ينشئ نفقًا.

على بيانات الهاتف:

الخادم نفسه يتصل.

الـVPN لم يتغير.

الجهاز لم يتغير.

والموقع لم يتغير.

الذي تغير هو الطريق بيني وبين خادم الـVPN.

عندها أصبح الاحتمال العملي الأقوى أمامي واضحًا:

المشكلة تحدث قبل الوصول إلى الموقع.

هذه هي العلامة التي كنت أبحث عنها

كنت في السابق أختبر الحجب بهذه الطريقة:

هل الموقع يفتح؟

لا.

إذن هو محجوب.

لكن هذا الاختبار ناقص عندما يكون VPN في الوسط.

الترتيب الأهم هو:

هل الإنترنت العادي يعمل؟

هل الـVPN يستطيع الاتصال؟

ثم ماذا يحدث للموقع بعد نجاح النفق؟

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

أبدأ بالنفق.

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

قد يكون الموقع نفسه متوقفًا أو يتعامل مع عنوان الخروج بطريقة مختلفة؛ OONI تحذر أصلًا من أن أخطاء الوصول لا تعني تلقائيًا وجود حجب، لأن الخادم نفسه أو طريقة تعامله مع عناوين معينة يمكن أن تكون السبب. (OONI)

وهكذا أصبح زر Connect خطًا فاصلًا عمليًا.

فشل قبل Connected؟ أفحص الـVPN والشبكة.

فشل بعد Connected وفي موقع واحد؟ أفحص الموقع والمسار بعد النفق.

لماذا يمكن للشبكة معرفة أنني أشغل VPN؟

هنا كنت أحتاج إلى تفسير واحد فقط، لا محاضرة.

حركة VPN مشفرة، لكن التشفير لا يجعل كل بروتوكول يبدو مثل التصفح العادي.

أبحاث USENIX أظهرت أن OpenVPN يمكن تمييزه من خصائص في حركة الاتصال نفسها، بما في ذلك أنماط يستطيع نظام على الشبكة استخدامها للتعرف عليه. (USENIX Security)

وهذا يفسر شيئًا كان يبدو لي متناقضًا:

المتصفح يعمل.

مواقع كثيرة تفتح.

لكن تطبيق VPN لا يستطيع إنشاء النفق.

الشبكة لا تحتاج إلى تعطيل الإنترنت كله حتى تمنع طريقًا بعينه.

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

هذا كان كل ما احتجته من تجارب الآخرين.

الخطأ ليس بالضرورة في الموقع الذي كنت أنظر إليه طوال الوقت.

تغيير خمسة خوادم لم يعد يبدو لي تشخيصًا جيدًا

المزود الكبير الذي كنت أستخدمه لديه ميزة واضحة:

شبكة خوادم واسعة وتاريخ طويل.

ولذلك كانت أول غريزة لدي هي الاستفادة من تلك القائمة.

خادم أول.

ثانٍ.

ثالث.

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

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

وهنا تغير معياري.

لم أعد أحتاج إلى «خادم آخر» بالمعنى الجغرافي فقط.

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

وهذه هي اللحظة التي جربت فيها الخيار الثاني.

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

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

اخترت وضع الشبكة الأكثر تقييدًا.

Connect.

اتصل.

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

فتح.

الآن لدي معلومة لم تكن موجودة في المحاولات السابقة:

النفق نفسه قائم على هذه الشبكة.

فتحت بعدها الموقع المستهدف.

ظهرت الصفحة.

دخلت إلى الجزء الذي كنت أحتاجه.

ثم أكملت المهمة التي كنت أؤجلها أثناء تبديل الخوادم.

هذا الترتيب مهم.

نجاح الموقع لم يكن أول دليل.

نجاح النفق كان الدليل الأول.

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

الفرق كان في جعل النفق أقل وضوحًا للشبكة

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

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

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

فاتصل النفق أولًا.

ثم فتح الموقع.

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

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

مسار واحد بقي عند Connecting.

والآخر أنشأ النفق وأوصلني إلى الصفحة.

هذا أيضًا يمنع تشخيصًا خاطئًا في الاتجاه المعاكس

هناك خطأ آخر كنت أفعله.

إذا اتصل VPN لكن موقعًا واحدًا لم يفتح، كنت أفترض فورًا أن الشبكة اكتشفت الـVPN.

ليس بالضرورة.

إذا كان النفق قائمًا، والمواقع الأخرى تعمل من خلاله، فقد وصلت بالفعل إلى خادم الـVPN.

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

المشكلة أصبحت بعده.

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

هذا مختلف تمامًا عن الحالة التي بدأت بها:

هناك لم أصل إلى Connected أصلًا.

والتمييز بين الحالتين وفر عليّ أكثر من أي قائمة استكشاف أخطاء طويلة.

أصبحت أختبر نقطة الفشل بدل تغيير كل شيء دفعة واحدة

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

فعلت شيئًا واحدًا.

راقبت أين تتوقف السلسلة.

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

جيد.

Connect.

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

أغير الشبكة أو طريقة النفق.

إذا نجح Connect، أفتح موقعًا معروفًا.

إذا عمل، أفتح الموقع المستهدف.

بهذا أصبحت كل محاولة تعطيني معلومة.

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

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

بدل أن يبدأ السؤال بـ«أي دولة تريد؟»، استطعت البدء بالمشكلة:

الشبكة مقيدة.

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

العيب موجود، لكنه لم يكن هو ما يوقفني

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

هذه محدوديتها الواضحة.

لكنني لم أكن في موقف أحتاج فيه إلى عشر سنوات إضافية من المراجعات كي أعرف أين تفشل جلستي.

كان لدي مزود معروف وقائمة كبيرة من الخوادم.

وكنت ما أزال عالقًا قبل إنشاء النفق.

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

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

المزود الأول أعطاني أماكن أكثر لأحاول الوصول إليها.

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

الآن أعرف متى ألوم الموقع ومتى ألوم طريق الـVPN

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

وإذا كان VPN لا يتصل، فلن أبدأ بالموقع أصلًا.

أنظر إلى ترتيب الأحداث.

هل وصل التطبيق إلى Connected قبل أن أطلب الصفحة؟

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

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

هذا هو الفارق الذي كنت أفتقده عندما كنت أغيّر الخوادم بلا نهاية.

لمعرفة ما إذا كانت الشبكة تحجب خادم VPN نفسه، لا تبدأ بالموقع الذي تريد فتحه؛ ابدأ بالنفق—فإذا لم يستطع الوصول إلى Connected قبل أن تطلب أي صفحة، فقد وجدت نقطة الفشل التي تستحق أن تغيّر طريقة الاتصال من أجلها.