WireGuard داخل LXC أو جهاز افتراضي على Proxmox: أين يجب أن يعمل؟

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

الضيف من نوع LXC يعمل داخل نواة المضيف

تثبيت wireguard-tools داخل حاوية يمنحك برنامج التحكم، لا نواة خاصة. الواجهة wg0 التي تنشئها تُسجَّل في مكدس الشبكة لدى المضيف وتظهر في قائمة وحدات النواة لديه. لهذا قد تجتاز الحاوية كل فحوص الحزم ثم تفشل عند أول أمر wg حين تفتقر نواة المضيف إلى الوحدة. ويوضح مرجع حاويات Proxmox هذا النموذج القائم على نواة مشتركة، إلى جانب حدود نطاق الأسماء والامتيازات التي تعمل داخلها.

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

نواة المضيف أيضاً تبعية مشتركة. تحديث نواة Proxmox يغيّر تنفيذ WireGuard تحت كل حاوية دفعة واحدة، وهذا مريح إلى أن يختلف تحديث ما مع توقعات حاوية ما.

المضيف أو الحاوية أو الجهاز الافتراضي: ما يملكه كل موضع فعلاً

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

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

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

ثلاثة شروط تختار عنك

إذا كان النفق يحتاج إصدار نواة أو ميزة في WireGuard لا يوفرها مضيف Proxmox، فتوقف هنا واستخدم جهازاً افتراضياً. لا يمكنك تثبيت نواة أحدث داخل حاوية، ولا ينبغي أن تستبدل نواة الهايبرفايزور لإرضاء ضيف واحد.

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

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

السؤال الرابع نادراً ما يكون حاسماً لكنه جدير بالذكر: هل يحتاج شيء آخر على المضيف إلى رؤية واجهة النفق؟ إذا كان الجواب نعم، فإن التشغيل على المضيف أو في حاوية يبقي هذه الرؤية محلية، بينما يفرض الجهاز الافتراضي عليك التوجيه بين الضيف والمضيف.

أثبت الموضع قبل توجيه حركة المرور عبره

بعد التثبيت، أكّد أي نواة تخدم الواجهة فعلاً وما إذا كانت الحاوية قد مُنحت سلطة كافية للحفاظ عليها:

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

ثم افحص جانب إعادة التوجيه من المضيف، لأن المصافحة وحدها تثبت فقط أن النفق قائم. استخدم ip route get لعنوان عميل وتأكد من أن القفزة التالية والواجهة تطابقان التصميم، وتأكد من وجود مسار العودة في الطرف الآخر.

اترك النشر بمالك مكتوب: أي نواة تحمل التنفيذ، وأي نطاق أسماء يضم الواجهة، وأي النطاقات يُسمح للبوابة بإعادة توجيهها. تلك الجملة تمنع حوادث أكثر من أي مقارنة معيارية بين المواضع الثلاثة.