لماذا تعترض بوابة الالتقاط اتصالك بالشبكة الافتراضية، وكيف تعيد تسجيل الدخول
تمنح شبكة Wi-Fi العامة الإذن لجهازك قبل أن تخرج منه أي حزمة. ما الذي تُسقطه البوابة، ولماذا يخطئ عميل VPN في تفسيره، والترتيب الذي يعيد اتصالك.
على شبكة مفتوحة، لا تُسلّم نقطة الوصول الحزم إلى الإنترنت ببساطة. تتحقق نقطة سياسة أعلى في المسار مما إذا كان جهازك قد حصل على إذن بعد، وإلى أن يحصل عليه، يُسقَط كل شيء تقريبًا. يقرأ عميل VPN هذا الصمت كخادم ميت. ونادرًا ما يقول ذلك صراحةً: يعيد WireGuard محاولة المصافحة في فراغ، ويُبلّغ OpenVPN عن انتهاء مهلة الاتصال، ويعود IKEv2 بالخطأ 809 بشأن خادم بعيد لا يستجيب.
ما الذي تتحكم فيه البوابة فعليًا
بوابة الالتقاط شيئان مدبّسان معًا: نقطة قرار للسياسة ومُعيد توجيه. عندما يقترن جهازك ويحصل على تأجير DHCP، تضعك الشبكة في حالة ما قبل الإذن.
تلك الحالة هي مجموعة قواعد لجدار ناري. وهي تسمح عادةً بـ DNS وتسمح بـ HTTP أو HTTPS لقائمة قصيرة من مضيفات البوابة، وتُسقط كل شيء آخر. القائمة المسموح بها هي الحديقة المسوّرة، ولا تكاد تتضمن أبدًا نقطة نهاية VPN.
لا شيء في هذا الإسقاط مؤدّب. الحزم الموجّهة إلى خادم VPN تُهمَل بدلًا من أن تُرفض، فلا يتلقى العميل رسالة ICMP unreachable ولا إعادة تعيين TCP، بل غياب الإجابة فقط. وحسب المورّد، قد يجيب مُعيد التوجيه على المنفذ 80 بإعادة توجيه إلى صفحة تسجيل الدخول بينما يُسقَط المنفذ 443 أو يُعترَض. إعادات التوجيه سهلة الاكتشاف لأنها تحمل استجابة HTTP عادية؛ أما الاعتراض على 443 فيحتاج إلى شهادة سيرفض متصفحك الوثوق بها.
الإذن نفسه مرتبط عادةً بعنوان MAC للجهاز، وأحيانًا بعنوان IP المؤجَّر، ويعيش في جدول جلسات مع مؤقّت. تسجيل الدخول يُنشئ مدخلًا. وقاعدة الجدار الناري التي تسمح بمرور حركتك لا توجد إلا ما دام ذلك المدخل موجودًا، ولهذا تعود المشكلة كلها لاحقًا دون أن يتغيّر شيء من جانبك.
لماذا تموت مصافحة VPN قبل أن تبدأ
لكل بروتوكول نقله الخاص، وجدار الحماية السابق للإذن يعطّل كل واحد منها بطريقة مختلفة. يعتمد IKEv2 على Windows وiOS على UDP 500 وUDP 4500؛ ويظهر الإسقاط على هذين المنفذين في صورة 809، أو في صورة فشل شبيه بفشل تحليل الأسماء على العملاء التي تفصل مراحل الإبلاغ. يبقى OpenVPN عبر UDP 1194 في حالة الاتصال حتى تنتهي مهلته. أما OpenVPN عبر TCP 443 فهو الحالة المثيرة للاهتمام، لأن البوابة قد تُكمل مصافحة TCP ثم تجيب بصفحة إعادة التوجيه، فترى خطأ TLS بدلًا من انتهاء المهلة.
يُظهر WireGuard الآلية بأوضح صورة. فهو UDP فقط بالتصميم، بلا بديل TCP، لذا فإن جدارًا ناريًا يُسقط UDP غير المعروف يزيل النقل كله. يواصل العميل إرسال بدايات المصافحة بتراجع متزايد ويُبلّغ عن مصافحة لا تكتمل أبدًا. لا شيء في تلك الرسالة يذكر Wi-Fi، ولا شيء فيها يوحي بأن عليك فتح متصفح.
تحاول المنصات ملاحظة الحالة قبل أن يلاحظها VPN. يجلب Windows عنوان URL معروفًا ليقرر ما إذا كان سيعرض إشعار تسجيل الدخول، ويطلب Android نقطة نهاية يفترض أن تجيب بـ 204 No Content، وتفتح أجهزة Apple نافذة صغيرة لشبكة الالتقاط. وتنجح تلك الفحوص لأن البوابة تجيب بإعادة توجيه بدلًا من الجسم المتوقع. ويشرح السلوك نفسه كيف يمكن أن تبدو البوابة سليمة تمامًا بينما النفق ميت: فالفحص والنفق يُحكَم عليهما بقواعد مختلفة.
ما الذي يعيده انتهاء الجلسة حقًا
تُنهي الأماكن الجلسات لأسباب لا علاقة لها بحساب VPN لديك: مهلة خمول، أو حد أقصى لطول الجلسة، أو تأجير DHCP جديد، أو إعادة اقتران بنقطة وصول مختلفة. وعندما يعمل المؤقّت، يختفي مدخل جدول الجلسات وتعود مجموعة قواعد ما قبل الإذن كما كانت تمامًا عند تسجيل الوصول.
كثيرًا ما يبقى النفق القائم حيًّا مدة تكفي ليبدو سليمًا. تستمر رسائل الإبقاء حيّة في الخروج، وهل يلاحظ العميل ذلك يتوقف على كيفية تعامله مع الحركة التي لا تُجاب، لذا قد يبقى ضوء الحالة أخضر لبعض الوقت بعد ذهاب المسار. ثم يسقط النفق ويفشل كل محاولة إعادة اتصال على المنافذ المحجوبة نفسها.
عند تلك النقطة، يخبرك خطأ العميل بالمرحلة التي أنت فيها، إن قرأته بعناية:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
هناك تفصيل يخدع الناس: عندما تكون الجلسة مرتبطة بعنوان MAC، فقد لا يساعد إعادة تحميل صفحة تسجيل الدخول. عليك إسقاط الاقتران والانضمام من جديد حتى ترى البوابة محاولة إذن جديدة بدلًا من محاولة منتهية.
سجّل الدخول أولًا، ثم ارفع النفق
الترتيب الذي ينجح هو: امنح الجهاز إذنًا، وأثبت المسار، وابدأ VPN، وأثبت النفق، ثم أعِد حجبك المعتاد. تلك الخطوة الأخيرة مهمة لأن الحالة المؤقتة التي تحتاجها للوصول إلى البوابة هي بالضبط الحالة التي وُجد مفتاح الإيقاف لمنعها.
على عميل سطح مكتب فيه خيار حجب كل شيء خارج النفق أن يُوقَف مؤقتًا حتى تُحمَّل صفحة البوابة، وينبغي أن تُبقي التطبيقات الحساسة مغلقة خلال تلك النافذة خارج النفق؛ فهي الفترة الوحيدة التي تغادر فيها حركة محلية بلا حماية. أما الجهاز المُدار الدائم التشغيل فينبغي أن يستخدم الإجراء الذي نشره مالكه بدلًا من أن تزيل أنت السياسة. وإذا عرضت البوابة تحذير شهادة، فتوقف: فقبوله يوجّه جلستك عبر وكيل اعتراض المكان، وذلك الوكيل يستطيع قراءة كل ما ترسله. على Android، يحجب وضع القفل في VPN الدائم التشغيل الحركة قبل أن يصعد النفق، وبعض الإصدارات لا تستطيع استثناء تدفّق البوابة؛ فإن لم يستطع إصدارك، فاستخدم الوصول البديل الذي يوفره المكان أو جهازًا آخر بدلًا من إبقاء القفل معطّلًا. ويمكن كتابة قواعد Apple عند الطلب بحيث ترفض النفق حتى ينجح فحص، وهو السلوك الذي تريده على شبكات الفنادق.
تحقّق بالترتيب بالأدوات التي لديك بالفعل. قبل النفق، شغّل الفحص مع إظهار الترويسات والجسم كليهما، وراقب هل يحصل نقل VPN على أي إجابة على الإطلاق:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'قبل الإذن، تعطي البوابة العادية واحدًا من جوابين: 302 يشير فيه Location إلى صفحة تسجيل الدخول، أو 200 بجسم HTML هو صفحة البوابة. سجّل أيّهما حصلت عليه. إعادة التوجيه ليست فشلًا قبل تسجيل الدخول؛ بل هي البوابة تخبرك أين تذهب. بعد أن تعلن البوابة النجاح، أعد الأمر وتوقّع 200 جسمه الكلمة الحرفية Success. تلك السلسلة هي ما يجعل الفحص ذا معنى. إذا أجاب المضيف بشكل طبيعي قبل أن تسجّل الدخول أصلًا، فلا توجد بوابة اعتراض على هذه الشبكة. في الالتقاط، يكون الإسقاط قبل الإذن حزمًا صادرة لا يعود منها شيء، بينما يُظهر المسار العامل ردًّا على التدفق نفسه خلال ثانية تقريبًا. اتصل، ثم أعد الالتقاط.
إذا ظل النفق يفشل بعد أن تقول البوابة نعم
نجاح تسجيل الدخول ليس هو النقل المسموح. فكثير من الأماكن تسمح بالبوابة والتصفح العادي بينما تحجب UDP كليًا، مما يترك WireGuard وOpenVPN عبر UDP معطّلين وTCP 443 يعمل. إذا مرّ TCP 443 ولم يمرّ UDP، فهذه سياسة المكان لا عميل أخطأت في إعداده، لذا بدّل النقل أو اقبل الحدّ وامضِ. وإن ظل إعادة الاتصال يفشل بعد ذلك، فاحتفظ بالخطأ الدقيق؛ فهو يسمّي المرحلة التي علقت فيها.
الأعطال الأخرى تسكن في الجهاز. جلسة ما زالت مرتبطة بعنوان MAC قديم، أو محوّل Wi-Fi ثانٍ له تأجيره الخاص، أو عميل خزّن استثناء شهادة البوابة، يمكن لكل منها أن يستمر في الفشل بعد إعادة إذن نظيفة. أسقط الاقتران، وأعد الإذن، وأعد المحاولة مرة واحدة قبل أن تلمس إعدادات العميل. ويستحق RFC 8952 القراءة إن أردت المعمارية التي تقف خلف المكوّنات التي تراقبها.
إذا رفضت البوابة نفسها منح الإذن، فالمشكلة في الحساب أو في تخصيص الجهاز، ولن يصلحها أي إعداد VPN. تغيير بلد خروج VPN لا يعيد ضبط حالة الوصول المحلية للمكان؛ فذلك الجدول مرتبط بجهازك لا بالخادم الذي تختاره. اسأل مشغّل المكان وأعطه الوقت، لأن جدول الجلسات هو ما سينظر إليه.
قبل رحلتك التالية، اكتب ثلاثة أشياء: صفحة البوابة كخطوة صفر، وخطوة إيقاف الحجب لكل جهاز تحمله، وبديل نقل واحد جرّبته فعليًا. وحين يتوقف نفق كان يعمل قبل عشر دقائق، تعامل معه كإذن منتهٍ وأعد فحص البوابة قبل أن تلمس ملف تعريف VPN.