شبكات VLAN للعملاء أم جذع موسوم: اختر وضع OpenVPN المناسب

يصل طلبان بصياغة تكاد تكون واحدة: ضع كل عميل VPN في شبكة VLAN مختارة، أو انقل جذع VLAN قائمًا عبر الـ VPN. هما منتجان مختلفان. الوضع المدمج في OpenVPN الواعي بـ VLAN هو نموذج تبديل للطلب الأول، وليس مرادفًا لنقل الوسوم الشفاف. واختيار الوضع الخاطئ ينتج تصميمًا يبدو مهيأً ثم يُسقط بصمت الإطارات التي تهمك.

ما يبنيه الوضع الواعي بـ VLAN فعليًا

عند تفعيل vlan-tagging في نشر TAP مخصص للخادم، يمثّل البرنامج الخفي جهاز TAP الخاص به وكل عميل متصل كمنافذ على مبدّل داخلي. منافذ العملاء غير موسومة، ويُضبط ربطها بـ VLAN على الخادم عبر سياق vlan-pvid الخاص بكل عميل، لا عبر أي شيء يرسله العميل. وهذا هو جوهر النموذج: العضوية قرار من جانب الخادم بشأن نظير موثّق. ولا يحتاج أي شيء في ملف تعريف العميل إلى معرفة شبكة VLAN التي ينتمي إليها.

يحصل جانب TAP في الخادم على سياسة قبول خاصة به، موسومة أو غير موسومة، عبر vlan-accept. ولا يحدث التمرير داخل ذلك المبدّل إلا بين VID متطابقة، بما في ذلك عند تفعيل client-to-client، لذا لا يستطيع عميلان في شبكتي VLAN مختلفتين الوصول أحدهما إلى الآخر عبر الخادم رغم اتصال كليهما به.

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

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

ما يتطلبه الجذع الشفاف بدلًا من ذلك

نقل إطارات موسومة أصلًا من طرف إلى طرف يبدأ بإيقاف المعالجة الواعية بـ VLAN. فنموذج التبديل والحفاظ على الوسوم بديلان، وتفعيلهما معًا يعني أن تطلب من ميزة أن تؤدي عمل الأخرى.

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

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

ثلاثة شروط تحسم الجواب

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

ثانيًا، من يخصص VLAN؟ إذا كان الجواب «الخادم، استنادًا إلى من وثّق نفسه»، فنموذج التبديل يناسب. وإذا كان الجواب «البنية التحتية للمبدّلات القائمة، بوسوم موجودة أصلًا»، فأنت تحتاج تصميم الجذع.

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

اختبار الاختيار الذي قمت به

وصّل عميلًا يجب أن يكون في شبكة VLAN المسموحة وآخر يجب ألا يكون، ثم اختبر من الطرف الفعلي لا من الخادم نفسه. فالوصول من جانب الخادم يثبت وجود الجسر أو المبدّل؛ لكنه لا يثبت في أي شبكة VLAN هبط العميل.

ip -d link show tap0
bridge vlan show

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

سجّل أي التصميمين يستخدمه النشر. فملاحظة تقول «واعٍ بـ VLAN» غامضة، والمهندس التالي سيفترض التصميم الذي تعلمه أولًا. ويقدّم مرجع OpenVPN لشبكات VLANتعريفًا لسلوك المبدّل والسياق الخاص بكل عميل، وهو أقصر طريق للتأكد من النموذج الذي تشغّله.