أوقف وصول عملاء VPN إلى بعضهم البعض على النفق

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

مسار إلى الخدمة المشتركة ليس تصريحًا بين الأقران

الإعلان عن شبكة العملاء الفرعية يخبر القرين كيف يضع حزمة على السلك نحو عنوان عميل آخر. أما ما إذا كانت تلك الحزمة ستُسلَّم فيُحسم بعد ذلك، بما يمررها. على بوابة Linux تكون هذه سلسلة FORWARD؛ وداخل خادم في مساحة المستخدم يكون جدول الجلسات الخاص بالنفق. المسار يجيب عن قابلية الوصول ويترك الإذن دون مساس.

ولهذا فإن فحص العزل الذي يقرأ المسارات فقط لا يثبت شيئًا. يمكن دفع /24 إلى كل عميل بينما تُسقَط كل حزمة بين قرينين عند خطاف التمرير. الحالة الخطرة هي العكس: لا قاعدة صريحة، وإعداد افتراضي متسامح، وعزل لا وجود له إلا لأن أحدًا لم يختبره.

اكتب المتطلب في سطر واحد قبل أن تفتح طرفية. الوصول إلى كتلة الخدمة ومضيف القفز، ولا شيء غير ذلك داخل كتلة العملاء.

اكتشف من يمرر حزمة القرين فعليًا

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

ينتمي WireGuard إلى المجموعة الأولى: ليس فيه مفتاح بين الأقران، فحزمة من 10.8.0.4 إلى 10.8.0.5 تصل على wg0، وتصطدم بخطاف التمرير، وتُوجَّه خارج wg0 من جديد عندما يغطي AllowedIPs العنوانين. أما OpenVPN فهو المجموعة الثانية متى ضُبط client-to-client في إعداد الخادم، لأن ذلك التوجيه يناول الحزمة بين الجلسات في مساحة المستخدم. افحص الإعداد المحمّل بحثًا عن ذلك التوجيه قبل أن تكتب أي شيء. قاعدة في النواة لا ترى حركة أبدًا لا يمكن تمييزها من قاعدة تعمل، وهكذا ينتهي نشر ما بلا عزل على الإطلاق.

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

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

أعط كل عنوان هوية يمكن سحبها بذاتها

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

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

ضع المنع حيث تعبر الحزمة النفق

على بوابة تمرر حركة WireGuard، تغطي الحالة قاعدتان: اسمح بكتلة الخدمة ثم أسقط بقية كتلة العملاء. زوج الواجهتين يهم بقدر ما تهم العناوين، لأن المطابقة على الوجهة وحدها تلتقط أيضًا حركة قادمة من الشبكة المحلية. حمّلهما بهذا الترتيب كي يُقيَّم الإذن أولًا.

مع nftables يدخل الزوج في جدول مرشِّح inet قائم، الإذن أولًا والإسقاط ثانيًا. كلا التطابقين يثبت زوج الواجهتين إضافة إلى العناوين.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

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

عند تفعيل client-to-client على OpenVPN، لا تطابق قواعد التمرير هذه حركة الأقران أبدًا ويجب أن يكون المنع في ضوابط الخادم نفسها. أبقِ قواعد النواة للحركة الموجهة إلى المضيف، لكن لا تحسبها ضابط العزل.

أثبت المنع من عميل، لا من الخادم

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

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

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

الحزمة المُسقطة والقرين غير المتصل يبدوان كلاهما كمهلة، لذا افحص العدادات قبل أن تستنتج شيئًا. تأكد من أن عداد قاعدة الإسقاط يزداد بينما القرين متصل بشكل واضح. كرر عبر IPv6، حيث تترك قاعدة ip6 الغائبة منع v4 يبدو فعّالًا. سجّل النتائج المقبولة والمرفوضة في دليل التشغيل مع التاريخ، لأن الترحيل التالي سيعيد استنتاج القاعدة.