تقديم OpenVPN عبر TCP وUDP من مضيف واحد
قبل الإصدار 2.7 يربط كل عملية نقلًا واحدًا. قارن زوج TAP موصولًا بجسر، وشبكتي TUN فرعيتين، ومجمعًا مشتركًا، ثم طابق كل ملف تعريف مع مستمعه.
الشبكات التي تسمح بـ TCP 443 فقط تتعايش مع شبكات تمرر UDP بسهولة، وعلى خادم واحد أن يخدم الاثنين. ملف تعريف يحمل proto udp يجيب المجموعة الثانية ويفشل مع الأولى، وتعديل الإعداد نفسه ليقول proto tcp لا ينشئ مستمعًا ثانيًا. يختار هذا التوجيه نقلًا واحدًا لعملية واحدة. وكل شيء آخر يتبع هذا القيد.
إما أن تشغّل أكثر من عملية، أو أن تشغّل إصدارًا يمكنه ربط عدة مقابس في وقت واحد.
عملية واحدة تربط نقلًا واحدًا قبل 2.7
نسخة المجتمع من OpenVPN تربط المقبس الذي يصفه proto ، وذلك التوجيه يختار نقلًا واحدًا للنسخة. TCP وUDP مكدسان منفصلان، لذا يمكن أن يحتجز الرقم نفسه للمنفذ فيهما في الوقت نفسه، لا أن تحتجزه عملية واحدة. لذلك يمنحك خط 2.6 نقلًا واحدًا لكل خدمة. أزال OpenVPN 2.7 هذا القيد للخوادم، التي يمكنها ربط عدة مقابس عبر عبارات --local متعددة في عملية واحدة.
تحقق من الإصدار قبل التصميم على أي من الجوابين، لأن ترتيب 2.7 نموذج تشغيلي مختلف بصيغة إعداد خاصة به. الدليل المكتوب لـ 2.6 يصف عمليتين حتى عندما لا يقول ذلك.
ثلاث طرق لتشغيل نسختين
مع واجهات TAP، شغّل نسخة لكل نقل واجسر جهازي tap على المضيف. تنتهي مجموعتا العملاء في نطاق بث واحد، ما يتيح مجمع عناوين واحد لتغطيتهما ويُبقي البروتوكولات المعتمدة على البث تعمل. مع TUN لا يتوفر الجسر، لذا يمنح أبسط تقسيم كل نسخة شبكتها الفرعية ويترك التوجيه يفصل بين مجموعتي العملاء. الخيار الثالث يحتفظ بمجمع واحد بأن تستدعي كل نسخة سكربت learn-address يثبت مسار /32 للعميل عبر جهاز تلك النسخة.
هذا الترتيب الثالث هو ما يطلبه الناس وهو الأكثر حاجة إلى العناية، لأن السكربت يصبح جزءًا من مسار البيانات وعليه معالجة أحداث الإضافة والتحديث والحذف بشكل صحيح.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
أبقِ النسختين منفصلتين
تحتاج كل نسخة أيضًا إلى منفذ أو عنوان منفصل وملف حالة منفصل ووجهة سجل منفصلة. خدمان يضيفان إلى ملف حالة واحد ينتجان خرجًا لا يمكن قراءته أثناء حادث، وهو بالضبط وقت حاجتك إليه. إذا ربطت نسخة ثانية عنوانًا معينًا، فيجب أن يكون ذلك العنوان موجودًا على المضيف عند بدء العملية؛ وإلا فإنها تخرج بفشل ربط قبل أن تقول شيئًا عن المفاتيح.
سمِّ الوحدات وملفات التعريف بحيث يكون النقل واضحًا من اسم الملف . لا ينبغي للمشغّل التالي أن يفتح إعدادًا ليعرف أيّها TCP.
طابق ملف التعريف مع المستمع
خادم يشغّل proto tcp يتوقع ملف تعريف عميل يحمل proto tcp-client ، وملف تعريف لا يزال يحمل proto udp مقابل ذلك المستمع ينتهي مهلته دون خطأ يستطيع المستخدم التصرف بناءً عليه . أبقِ ملفَي تعريف إذا كان النشر يقدم النقلين، وسمّهما بحيث تعرف الدعم أيّهما جُرّب. رقم المنفذ وحده لا يصف النقل.
قواعد جدار الحماية تتبع التقسيم نفسه: قاعدة لـ UDP 1194 لا تقول شيئًا عن TCP 1194، وقاعدة لعنوان واحد لا تغطي المستمع الآخر.
اقرأ رؤية الخادم أولًا
ابدأ بـ ss -lntup على الخادم وتأكد من ظهور مستمع TCP ومستمع UDP. ثم وصّل عميلًا من كل نوع وافحص خرج الحالة بحثًا عن مدخلين بعنوانين مختلفين. إذا كانت المقابس موجودة ولا يصل أي عميل، فالمسار أو جدار الحماية يرفض الحزم قبل أن تراها الخدمة.
المقبس الذي لا يظهر أبدًا هو مشكلة إعداد أو ربط، والمقبس الذي يظهر لكنه لا يسجل أي اتصال هو مشكلة تصفية. يبدو الاثنان متطابقين من جهة العميل، ولهذا تأتي رؤية الخادم نفسه أولًا. تذكّر أن TCP يحمل حجب رأس الصف، لذا فإن تقديمه إجراء للوصول لا ترقية للعملاء الذين لديهم مسار UDP نظيف.