OpenVPN عبر وكيل HTTP: اقرأ رد CONNECT أولاً
وكيل CONNECT يمرر البايتات، لذا يحتاج الطرفان إلى TCP. اقرأ 407 و403 و503 قبل لوم الشهادات، وأبقِ التحقق من الخادم مفعلاً.
وجّه عميل VPN إلى وكيل HTTP مؤسسي، فأول حقيقة مفيدة هي أن الوكيل لا يتحدث بروتوكول VPN. يفتح اتصال TCP عادياً إلى العنوان الذي ذكرته ثم يتنحى جانباً، تاركاً عميلك والخادم يجريان تبادلهما الخاص عبر ذلك التدفق. كل ما يحتاجه العميل، من نوع النقل إلى مستمع الخادم، يجب أن يطابق هذا الترتيب. عدم تطابقين يفسران معظم حالات الفشل: ملف تعريف UDP موجّه إلى وكيل CONNECT، ورد وكيل يُفهم خطأً على أنه خطأ VPN.
ما ينقله الوكيل، وما لا ينقله
الوكيل هو مجرد قفزة نقل. لا يصبح وكيل متصفحك، ولا يخزن المواقع التي تزورها عبر النفق، ولا يرى حركة المرور الداخلية إلا إذا ضبط أحدهم التفتيش عمداً. النفق الذي يفتحه معتم عليه بحكم التصميم.
هذا يعني أيضاً أن الوكيل لا يستطيع إصلاح خادم ليس لديه مستمع مطابق. إذن الوصول إلى وجهة ما ووجود خدمة تستمع على تلك الوجهة حقيقتان منفصلتان، والأولى فقط تخص مسؤول الوكيل.
يجب أن يكون الناقل TCP على الطرفين
وكيل CONNECT التقليدي يمرر تدفق بايتات فقط ، لذا يجب أن يستخدم العميل نقل تدفق. مقطع عميل لتلك الحالة يبدو هكذا:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128يحتاج جانب الخادم إلى مستمع TCP حقيقي على المنفذ المذكور في سطر remote. تغيير proto udp إلى proto tcp-client في ملف تعريف ينشئ عميلاً يتوقع تدفقاً؛ لكنه لا ينشئ التدفق على الطرف الآخر. وإذا كان الخادم نفسه يستجيب أيضاً عبر UDP على ذلك المنفذ، فهذا مستمع مختلف، وليس وضعاً ثانياً للمستمع نفسه.
حيث توجد نسخة TCP منفصلة، تكون واجهة النفق ومجمع العناوين والتوجيه فيها موارد خاصة بها. نسخ إعداد عامل وتعديل كلمة النقل يترك تلك الموارد تشير إلى النسخة الأصلية، ما ينتج اتصالاً ينجح في المصادقة ثم لا يوجه شيئاً.
اقرأ رد الوكيل قبل نتيجة VPN
أول تبادل للعميل هو سطر طلب يذكر مضيف الوجهة ومنفذها. والرد على ذلك السطر يخبرك إن كان هناك تدفق بايتات أصلاً، ويصل قبل التحقق من أي شهادة أو بيانات اعتماد:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
رد من فئة 200 على CONNECT يعني أن التدفق موجود. لكنه لا يقول شيئاً عن كون شهادة البوابة موثوقة، أو تطابق المفتاح المشترك، أو صلاحية حساب المستخدم. تلك الفحوص تجري بعد ذلك، داخل التدفق، وتفشل برسائل العميل نفسه لا بسطر حالة HTTP. اقرأ سجل العميل بحثاً عن أول OpenVPN حدث بعد مصافحة الوكيل، لا عن آخر سطر قبل إغلاق النافذة.
بيانات اعتماد الوكيل وبيانات اعتماد VPN كثيراً ما تكون هويتين مختلفتين تديرهما فرق مختلفة. خطأ 407 ليس كلمة مرور سيئة على حساب VPN، والشهادة المرفوضة ليست مشكلة صلاحيات في الوكيل.
ما لا يكشفه CONNECT
نفق CONNECT الصريح ليس اعتراضاً. الوكيل يمرر البايتات ولا ينهي جلسة TLS الخاصة بـ VPN، لذا يبقى تحقق العميل من شهادة الخادم ذا معنى ويجب أن يبقى مفعلاً. تعطيل التحقق لتجاوز وكيل ما هو حل لمشكلة أخرى غير مشكلتك.
توجد ترتيبات منفصلة تنهي فيها مؤسسة TLS وتفتشه عمداً. تلك تتطلب إعداد ثقة خاصاً بها وقرار سياسة خاصاً بها، وليست ما يطلبه سطر http-proxy عادي.
تكلفة TCP داخل TCP
حمل النفق عبر TCP يبقي التدفق الخارجي منظماً ومعاد الإرسال، وحركة المرور الداخلية عادة TCP أيضاً. آلية التعافي هذه لا تنسق مع تلك، لذا يمكن لمقطع واحد مفقود أن يوقف كل ما يتشارك ذلك التدفق الخارجي حتى يُعاد إرساله. هذه مقايضة حقيقية للتوافق، وليست ترقية مجانية.
استخدم مسار الوكيل عندما لا تترك لك الشبكة بديلاً، وفضّل مسار UDP مباشراً حيث تسمح السياسة. وفي الحالتين، تأكد من أن الوكيل نفسه والوجهة نفسها وملف التعريف نفسه تصل إلى المرحلة التالية بعد أي تغيير؛ فمتصفح يحمّل صفحة على ذلك العنوان يمارس بروتوكولاً مختلفاً ولا يثبت شيئاً عن النفق.