لماذا لا يستطيع وسيط Cloudflare نقل OpenVPN على اسم واحد

تشغّل آلة واحدة الموقع وخادم OpenVPN، والإغراء هو توجيه اسم مضيف واحد إليها وترك السحابة البرتقالية ترتّب حركة المرور. الوسيط يرتّب HTTP وHTTPS. لكنه لا يرتّب جلسة OpenVPN، أيًّا كان المنفذ الذي تستخدمه تلك الجلسة. اسمان، أحدهما مباشر والآخر عبر الوسيط، لا يكلّفان شيئًا ويزيلان فئة الالتباس بأكملها.

اسمان، وناقلان

أعطِ الموقع سجلاً مارًّا عبر الوسيط حتى تمرّ حركة HTTP وHTTPS الخاصة به عبر Cloudflare. وأعطِ الـ VPN سجلاً بـ DNS فقط يُحلّ مباشرة إلى مدخل الـ VPN العام، ودع العميل يستخدم منفذ UDP أو TCP الذي ضُبط عليه.

يمكن أن ينتهي الاسمان إلى آلة الأصل نفسها. الفرق هو ما يحدث بين العميل وتلك الآلة، وذلك الفرق هو جوهر الفصل.

تسرد مرجع منافذ الشبكة لدى Cloudflare المنافذ التي يقبلها وسيط الويب العادي. تلك القائمة تخص HTTP وHTTPS على تلك المنافذ، لا البروتوكولات العشوائية التي تصادف أنها تشترك في رقم.

المنفذ ليس البروتوكول

نقل OpenVPN إلى TCP 443 لا يحوّله إلى HTTPS. لا يزال الوسيط يتوقع طلب HTTP في بداية الاتصال، بينما يرسل عميل OpenVPN رسالة تحكم ثنائية بدلاً من ذلك. يفشل الاتصال بطريقة تبدو كحجب شبكي لأن شيئًا مفيدًا لا يصل إلى السجلات.

إذا كان الشرط حقًا وضع منتج من Cloudflare في مسار بيانات الـ VPN، فقيّم منتجًا يوثّق دعمه للبروتوكول الذي تحتاجه. لا تفترض أن السحابة البرتقالية نفق TCP أو UDP عام، لأنها وسيط عكسي لحركة الويب له وظيفة محددة.

السجل بـ DNS فقط هو الجواب الممل الذي ينجح، وهو أول ما ينبغي اللجوء إليه.

آلة واحدة لا تزال تحتاج إلى مستمعين اثنين

الأسماء المنفصلة لا تسمح لعلميتين بربط العنوان والمنفذ والناقل نفسه في الوقت ذاته. إذا كان خادم الويب يحتفظ أصلاً بمنفذ TCP 443 على جميع العناوين، فلا يمكن لنسخة OpenVPN أن تأخذه أيضًا دون ترتيب مقصود.

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

الشهادات تتبع الاتصال الذي تحميه

اتصال المتصفح بـ TLS إلى Cloudflare واتصال Cloudflare بأصلك هما علاقتان منفصلتان بشهادتين منفصلتين. يرى المتصفح شهادة الحافة. ويقدّم الأصل شهادته الخاصة إلى Cloudflare، وشهادة Cloudflare Origin CA مخصصة لتلك العلاقة الثانية بالتحديد.

تلك الشهادة الأصلية موثوقة من Cloudflare في وضع Full (strict) وليست شهادة متصفح موثوقة عمومًا. إذا زار أحدهم اسم المضيف بـ DNS فقط مباشرة وحصل على تحذير، فهذه نتيجة متوقعة لمسار ثقة متغيّر، وليست دليلاً على توقف التشفير.

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

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

الانكشاف يتبع الاسم

سجل VPN بـ DNS فقط ينشر العنوان الذي يشير إليه. إذا كان ذلك العنوان هو أصل الويب أيضًا، فالأصل غير مخفي، ووصفه بأنه مخفي لأن الاسم الآخر يمر عبر الوسيط خطأ يبقى حتى يفحصه أحدهم.

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

أبقِ الروابط المولدة على اسم الويب العام ومخطط HTTPS، وأبقِ ملفات تعريف العميل على اسم الـ VPN بالبروتوكول والمنفذ الحقيقيين. لا ينبغي أن تعتمد أي من الخدمتين على تبديل إعداد الوسيط للأخرى أثناء التشغيل العادي.

ترتيب العمل: اسم عبر الوسيط للموقع، واسم بـ DNS فقط للـ VPN، ومستمعان منفصلان، وشهادة لكل علاقة، ثم اختبار واحد يثبت أن كل اسم لا يصل إلا إلى الخدمة التي يجب أن يصلها.