لماذا يعتمد نفق WireGuard على نواة واحدة؟ ومتى تقسّم الأنفاق

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

هل يعني هذا أن WireGuard يعمل على نواة واحدة؟ ليس تماماً. والفهم الدقيق هنا يهم، لأنه يحدد متى ينفعك تقسيم الأنفاق ومتى يكون تعقيداً بلا فائدة.

ما الذي يتوزع على الأنوية، وما الذي لا يتوزع؟

WireGuard في نواة لينكس يوزع عمل التشفير وفك التشفير على عدة أنوية. فالفكرة الشائعة بأنه أحادي النواة بالكامل غير دقيقة.

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

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

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

لماذا يتجه النفق إلى طابور واحد؟

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

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

وهذا هو الفرق بين حالتين يخلط الناس بينهما:

كيف تعرف أن هذه مشكلتك؟

لا تقسّم قبل أن تتأكد. ففي قياس على أحد سيرفراتنا، بلغت قدرة التشفير الداخلية داخل VM بأربع أنوية نحو 1.7Gbps، بينما حد المنفذ 480Mbps. في حالة كهذه لا فائدة من التقسيم، لأن الاختناق ليس في المعالج أصلاً.

لكي تشخّص سيرفرك، حمّل النفق ثم راقب كل نواة:

apt install -y sysstat

# كل نواة على حدة، كل ثانيتين
mpstat -P ALL 2

# الطوابير المتاحة على البطاقة
ethtool -l eth0

ابحث عن نواة قريبة من 100% وفيها نسبة عالية من %soft، مع بقاء أنوية أخرى خاملة. هذا هو نمط اختناق التوزيع.

أما إذا كانت الأنوية بعيدة عن الامتلاء والسرعة محددة، فابحث في مكان آخر: حد السويتش، أو MTU، أو سرعة الطرف الآخر.

كيف تقسّم الأنفاق؟

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

نقسم هنا الشبكة 10.66.66.0/24 إلى نصفين:

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.66.66.1/25
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY_0>

[Peer]
PublicKey = <CLIENT_A_PUBLIC_KEY>
AllowedIPs = 10.66.66.2/32


# /etc/wireguard/wg1.conf
[Interface]
Address = 10.66.66.129/25
ListenPort = 51821
PrivateKey = <SERVER_PRIVATE_KEY_1>

[Peer]
PublicKey = <CLIENT_B_PUBLIC_KEY>
AllowedIPs = 10.66.66.130/32

systemctl enable --now wg-quick@wg0
systemctl enable --now wg-quick@wg1
wg show

ولا تنسَ فتح المنفذ الجديد في الجدار، ومراجعة قواعد NAT إن كانت لكل شبكة فرعية على حدة. وعلى VM، فعّل queues بعدد الأنوية، وإلا فلن تجد الحركة طوابير تتوزع عليها.

أسلوبان للتوزيع

التقسيم حسب المجموعات

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

نفقان بين طرفين

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

كيف تقيس فائدة التقسيم؟

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

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

# عدادات كل الأنفاق معاً
wg show all transfer

على طرف الفرع أيضاً

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

حدود لا يتجاوزها التقسيم

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

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

بدائل قبل التقسيم

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

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

الخلاصة

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

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