سيرفر WireGuard بمنفذ 480Mbps يبدو مشروعاً بسيطاً: تنصّب الحزمة، وتنشئ مفتاحين، وينتهي الأمر. لكن النفق الذي يعمل ليس بالضرورة نفقاً يعطيك سرعة الرابط كاملة.
في هذا المقال نعرض ما فعلناه على أحد سيرفراتنا، خطوة بعد خطوة، مع الأرقام كما قيست. ونذكر أيضاً ما جرّبناه ولم ينفع، لأن التجربة الفاشلة تختصر عليك وقتاً كما تختصره الناجحة.
نقطة البداية: ماذا يوجد في الجهاز؟
قبل أي ضبط يجب أن تعرف ما تعمل عليه. فلا يمكن الحكم على نتيجة دون معرفة العتاد والحد المفروض على المنفذ.
| العنصر | القيمة |
|---|---|
| المعالج | Xeon E5-2698 v4، أي 20 نواة و40 خيطاً |
| الذاكرة | 64GB ECC |
| التخزين | مرآة ZFS على SSD |
| البيئة | Proxmox، وWireGuard داخل VM بأربع أنوية |
| الرابط | 1Gbps وعليه حد على السويتش عند 480Mbps |
الحد هو الرقم الذي يحكم كل ما بعده. فبما أن 480Mbps تساوي 60MB/s نظرياً، فهذا هو السقف الذي نقيس عليه. لا نتوقع أكثر منه، ولا نقبل بأقل منه بكثير دون تفسير.
الخطوة الأولى: عزل السؤال
حين تكون السرعة أقل من المتوقع، فالمتهمون كثيرون: المعالج، والرابط، والعميل، والطريق بينهما. وأسوأ ما تفعله أن تغيّر عدة إعدادات معاً ثم لا تعرف أيها أثّر.
لذلك قسمنا السؤال إلى ثلاثة أسئلة أصغر:
- هل يستطيع المعالج داخل الـVM تشفير ما يكفي من البيانات؟
- هل يوصل الرابط السرعة المتفق عليها دون نفق؟
- هل تصل السرعة نفسها عبر النفق؟
إجابة كل سؤال تحذف مشتبهاً به من القائمة. وهذا أسرع بكثير من تجربة الإعدادات عشوائياً.
النتيجة الأولى: المعالج ليس الاختناق
قسنا قدرة التشفير الداخلية داخل الـVM بأربع أنوية، فبلغت نحو 1.7Gbps. أي أكثر من ثلاثة أضعاف حد المنفذ.
معنى هذا واضح: لو ظهر بطء لاحقاً، فلن يكون سببه ضعف المعالج. وهذه المعلومة وحدها توفّر عليك شراء عتاد لا تحتاجه، أو إضافة أنوية لن تغيّر شيئاً.
والقياس الداخلي مهم لأنه يتم دون المرور بالرابط الخارجي. فهو يخبرك بما يقدر عليه الجهاز، لا بما يسمح به الطريق.
النتيجة الثانية: الرابط يوصل ما اتُّفق عليه
أجرينا تنزيلاً متواصلاً لمدة 3 دقائق، فكانت السرعة المقاسة 57MB/s. واخترنا تنزيلاً طويلاً لأن الاختبار القصير قد يخدعك: دفعة أولى سريعة ثم هبوط لا تراه.
الرقم 57MB/s يقارب 456Mbps، وهو قريب من السقف النظري. أما الفرق القليل عن 60MB/s فمتوقع، لأن الترويسات وطبقات البروتوكولات تأخذ جزءاً من الرابط، والسرعة التي تراها هي البيانات الفعلية فقط.
ثم كررنا التنزيل عبر النفق، فجاءت النتيجة 57MB/s أيضاً، مع زمن وصول يقارب 6ms عبر النفق محلياً. أي أن النفق لم يخفض سرعة التنزيل في هذا القياس.
| القياس | النتيجة | ما نستنتجه |
|---|---|---|
| قدرة التشفير الداخلية | ~1.7Gbps | المعالج أوسع من حد المنفذ |
| تنزيل متواصل 3 دقائق | 57MB/s | الرابط يقارب سقفه النظري |
| تنزيل عبر النفق | 57MB/s | النفق يحمل الرابط كله تقريباً |
| زمن الوصول عبر النفق محلياً | ~6ms | زمن منخفض يناسب العمل التفاعلي |
أين دخل BBR، وأين لم يدخل؟
هنا يقع الخلط الشائع. على منفذ بحد policer، قسنا الرفع عبر Ookla باستخدام TCP. قبل BBR كان الرفع بين 154 و177Mbps، وبعده أصبح بين 365 و444Mbps.
تحسّن كبير، لكن انتبه لشرطه: هو قياس TCP. أما WireGuard فيعمل على UDP، فلا يسرّعه BBR مباشرة. وقد يبدو أن النتيجتين متناقضتان، لكنهما تجيبان عن سؤالين مختلفين:
- BBR يفيد خدمات TCP التي تبدأ أو تنتهي على السيرفر نفسه.
- WireGuard يغلّف الحزم في UDP، ولا يتحكم بازدحام هذه الطبقة أصلاً.
لذلك فعّلناه لفائدته في TCP، ولم نعدّه سبباً في نتيجة النفق.
# /etc/sysctl.d/90-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# تطبيق الإعداد ثم التحقق
sysctl --system
sysctl net.ipv4.tcp_congestion_controlما جرّبناه ولم نعتمده: shaper بـcake
الفكرة منطقية على الورق. فالـpolicer يرمي الحزم الزائدة عن الحد، أما الـshaper فيؤخرها في طابور. فلماذا لا نضبط السرعة قليلاً تحت الحد حتى لا يرمي السويتش شيئاً؟
جرّبنا ذلك بـcake عند 465Mbps، على 3 جولات متناوبة بين التفعيل والتعطيل. لم نرَ فرقاً واضحاً، فلم نعتمده.
هذه نتيجة مفيدة وليست خسارة. فكل إعداد تضيفه يصبح شيئاً تصونه لاحقاً وتشك فيه عند أي عطل. وإذا لم يعطِ فرقاً قابلاً للقياس، فمكانه خارج الإعدادات. والجولات المتناوبة مهمة هنا، لأن الشبكة تتغير خلال اليوم، وجولة واحدة قد تكافئ إعداداً لا يستحق.
اختبار العميل: MikroTik على RouterOS 7.25
السيرفر لا يكفي وحده، فالنفق طرفان. ربطنا عميلاً على RouterOS 7.25، فنجحت المصافحة، وكان فقد ping صفراً بالمئة، وخرجت الحركة من عنوان السيرفر كما هو مطلوب.
لم نقس سرعة MikroTik في هذه الجولة، فلن نعطيك رقماً له. فسرعة العميل تعتمد على طرازه ومعالجه، ولا يصح نقل رقم السيرفر إليه.
وإذا أردت تكرار هذه الجولة على سيرفرك، فاتبع الترتيب نفسه: اعرف حد المنفذ من مزوّدك، ثم قس المعالج، ثم الرابط، ثم النفق. وسجّل كل نتيجة مع تاريخها ووقتها، حتى تقارن لاحقاً بأرقام لا بذكريات.
ولا تكتفِ بقياس واحد في ساعة هادئة. فالسؤال ليس أعلى رقم رأيته، بل الرقم الذي يبقى ثابتاً حين يعمل الناس فعلاً.
ماذا نتعلم من هذه الجولة؟
- قس قبل أن تضبط. معرفة أن المعالج يقدر على 1.7Gbps أغنتنا عن ملاحقة مشكلة غير موجودة.
- افصل المعالج عن الرابط. لكل منهما حد مستقل، ويجب اختبار كل حد وحده.
- لا تنسب النتيجة لغير سببها. تحسّن TCP مع BBR حقيقي، لكنه لا يعني أن WireGuard صار أسرع بسببه.
- احذف ما لا يُقاس أثره. الـcake لم يعطِ فرقاً، فخرج.
وقرب السيرفر من المستخدم مفيد، لكنه لا يكفي وحده. فمعالج ضعيف قريب منك قد يخنق النفق قبل أن يصل إلى حد المنفذ، والعتاد هنا يقرر ما يقدر الطريق على حمله.
عن هذه الأرقام: هي قياس على أحد سيرفراتنا، ضمن إعداد معين وفي ظروف شبكة معينة. نتيجتك ستختلف بحسب معالجك ومنفذك وعميلك وطريق الاتصال. لذلك خذ منها طريقة القياس قبل الأرقام نفسها.
الخلاصة
النفق السريع لا يأتي من إعداد سحري. يأتي من معرفة الحد الحقيقي، ثم فحص كل طبقة وحدها، ثم الاحتفاظ بما يثبت القياس فائدته فقط. وعلى هذا السيرفر، وصل النفق إلى 57MB/s قريباً من سقف الرابط النظري.
إن كنت تبني سيرفر VPN لربط فروع شركتك أو لتأمين العمل عن بعد، فتواصل مع فريق مرام هوست لنختار معاً المعالج والمنفذ المناسبين لحجم ترافيكك. وتتوفر لدينا خيارات منافذ بسرعات أعلى تصل إلى 100 جيجابت حسب التوفر والموقع، ونؤكد التفاصيل قبل الطلب.
