VPN موجّه أم جسري: اختر حسب ما يجب أن يصل إليه العميل
التوصيل الموجّه يقدّم خدمات محددة، والتوصيل الجسري يضم إلى مقطع. قرّر انطلاقًا مما يجب أن يصل إليه العميل، ثم تحقّق من الحدود التي بنيتها.
تصل تذكرتان في اليوم نفسه: مستخدم يحتاج تطبيق ويب داخليًا، ومهندس يحتاج جهاز قياس مختبريًا أن يتصرف كأنه على مقطع Ethernet نفسه. يُجاب عن الاثنين بوضعهما على الـ VPN، وهنا تبدأ المشكلة. النفق الموجّه والنفق الجسري يمدّان علاقتين مختلفتين، وواحد فقط منهما يناسب كل طلب. اختيار الطوبولوجيا قرار وصول، لا إعداد تشفير.
طلبان يبدوان متطابقين عند مكتب التذاكر
مطلب الموظف خدمة يمكن الوصول إليها عبر IP من جهاز لا تتحكم فيه. مطلب المهندس على مستوى الوصلة: يتوقع الجهاز أن يرى إطارات Ethernet واكتشاف البث، وربما DHCP من المقطع الذي يظن أنه عليه.
هذان سؤالان مختلفان، والجواب عن كليهما بجسر يوسّع وصول الموظف إلى شبكة المكتب المحلية كلها بلا سبب.
اكتب المطلب جملةً قبل الاختيار: أي وجهات، وأي بروتوكولات، وأي أقران يجب أن تبدو محلية. إن كان الجواب مضيفًا ومنفذًا، فالتوجيه يغطيه. وإن كان الجواب علاقة على مستوى الإطار مع أجهزة لا تتحدث إلا بالبث، فقد يكون الجسر الخيار الوحيد. وما بين ذلك يستحق مقطع اختبار بدل شبكة الإنتاج.
المسار أضيق من عضوية الشبكة المحلية
العميل الموجّه يحصل على عنوان على شبكة نفق فرعية ومسارات للبادئات التي تختارها. يستطيع الوصول إلى خادم التطبيق ولا شيء غيره، إن كان هذا ما تقوله السياسة. تصبح البوابة نقطة الإنفاذ، بشرط أن يعبرها كل مسار ذي صلة.
لا تخلط بين المسار والصلاحية. إخبار العميل كيف يصل إلى شبكة فرعية لا يمنعه من محاولة وجهة أخرى.
طبّق التحكم في الوصول حيث يمكنه إنفاذ التدفق فعلاً، وأبقِ صلاحيات التطبيق نفسه في مكانها. قاعدة إعادة توجيه واسعة أو واجهة ثانية منسية قد تمنح أكثر مما يوحي به المخطط. اقرأ القواعد الفعلية لا المقصودة. ثم اختبر وجهة يجب أن تفشل، لأن سياسة لم يحاول أحد خرقها ليست إلا فرضية.
الجسر يغيّر سؤال القبول
الجسر يدمج واجهة فعلية وجهاز TAP في مبدّل برمجي، فتتصل الأجهزة البعيدة بنطاق البث نفسه. هذه قدرة حقيقية وخطر حقيقي: الجهاز البعيد لم يعد ضيفًا موجّهًا، بل صار مشاركًا.
قرّر أي الأجهزة يجوز لها الانضمام، وأي أنواع الإطارات يجب أن تعبر، وأين تُحجب التفاعلات غير المرغوبة. يصبح العنونة وسلطة DHCP جزءًا من الشبكة المشتركة، وخادمَا DHCP على مقطع واحد ينتجان الفوضى التي تتوقعها بالضبط.
بالنسبة للجهاز، يكون مقطع اختبار مخصص أنسب عادة من شبكة المكتب. أبقِ وصول الإدارة خارج التجربة، وحدّد كيف يُزال المشارك المؤقت عند انتهاء العمل.
الترشيح موجود في الطوبولوجيتين
الجسر ليس غير قابل للترشيح بطبيعته، والمسار ليس آمنًا بطبيعته. لترشيح الجسور في Linux نقاط ربط خاصة به وصيغة قواعد خاصة به، وقاعدة مكتوبة لإعادة توجيه IP الموجّه لا تنطبق تلقائيًا على الإطارات الجسرية.
تحقّق مما تدعمه المنصة فعلاً قبل أن تعد بحدود:
bridge link show
nft list ruleset
تصف TUN و TAP حركة الواجهة، لا التشفير. تبديل الواجهات لا يصلح شيئًا من ذلك: مصادقة الأقران، والمفتاح المسروق، وسياسة التشفير القديمة كلها تبقى بعد التغيير. لا يزال الطرفان بحاجة إلى إعدادات متطابقة وما زالت مدعومة.
أثبت الحدود بثلاث محاولات
القبول ثلاث ملاحظات، لا مراجعة مخطط. يجب أن تعمل العملية المطلوبة، ويجب أن تفشل وجهة غير ذات صلة، ويجب أن تبقى خدمات إدارة البوابة نفسها بعيدة عن المتناول.
نفّذ المسارات المسموحة والمرفوضة من العميل نفسه، وسجّل الاثنين:
curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5
بالنسبة للجسر، أضف فحوص مستوى الوصلة: هل تعبر حركة الاكتشاف المسموحة، وهل تأتي العنونة من السلطة المقصودة، وهل زال المشارك المؤقت بعد الإزالة. عندما يفي IP الموجّه العادي بالمطلب، فإن الانضمام إلى مقطع Ethernet المكتبي يحتاج تبريرًا منفصلًا، وينبغي كتابته قبل التغيير.