VPN لا يتصل أو يظهر Connected بلا إنترنت؟ شخّص مكان العطل قبل أن تغيّر الخادم

كان أمامي أقل من نصف ساعة لإرسال ملف، والـVPN يقول إنه يعمل.

هذه هي الجملة التي ضيعت عليّ أول عشر دقائق.

كنت على Wi-Fi في فندق. اتصل اللابتوب بالشبكة، واشتغل تطبيق الـVPN تلقائيًا.

Connected.

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

لا شيء.

Gmail لا يفتح.

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

حتى موقع بسيط بقي ينتظر.

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

ثم خادمًا ثانيًا.

ثم ثالثًا.

ما دام التطبيق يقول Connected، افترضت أن الإنترنت موجود وأن الخادم هو المشكلة.

ثم جربت شيئًا كان يجب أن أفعله منذ البداية.

أوقفت الـVPN تمامًا.

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

لم يعمل أيضًا.

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

أول سؤال ليس: أي خادم أجرب؟

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

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

رقم الغرفة.

اسم العائلة.

موافقة على الشروط.

ثم Connect.

هذا هو الـcaptive portal الشائع في الفنادق والمطارات والمقاهي: الجهاز يتصل بالـWi-Fi، لكن الوصول الكامل إلى الإنترنت لا يبدأ قبل إنهاء صفحة الدخول أو قبول الشروط. (Microsoft)

بعد إكمالها فتحت المواقع فورًا.

لم أغير DNS.

لم أعد تشغيل الجهاز.

ولم يكن أي خادم VPN مسؤولًا عن المشكلة الأولى.

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

ومن هنا أصبحت لدي قاعدة تشخيص بسيطة:

إذا كان الإنترنت لا يعمل والـVPN متوقف، أصلح الاتصال الأساسي أولًا.

لكن بعد دقائق ظهرت المشكلة التي كنت أتوقعها من البداية.

الإنترنت عاد، والـVPN أصبح هو الفارق

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

البريد يعمل.

المواقع تعمل.

شغلت مزود الـVPN المعروف مرة أخرى.

Connecting…

انتظرت.

فشل.

اخترت خادمًا آخر.

هذه المرة ظهر:

Connected.

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

أوقفت الـVPN.

عاد الإنترنت فورًا.

شغلته.

اختفى الإنترنت.

وهنا أصبح الاختبار واضحًا جدًا.

في المرة الأولى، لم يكن لدي إنترنت كامل أصلًا.

أما الآن فالإنترنت يعمل، ولا تبدأ المشكلة إلا عندما يدخل نفق الـVPN في الطريق.

هذان عطلان مختلفان، حتى لو كانت النتيجة الظاهرة للمستخدم واحدة:

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

كلمة Connected لا تعني أن الطريق كله سليم

كنت أثق في اللون الأخضر أكثر مما ينبغي.

إذا ظهر Connected، أفترض أن مهمة الـVPN انتهت.

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

بالنسبة لي، هذا يكفي.

لا أحتاج إلى تحليل جداول routing في ردهة الفندق.

أحتاج فقط إلى فهم أن:

Connected يعني أن النفق بدأ، لا أن المهمة نجحت.

لذلك أصبحت أفتح الصفحة التي أحتاجها بعد الاتصال.

إذا لم تصل، فالأيقونة الخضراء ليست نتيجة نهائية.

هنا أصبحت كثرة الخوادم جزءًا من المشكلة

المزود الكبير لديه نقطة قوة حقيقية.

شبكة واسعة.

خيارات كثيرة.

تاريخ طويل.

لكن عندما حدث العطل، تحولت هذه الخيارات إلى سلسلة تخمينات.

فشل؟

غيّر الخادم.

ما زال لا يعمل؟

غيّر الدولة.

ثم البروتوكول.

ثم Fastest Server.

بعد عدة محاولات لم أعد أعرف ما الذي تغير وما الذي بقي ثابتًا.

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

تعرفت على ذلك فورًا.

كنت أجمع محاولات.

لا معلومات.

والفرق مهم.

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

لا أحتاج إلى عشر دول أخرى كي أثبت ذلك.

أربعة اختبارات وفرت عليّ معظم التخمين

منذ ذلك الوقت أصبحت أبدأ بأربع حالات فقط.

الإنترنت لا يعمل حتى والـVPN متوقف؟

أفحص Wi-Fi نفسه أولًا: صفحة دخول، راوتر، شبكة الفندق أو مزود الإنترنت.

الإنترنت يعمل، لكن الـVPN لا يصل إلى Connected؟

هنا فشل إنشاء النفق. تغيير طريقة الاتصال أهم من تدوير قائمة الدول.

الـVPN يقول Connected، لكن كل المواقع تتوقف؟

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

كل شيء يعمل ما عدا موقعًا أو تطبيقًا واحدًا؟

إذن لا أتعامل مع الجهاز كله كأنه معطل. أركز على تلك الوجهة.

هذه ليست قائمة تقنية طويلة.

هي فقط طريقة لمعرفة أين أبحث.

وفي الفندق كانت النتيجة واضحة:

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

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

كنت بحاجة إلى محاولة مختلفة، لا إلى خادم إضافي.

هذه المرة بدأت من المشكلة نفسها

كان OnlydogVPN^[1] مثبتًا على اللابتوب ضمن الاختبارات.

فتحته.

بدل أن أبدأ بدولة جديدة، بدأت من نوع الشبكة الموجودة أمامي.

اخترت الوضع الموجه للشبكات المقيدة.

ضغطت اتصال.

اتصل.

لم أفتح Speedtest.

ولم أذهب للتحقق من عنوان IP.

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

ظهرت.

فتحت مجلد العميل.

بدأ رفع الملف.

وصل إلى 100%.

ثم أرسلت الرسالة التي كنت أحاول إرسالها منذ دخولي الفندق.

هنا انتهت بالنسبة لي أهم مرحلة من التشخيص.

الخدمة لم تعطِني خادمًا آخر لأكرر التخمين نفسه.

أعادتني إلى المهمة التي كنت أحاول إنجازها.

ما تغير كان طريقة المرور

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

بالنسبة لي، القيمة واضحة:

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

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

لكنني أستطيع رؤية ما حدث أمامي.

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

المحاولة الأولى لا تعطيني اتصالًا مفيدًا.

الخدمة الثانية تتصل.

والملف يصل.

هذا هو النوع من التشخيص الذي أحتاجه عندما يكون الوقت محدودًا.

لهذا لم أعد أبدأ بـNetwork Reset

قبل ذلك كنت أميل سريعًا إلى الحلول الكبيرة.

Network Reset.

حذف محولات الشبكة.

إعادة تثبيت التطبيق.

إعادة تشغيل الجهاز.

Windows يوفر Network Reset ضمن أدوات إصلاح مشاكل الشبكة، لكنه يعيد إعداد مكونات الاتصال، لذلك أصبح بالنسبة لي خطوة متأخرة لا نقطة بداية. (Microsoft)

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

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

ترتيب التشخيص وفر الوقت أكثر من كثرة الحلول.

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

أنهيت العمل وأغلقت اللابتوب.

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

كان الهاتف على Wi-Fi.

ابتعدت عن المبنى.

اختفت الشبكة.

ظهرت بيانات الجوال.

توقف الاتصال لحظة، ثم استعادت الخدمة الطريق وأكملت الإرسال.

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

لأن أعطال VPN لا تحدث دائمًا وأنا جالس أمام راوتر ثابت.

تحدث في فندق.

ثم في المطار.

ثم عندما يتحول الهاتف من Wi-Fi إلى البيانات.

والخدمة التي تحتاج مني إعادة التشخيص بعد كل انتقال تصبح جزءًا من المشكلة نفسها.

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

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

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

إذا بقي التطبيق على Connecting، لا أستهلك وقتي في تبديل عشر دول.

وإذا ظهر Connected بينما الإنترنت ميت، لا أعتبر اللون الأخضر دليل نجاح.

أختبر النتيجة.

المزود الأكبر الذي بدأت به لديه مواقع أكثر، تاريخ عام أطول ومراجعات مستقلة أكثر.

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

لكنني في تلك الليلة لم أكن أعاني من نقص في الخوادم.

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

بمجرد أن عرفت ذلك، اختفت معظم المحاولات غير الضرورية.

احتجت أولًا إلى إنهاء صفحة Wi-Fi.

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

ولهذا عندما يكون الـVPN عالقًا على Connecting أو يظهر Connected بلا إنترنت، لا أبدأ بتغيير الدولة؛ أبدأ بالسؤال: ما آخر جزء من الاتصال أعرف أنه يعمل فعلًا؟