OpenVPN وHTTPS على المنفذ 443: من يملك المستمع؟
المنفذان TCP وUDP 443 مقبسان منفصلان. مشاركة مستمع TCP واحد تتطلب مالكًا، ومشاركة منفذ OpenVPN ترتيب ضيق وليست حيلة وكيل.
يمكن لخدمتين أن تجيبا معًا على المنفذ 443 دون أن تتنافسا أبدًا، لأن المستمع يُحدَّد بالمشترك الثلاثي: النقل والعنوان والمنفذ معًا، لا بالرقم وحده. ضع خادم ويب و OpenVPN على جهاز واحد، والسؤال الوحيد الجدير بالإجابة أولًا هو أي مقبس تطلبه كل عملية من النواة. اكتب تلك القائمة قبل أن تعدّل أي إعداد، وستشرح معظم أخطاء «العنوان قيد الاستخدام» نفسها. كل ما يأتي بعد القائمة خيار بين مستمع UDP، أو مقبس TCP مشترك، أو واجهة أمامية توجّه حسب البروتوكول.
ابدأ بالمقبس الذي تطلبه كل عملية
تنجح عملية الربط أو تفشل وفق ذلك الثلاثي، لذا لا يتصادم عفريتان إلا حين تتطابق الأجزاء الثلاثة. لهذا يتعايش موقع ويب على TCP 443 مع مستمع OpenVPN على UDP 443 إلى ما لا نهاية، ولهذا فإن نقل أحدهما إلى عنوان محلي ثانٍ على المضيف نفسه ينهي الجدل أيضًا. اقرأ المستمعين الأحياء بدلًا من الملفات التي كان يفترض أن تنشئهم، لأن تضمينًا قديمًا أو ملف وحدة منسيًا يعيش أطول من التعديل الذي تذكر أنك أجريته.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
شغّل ss -lntup بصلاحيات root واقرأ كل سطر يذكر 443، بما في ذلك مدخلات IPv6. عادةً يقبل مستمع v6 العام حركة v4 أيضًا، وهكذا يبقي مستمع نسيته المنفذ مشغولًا بعد أن تغيّر الملف الذي ظننت أنه المسؤول. إن فاجأك اسم عملية، فضيِّق المخرجات باستخدام ss -lntup 'sport = :443' قبل أن تلمس أي شيء.
حوّل النفق إلى UDP عندما تسمح الشبكة بذلك
يتجنب مستمع UDP التصادم تمامًا وهو عادةً أقصر إصلاح، لأن لا مقبس يُشارَك ولا منتجًا إضافيًا يدخل المسار. لكنه ليس مجانيًا. بعض شبكات العملاء تُسقط UDP 443 دون إرسال إعادة تعيين، فيتوقف النفق عن التشكّل بدلًا من أن يفشل في الربط، ويبلّغ المستخدم عن انقطاع VPN دون أي خطأ يُقرأ. كما يعيش مستمع UDP أطول من إعادة تشغيل طبقة الويب، وهذا مهم على جهاز يُعاد نشر موقعه كثيرًا. اختبر من الشبكة التي يوجد فيها المستخدمون، لأن صدفة على الخادم تثبت فقط أن الخادم يستطيع الوصول إلى نفسه.
غيّر النقل في إعداد الخادم وفي ملف العميل معًا. الملف الذي ما زال يطلب TCP سيدور في إعادة اتصال متكررة أمام مستمع UDP فقط، ويبدو ذلك كعطل شبكة حتى تقارن الملفين.
دع عملية VPN تملك TCP 443 ومرّر الباقي
يقرأ OpenVPN المجتمعي في وضع خادم TCP أول بايتات الاتصال الوارد ويمرّر كل ما ليس بروتوكوله إلى خلفية HTTPS، وهذا ما تُستخدم من أجله توجيهات port-share. الخلفية خادم ويب عادي مع TLS مفعّل، يُحدَّد بالمضيف والمنفذ في ذلك التوجيه لا بعنوان URL.
port-share 10.0.0.5 8080
في جهاز يحتفظ فيه الموقع بعنوان خاص ثانٍ، يرسل ذلك السطر حركة غير VPN إلى 10.0.0.5:8080، لذا يجب ربط المضيف الافتراضي HTTPS هناك ويجب أن تسمح الجدار الناري بالقفزة المحلية. على خادم الويب إنهاء TLS بنفسه، لأن البايتات الواصلة هي مصافحة المتصفح الأصلية ولا شيء بينهما فك تشفيرها. وجّه التوجيه إلى مستمع HTTP عادي فيحصل المتصفح على خطأ طريقة غير صالحة، وهو يُقرأ كموقع معطوب لا كخلفية في غير موضعها. التوجيه موجود في وضع خادم TCP فقط، ومستمع UDP لا يملك تدفقًا لفحصه.
لأن عملية VPN تقبل كل اتصال، ترى تطبيق الويب الطلب الممرَّر آتيًا من أحد عناوين المضيف نفسه لا من الزائر. أي شيء يحتاج عنوان العميل الحقيقي يعتمد على دعم بروتوكول PROXY في الخلفية أو على واجهة أمامية تضيفه. نقل الخلفية إلى عنوان محلي آخر لا يعيد عنوان الزائر؛ بل يغيّر فقط أي عناوين المضيف يسجّلها الموقع. ضع هذا القيد في ملاحظات النشر قبل أن يطرح تقرير تحليلات السؤال.
الوكيل العكسي أداة خاطئة؛ الموجّه من الطبقة الرابعة ليس كذلك
ينهي الوكيل العكسي HTTP جلسة TLS كي يقرأ الطلبات، ما يعني أنه لا يستطيع تمرير تدفق OpenVPN دون مساس. الموجّه من الطبقة الرابعة الذي يمرّر حسب SNI أو فحص الحزمة الأولى يمكنه أن يتقدّم الاثنين، بشرط ألا ينهي الجلسة التي يعتمد عليها VPN. الجهازان يبدوان متشابهين في رسم تخطيطي ويتصرفان تصرفًا مختلفًا تمامًا عند المقبس.
يشحن Access Server التجاري إعدادات مشاركة منفذ خاصة به، وهي لا تُقابل واحدًا لواحد مع توجيه المجتمع. حدّد المنتج والإصدار قبل تكييف دليل كُتب للآخر. الإعداد المنسوخ الذي يُتجاهل بصمت أسوأ من عدم وجود إعداد، لأن قائمة المستمعين تظل تبدو معقولة بعد ذلك.
اختبر الموقع والنفق كمسارين منفصلين
حمّل الموقع ووصّل النفق، ثم اقرأ قائمة المستمعين مجددًا لترى أي عملية تملك 443 الآن. صفحة تُحمّل لا تثبت شيئًا عن VPN، ونفق يتصل لا يثبت شيئًا عن الموقع، رغم أن كليهما يستخدم الرقم نفسه. الأوامر الثلاثة أدناه تفحص المقبس المشترك ومسار الويب وخدمة VPN بهذا الترتيب.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
قارن عنوان العميل في سجل وصول الخلفية مع نظيره في سجل VPN في اللحظة نفسها. إذا سجّل الموقع كل زائر كأنه المضيف نفسه، فالتمرير يعمل ومعالجة العنوان لا تعمل. وإذا صمت السجلان، فلم تسلّم الواجهة الأمامية الاتصال قط. في الحالتين تحسم قائمة المستمعين من يقبل المقبس، وهذه هي الحقيقة التي يجب تأكيدها قبل أن تغيّر ملفًا آخر.
اترك خريطة المستمعين بجانب الإعداد ليعرف الشخص التالي الذي يلمس 443 أي عملية تقبل وأين ذهب البروتوكول الآخر. أكّد الملكية بعد التغيير بدلًا من الثقة بما كان التعديل يهدف إليه.