واي فاي الفندق: اتصال VPN يفشل قبل أن يصل إلى الخادم

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

الأسطورة: الفندق يحجب VPN

معظم شبكات الفنادق لا ترشّح الأنفاق تحديداً. تعترض حركة الويب حتى يتحقق الضيف من هويته، وقد تحد أيضاً من عدد الأجهزة أو تُنهي الجلسات أو تخفض الإنتاجية. كل ذلك ينتج عطلاً يبدو من داخل عميل VPN كأنه حجب.

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

هذا الترتيب مهم لسبب آخر: العميل الذي يعمل بمفتاح إيقاف أو بوضع التشغيل الدائم سيرفض تحميل البوابة، فيستنتج المستخدم أن الشبكة معطلة لا الإعداد. الحقيقتان صحيحتان في الوقت نفسه، وواحدة فقط منهما يمكن تغييرها في الفندق. أوقف الحماية من خلال تحكم العميل نفسه، وسجّل الدخول، ثم أعد تشغيلها. أي شيء آخر هو حل ملتوٍ يخفي التسلسل الحقيقي.

أكمل البوابة أولاً ثم اختبر HTTPS العادي

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

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

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

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

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

احتفظ بالملف الأصلي وخطئه

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

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

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

استخدم فقط البدائل التي يوفرها المشغّل

قد ينجح ملف TCP مطابق حيث لا ينجح مسار UDP المعروض، لكن فقط إذا كان الخادم يستمع فعلاً على ذلك النقل والمنفذ. المنفذ 443 في TCP لا يُعامل تلقائياً كـ HTTPS عادي، وهو ليس ضماناً للمرور عبر شبكة مقيدة.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

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

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

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