OpenVPN على المنفذ 443 ما زال محجوبًا؟ تحقّق مما يفتّشه المسار

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

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

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

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

تغليف التدفق يخلق نقطتي فشل

غلاف TLS مثل stunnel يعيد الشكل المتوقع: يتصل العميل بمستمع محلي، ويفتح الغلاف جلسة TLS حقيقية إلى الخادم على 443، ثم يمرّر غلاف ثانٍ على الخادم البايتات المفكوكة إلى خدمة VPN. تبدو الجلسة الخارجية الآن كأي اتصال HTTPS آخر. وينبغي لخدمة VPN على الخادم أن تستمع على loopback فقط، لأنه لا شيء خارج الغلاف يحتاج إلى الوصول إليها.

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

المسار إلى الغلاف هو الفخ

بمجرد أن يصعد النفق، يشير المسار الافتراضي إليه، وتحتاج جلسة TLS الخارجية إلى مسار لا يدخل النفق الذي تحمله. عميل VPN عادي يحمي العنوان الذي يتصل به؛ أما العميل المغلف فيتصل بـ loopback الخاص به، لذا يغيب عنوان وجهة الغلاف عن تلك الحماية.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

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

اقرأ التوقيت قبل أن تغيّر أي شيء

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

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

سجّل السلوك الملاحظ: كم دامت الجلسة، وهل انفتح المقبس، وهل سجّل الغلاف مصافحة. كل واحد منها يضيّق الاختبار التالي.

اختبر متغيرًا واحدًا في كل مرة

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

غيّر عنصرًا واحدًا في كل محاولة. منفذ جديد وغلاف جديد وشفيرة جديدة في الجولة نفسها تتركك عاجزًا عن القول أيها كان الأهم.