خادم TAP واحد أم عدة خوادم؟ عملاء OpenVPN على جسر واحد

لا تتطلب عدة عملاء TAP عملية خادم واحدة ومنفذ UDP واحدًا وجهاز TAP واحدًا على المضيف لكل عميل. يمكن لخادم OpenVPN واحد في وضع إيثرنت أن يقبل عملاء موثَّقين كثرًا ويربطهم بجسر واحد، وهذا هو الأسلوب الموثَّق لتوسيع مقطع من الطبقة 2. وتصميم العملية الواحدة هو ما يوثقه الدليل، وهو عادةً الوضع الافتراضي الصحيح.

السؤال الحقيقي هو ما إذا كان ينبغي لهؤلاء العملاء أن يتشاركوا ذلك المقطع. عدد العمليات لا يجيب عن ذلك، لأن خصائص العزل تأتي من الطوبولوجيا لا من عدد البرامج الخدمية العاملة. وبقية هذه المقارنة تدور حول الطوبولوجيتين وما يسهّله كل منهما.

معماريتان، لا إعدادان

يمنح نشر TUN الموجَّه كل عميل وصلة نقطة إلى نقطة داخل نطاق التوجيه لدى الخادم. تتوقف رسائل البث عند الخادم، ولا يستطيع العملاء رؤية أطر بعضهم بعضًا، أما حركة المرور بين العملاء، إن وُجدت، فيجب توجيهها وتصفيتها صراحةً.

يجعل نشر TAP المجسَّر العملاء أعضاء في مقطع إيثرنت واحد. فهم يرون رسائل البث، ويستطيعون حل عناوين بعضهم بعضًا عبر ARP، ويعتمدون على سياسة الجسر والجدار الناري لا على التوجيه لفصلهم. وذلك مفيد عندما يجب أن يظهروا كما لو كانوا موصولين بالمبدّل نفسه.

لذا تدور المقارنة حول ما يحتاج العملاء إلى الوصول إليه، لا حول الأداء. اختر الطبقة أولًا، ثم قرّر عدد العمليات التي تخدمها.

ما تفعله الأداة المساعدة server-bridge

تضبط الأداة المساعدة server-bridge وضع إيثرنت متعدد العملاء. ويأخذ شكل مجمّع العناوين فيها البوابة وقناع الشبكة ونطاقًا مخصصًا داخل الشبكة الفرعية المجسَّرة، مثل بوابة على 192.168.50.1 مع مجمّع من 192.168.50.160 إلى 192.168.50.199.

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

يوجد شكل وكيل DHCP لعمليات النشر التي يوزّع فيها خادم خارجي العناوين. ولهذا الشكل متطلباته المسبقة، وخلط الشكلين ينتج بالضبط التعارض الذي تحذر منه الوثائق. اختر مخصصًا واحدًا للشبكة الفرعية المجسَّرة.

العزل لا يأتي من عدد العمليات

ثماني عمليات OpenVPN موصولة بالجسر غير المقيّد نفسه تتشارك نطاق بث واحدًا. يستطيع العملاء إرسال ARP لبعضهم عبر الجسر، وعدد المستمعين لم يغيّر ذلك شيئًا.

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

إذا كان الشرط فقط أن يصل العملاء إلى خدمات IP معينة، فإن تصميم TUN الموجَّه أبسط عادةً من الجسر مع التصفية. يحصل كل عميل على وصلته الخاصة، وتعيش السياسة في قواعد التوجيه والجدار الناري بدلًا من داخل الجسر.

متى تكون العمليات المتعددة صحيحة رغم ذلك

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

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

ثم تحقق من التصميم بعدة عملاء في الوقت نفسه. تحقق من أن العناوين فريدة، وأن حركة المرور المقصودة بين العملاء تعمل، وأن الزوجين اللذين يجب ألا يتواصلا لا يستطيعان ذلك. ونجاح ping من عميل واحد لا يختبر شيئًا من تصميم تعدد العملاء.

اقرأ الجسر ووضع الخادم من المضيف العامل قبل أن تثق بالمخطط. الإعداد المهم هو الذي حمّله النواة والبرنامج الخدمي فعليًا، وهو أيضًا ما يستطيع المراجع التحقق منه.