تشغيل WireGuard داخل VM على Proxmox خيار عملي. تعزله عن بقية الخدمات، وتأخذ له نسخة احتياطية، وتنقله بسهولة. لكن إعدادات الـVM الافتراضية مصممة للتوافق أولاً لا للسرعة، وقد تكلفك جزءاً كبيراً مما يقدر عليه العتاد.
ثلاثة إعدادات تصنع أغلب الفرق: نوع المعالج، وعدد الأنوية، وطوابير بطاقة الشبكة. وهذا الدليل يشرح كلاً منها، ولماذا يهم، وكيف تتحقق منه.
مثال من الواقع قبل الإعدادات
في قياس على أحد سيرفراتنا، يعمل WireGuard داخل VM بأربع أنوية على معالج Xeon E5-2698 v4. بلغت قدرة التشفير الداخلية نحو 1.7Gbps، وكان التنزيل عبر النفق 57MB/s على منفذ محدد بـ480Mbps.
أي أن أربع أنوية كافية هنا، لأن قدرة التشفير أعلى بكثير من حد المنفذ. فلا معنى لمنح الـVM أكثر مما تحتاج، ولا معنى لتحميل المعالج مسؤولية ما يفرضه السويتش.
نوع المعالج: لماذا cpu host؟
يقدم Proxmox للضيف معالجاً افتراضياً بنوع محدد. والأنواع العامة تُخفي بعض تعليمات المعالج الحقيقي كي يبقى النقل بين العقد سهلاً. وهذا مفيد للتوافق، لكنه قد يضر بالتشفير.
يستعمل WireGuard خوارزمية ChaCha20-Poly1305، ونسختها في نواة لينكس تستفيد من تعليمات مثل AVX2 وAVX-512 إذا توفرت. فإذا لم يرها الضيف، عمل بمسار أبطأ على المعالج نفسه.
لاحظ هنا نقطة يخطئ فيها كثيرون: WireGuard لا يعتمد على AES-NI. فوجود هذه التعليمة في الضيف لا يكفي للحكم على سرعته.
# على عقدة Proxmox
qm set <VMID> --cpu host
# أوقف الـVM ثم شغّلها من Proxmox حتى يُطبَّق التغيير
qm shutdown <VMID>
qm start <VMID>
# داخل الـVM: تحقق من التعليمات
grep -m1 -o -w avx2 /proc/cpuinfo
grep -m1 -o -w avx512f /proc/cpuinfoظهور الكلمة يعني أن التعليمة متاحة للضيف. أما عدم ظهور avx512f فطبيعي على معالجات لا تدعمها. ولا تكفي إعادة التشغيل من داخل النظام، فالـVM تحتاج إلى إطفاء كامل ثم تشغيل.
| الخيار | المزايا | المحاذير |
|---|---|---|
| host | كل تعليمات المعالج متاحة للضيف | النقل الحي صعب بين عقد مختلفة المعالجات |
| x86-64-v3 | يشمل AVX2 ويبقى عاماً | يتطلب معالجات عقد تدعمه |
| x86-64-v2-AES | توافق واسع | لا يشمل AVX2 |
إذا كانت الـVM على عقدة واحدة ولا تحتاج إلى نقل حي بين معالجات مختلفة، فالخيار host هو الأبسط.
كم نواة تحتاج؟
لا يوجد رقم واحد يناسب الجميع. فالحاجة تعتمد على سرعة المنفذ، وعدد العملاء، وقوة النواة الواحدة. والطريقة الصحيحة هي القياس:
- ابدأ بأربع أنوية، فهي نقطة بداية معقولة لمنفذ بمئات الميجابت.
- حمّل النفق بترافيك فعلي مثل iperf3 لعدة دقائق.
- راقب الأنوية كل واحدة على حدة، لا المتوسط العام.
apt install -y sysstat
mpstat -P ALL 2راقب عمودي %soft و%idle. فإذا امتلأت نواة واحدة والبقية فارغة، فالمشكلة في توزيع الحمل، وليست في عدد الأنوية. وزيادة الأنوية لن تفيد عندئذ. أما إذا امتلأت كلها، فهنا يفيد رفع العدد.
تجنب أيضاً إعطاء الـVM أنوية أكثر مما يتسع له الجهاز عملياً. فعلى سيرفر مزدحم، تنتظر الأنوية الافتراضية دورها على الأنوية الحقيقية، وهذا يضيف تذبذباً محسوساً في النفق.
عمود يكشف ازدحام العقدة
في خرج mpstat عمود مهم اسمه %steal. وهو الوقت الذي أرادت فيه النواة الافتراضية أن تعمل، لكن العقدة كانت مشغولة بغيرها. فإذا ارتفع تحت الحمل، فالمشكلة ليست في إعدادك بل في ازدحام الجهاز. وهذا مؤشر مفيد أيضاً حين تستأجر VPS وتريد معرفة نصيبك الحقيقي.
طوابير الشبكة: queues
البطاقة الافتراضية VirtIO هي الخيار الصحيح، فهي أخف من محاكاة بطاقة حقيقية. لكنها تعمل افتراضياً بطابور واحد، فتتركز معالجة الحزم في مسار واحد.
عند تفعيل multiqueue، تتوزع الاتصالات المختلفة على طوابير متعددة، ومن ثم على أنوية متعددة. والقيمة الشائعة هي عدد أنوية الـVM.
# اعرض الإعداد الحالي لتحتفظ بعنوان MAC والجسر كما هما
qm config <VMID> | grep ^net0
# أعد الإعداد مع إضافة queues (مثال)
qm set <VMID> --net0 virtio=<MAC_ADDRESS>,bridge=vmbr0,queues=4انتبه لعنوان MAC. فإذا حذفته من الأمر، يولّد Proxmox عنواناً جديداً، وقد يعطل هذا الاتصال حيث توجد قواعد مرتبطة بالعنوان. وإن كان في السطر الحالي خيارات أخرى مثل firewall=1، فأبقها أيضاً.
ثم تحقق داخل الـVM:
ethtool -l eth0
# إن كان العدد الحالي أقل من الأقصى
ethtool -L eth0 combined 4لكن لا تتوقع أن تتضاعف سرعة نفق واحد. فالـqueues توزع التدفقات المختلفة، ونفق واحد إلى طرف واحد يظهر في العادة كتدفق UDP واحد على البطاقة. وفائدتها تظهر مع عملاء كثيرين أو أنفاق متعددة.
إعدادات أخرى تستحق المراجعة
- حد السرعة في Proxmox. خانة rate في بطاقة الشبكة تقيّد الـVM. وإذا نسيتها، فستبحث عن الاختناق في مكان آخر.
- الجدار الناري على البطاقة. تفعيله يضيف مكونات إلى مسار الحزم. وهو مفيد غالباً، لكن ضبطه يحتاج إلى عناية.
- التخزين. لا تأثير كبير له، فالنفق يتعامل مع الشبكة والمعالج. لا تدفع ثمن قرص سريع من أجل WireGuard وحده.
- الذاكرة. الاستهلاك قليل عادة، لكن احتفظ بهامش، خصوصاً مع جدول conntrack كبير.
على سيرفر بمعالجين: NUMA
إذا كان في السيرفر معالجان، فلكل منهما ذاكرته. وعندما تنتقل البيانات بينهما يزيد التأخير قليلاً. وتفعيل خيار NUMA يعرّف الضيف بهذه البنية، فيوزع عمله بطريقة أنسب، وخصوصاً مع VM كبيرة:
qm set <VMID> --numa 1ومع VM بأربع أنوية لن تكون هذه أولويتك، فابدأ بالإعدادات الثلاثة الأساسية، ثم عد إلى هذا إن كبرت الـVM.
النسخ الاحتياطي
نسخة الـVM تحتوي مفاتيح WireGuard الخاصة. فعاملها كأي سر، واجعلها مشفرة ومقيدة الوصول. وعند الاستعادة، تأكد أن النسخة القديمة لا تعمل بالتوازي مع الجديدة، حتى لا يتنازعا العنوان والمفتاح نفسيهما.
VM أم على العقدة مباشرة؟
تشغيله على العقدة مباشرة يوفر طبقة افتراضية، لكنه يخلط النفق بنظام إدارة السيرفر كله. وأي خطأ في الجدار أو التوجيه قد يقطع وصولك إلى Proxmox نفسه. أما الـVM فتعطيك عزلاً وسهولة في الاستعادة، وقد أظهر قياسنا أنها تحمل منفذ 480Mbps مع هامش واسع.
ولا تنسَ تحديث نظام الضيف والعقدة بانتظام. فالتعديلات على نواة لينكس تشمل تحسينات في الشبكة والتشفير، لكن جرّب التحديث في وقت هادئ، واحتفظ بطريقة للعودة، خصوصاً إن كان النفق يربط فروعاً تعمل طوال اليوم.
ترتيب العمل المقترح: غيّر إعداداً واحداً كل مرة، ثم قس لبضع دقائق، وسجّل النتيجة. بهذا تعرف ما أفاد فعلاً. وخذ نسخة من إعداد الـVM قبل التعديل، خصوصاً على سيرفر إنتاج.
الخلاصة
ثلاثة أشياء تكفي أغلب الحالات: cpu host لتصل تعليمات المعالج إلى الضيف، وعدد أنوية يثبت القياس حاجته، وqueues بعدد الأنوية مع عملاء كثيرين. وقبل ذلك كله، تذكر أن الموقع القريب لا ينفعك إن كان المعالج تحته ضعيفاً، فالعتاد هو الذي يحدد سقف ما يمكن ضبطه.
إن كنت تخطط لتشغيل نفقك على VM، فسيرفرات مرام هوست توفر لك موارد مناسبة، وفريقنا يساعدك في اختيار ما يكفي دون زيادة. وتتوفر لدينا خيارات منافذ بسرعات أعلى تصل إلى 100 جيجابت حسب التوفر والموقع، ونؤكد التفاصيل قبل الطلب.
