لا يتصل OpenVPN على واي فاي الفندق؟ جرّب TCP 443

افتح العميل، واضغط Connect، واقرأ سطر الحالة بدلًا من مربع الحوار الذي يليه. الملف التعريفي الذي يتعطّل عند Connecting أو Waiting for server بعد شبكة فندق أو حرم جامعي أو شبكة جوال يكون عادةً قد فقد طبقة النقل في مكان ما على المسار، لا بيانات اعتماده. الخطوة المفيدة التالية هي معرفة ما تحمله تلك الشبكة قبل أن تمسّ الخادم. لا تغيّر شيئًا حتى يعمل الملف نفسه في مكان آخر.

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

ابدأ من العميل: اقرأ سطر الحالة

يخبرك سطر الحالة أي مرحلة فشلت. العميل العالق عند Connecting ما زال يحلّل اسم المضيف أو يفتح المقبس الخارجي؛ والعميل الذي يصل إلى Waiting for server لديه مسار لكن لا رد؛ والعميل الذي ينجح في المصادقة ثم ينقطع لديه مشكلة مختلفة تمامًا. سجل العميل وحقلا remote و proto في الملف التعريفي يُظهران ما يحاول العميل فعله، و --verb 4 على عميل سطر أوامر يطبع التفاصيل نفسها. ومقارنة ذلك بالشبكة التي أمامك هي ما يحوّل عبارة «VPN محجوب» إلى ادعاء محدد.

ثم افحص الشبكة بأدوات لديك بالفعل. يرسل nc -vzu 203.0.113.10 1194 حزمة UDP، ويُبلّغ curl -v telnet://203.0.113.10:443 عمّا إذا اكتملت مصافحة TCP، والمتصفح الذي يحمّل صفحة HTTPS يثبت فقط أن المنفذ 443 الصادر يصل إلى ذلك المضيف وحده. الفحوص الصغيرة تجيب عمّا لا يستطيعه عميل VPN: أي منفذ وأي بروتوكول يغادر هذه الشبكة أصلًا.

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

حرّك المستمع والملف التعريفي معًا

من جهة الخادم، اضبط المستمع على ما تسمح به الشبكة: port 443 و proto tcp في إعداد الخادم، ثم أعد تشغيل الخدمة وأكّد المقبس باستخدام ss -lntp. ومن جهة العميل، يجب أن يوافق الملف التعريفي، لأن طبقة النقل والمنفذ يقعان خارج النفق: proto tcp و port 443 في ملف .ovpn، أو الحقلان المطابقان في شاشة إعدادات التطبيق. والملف الذي ما زال موجّهًا إلى UDP 1194 يفشل تمامًا كما كان، والإغراء هو إلقاء اللوم على جدار حماية أُصلح بالفعل. وإذا كان المضيف نفسه يجيب أيضًا على HTTPS في المنفذ 443، فلا يمكن للمستمعين مشاركة ذلك العنوان والبروتوكول؛ فأعطِ VPN عنوانًا ثانيًا أو ضع مُفصِلًا متعددًا في المقدمة.

تابع الاتصال الأول باستخدام tcpdump -ni any port 443 على الطرفين. الحزم التي تغادر العميل ولا تصل أبدًا تعني أن الشبكة ترشّح بعد كل شيء، أو أن العنوان في الملف التعريفي ليس العنوان الذي تفترضه. والحزم التي تصل بلا رد تعيدك إلى سجل الخادم، حيث يظهر عدم تطابق البروتوكول فورًا كحزمة مُسقطة.

حين لا يغادر الشبكة إلا وسيط

بعض الشبكات الضيفية لا تسمح بشيء سوى وسيط HTTP، وهو قيد مختلف عن منفذ مغلق ويستبعد أكثر من OpenVPN. العملاء الذين يتحدثون PPTP أو L2TP/IPsec أو IPsec المجرد فقط لا يجدون سبيلًا عبره، لأن تلك التصاميم تتوقع أن يصل بروتوكولها الخارجي إلى الخادم مباشرة. OpenVPN يستطيع ذلك، باستخدام http-proxy proxy.example.net 8080 في ملف العميل، بشرط أن يسمح الوسيط بأسلوب CONNECT إلى منفذك. ووسيط SOCKS أسهل بعد، لأنه يمرّر التدفق دون أن يبالي بما بداخله.

حيث لا يدعم العميل أي وسيط، يكون نفق SSH عبر 443 هو ما يبقى عادةً. وهو يضيف طبقة ثانية، وقد يكون لمشغّل الشبكة رأي فيه، فاعتبره جسرًا لرحلة واحدة لا معمارًا.

احسب ثمن البديل قبل أن تحتفظ به

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

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