بطء WireGuard: اكتشف السبب الحقيقي

من أين تأتي سرعات WireGuard البطيئة فعلياً

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

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

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

لماذا تبلغ قيمة WireGuard MTU ‏1420؟

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

يتكون رأس بيانات WireGuard من 32 بايتاً: حقل نوع من 4 بايتات، وفهرس مستلم من 4 بايتات، وعداد من 8 بايتات، ووسم مصادقة Poly1305 من 16 بايتاً. ويحيط بذلك رأس UDP بحجم 8 بايتات. ويحيط بهما رأس IP الخارجي، وحجمه 20 بايتاً في IPv4 و40 بايتاً في IPv6. لذلك يبلغ إجمالي التغليف 60 بايتاً عندما يكون Endpoint عنوان IPv4، و80 بايتاً عندما يكون عنوان IPv6. توثّق صفحة بروتوكول WireGuard بنية الرسائل التي تستند إليها هذه الأرقام.

لا يخمّن wg-quick هذه القيمة. بل يقرأ MTU للواجهة التي توجّه الحزم إلى Endpoint، ثم يطرح 80. في مسار Ethernet عادي بحجم 1500 بايت، ينتج عن ذلك 1420، وهي القيمة التي يطبعها ip link show wg0. ويطرح 80 بدلاً من 60 حتى تبقى القيمة نفسها آمنة إذا جرى الوصول إلى نقطة النهاية عبر IPv6، حيث يكون الرأس الخارجي أكبر بمقدار 20 بايتاً.

[
  {
    "label": "Ethernet, IPv4 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1440
  },
  {
    "label": "Ethernet, IPv6 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1420
  },
  {
    "label": "PPPoE DSL, IPv4 endpoint",
    "path_mtu": 1492,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1432
  },
  {
    "label": "Extra tunnel in the path",
    "path_mtu": 1400,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1320
  }
]

هذه الصفوف 4 ناتجة عن حسابات، وليست قياسات. في مسار نظيف بحجم 1500 بايت ومع نقطة نهاية IPv4، كانت القيمة 1440 ستلائم المسار، ولذلك يترك الإعداد الافتراضي 1420 مقدار 20 بايتاً غير مستخدم. هذا الهامش مقصود، وليس هو سبب المشكلة لديك.

الصف الأخير هو المهم. عندما لا يحمل أحد الوصلات في المسار سوى 1400 بايتاً، فإن نفقاً مضبوطاً على 1420 ينتج حزمة خارجية بحجم 1500 بايت مع كل مقطع بالحجم الكامل، أي أكبر بمقدار 100 بايت من الحجم الذي تقبله تلك الوصلة. والقيمة الملائمة هي 1320.

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

كيف يبدو MTU غير الصحيح

الفشل ليس تدريجياً. بل يظهر كفصل واضح بين الحزم الصغيرة والكبيرة.

• يعمل ping عبر النفق بأي حجم معتاد.
• يكتمل تسجيل الدخول عبر SSH وتبدو الكتابة سريعة الاستجابة.
• يعيد curl -I https://example.com الرؤوس فوراً.
• يتوقف curl https://example.com عند تحميل صفحة كبيرة بعد أول بضعة كيلوبايتات.
• يبدأ scp لملف كبير، ثم يتوقف عند نسبة مئوية معينة.
• تتجمد جلسة SSH لحظة تشغيل أمر يطبع كمية كبيرة من المخرجات.

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

تواجه الحزمة الخارجية التي يتجاوز حجمها MTU للرابط التالي مصيراً من اثنين.

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

تُسقط، وقد يتم إعلامك بذلك أو لا. يرسل الموجّه الذي لا يستطيع التجزئة رسالة ICMP (بروتوكول رسائل التحكم في الإنترنت) بعنوان "fragmentation needed" إلى المرسل، وتتضمن MTU الذي يمكنه قبوله. إذا وصلت الرسالة، تعمل آلية اكتشاف MTU للمسار، ويخفض المرسل حجم المقطع تلقائياً. تحظر شبكات كثيرة ICMP، ولذلك لا تصل الرسالة غالباً. ولا توجد آلية أخرى تُبلغ عن الفقد. هذه هي الفجوة السوداء: تغادر الحزمة، ولا يعود شيء، ولا يظهر أي خطأ في سجلات أي من الطرفين، ويبقى النقل متوقفاً إلى أن تنتهي مهلة ما.

كيف أعثر على قيمة MTU الصحيحة؟

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

ping -M do -s 1472 -c 3 203.0.113.10

يعيّن -M do بت DF ‏(عدم التجزئة)، لذلك لا يُسمح لأي موجّه في المسار بتقسيم الحزمة. تحدد -s حجم حمولة ICMP. تتكوّن حزمة IPv4 الكاملة من هذه الحمولة، إضافة إلى 8 بايت لرأس ICMP و20 بايت لرأس IP. لذلك تضع -s 1472 حزمة بحجم 1500 بايت بالضبط على الشبكة.

هناك 3 نتائج مهمة. تعني الاستجابات السليمة أن حجم 1500 بايت مناسب، وأن MTU ليس سبب المشكلة. ويعني الخطأ المحلي أن واجهتك نفسها أصغر من الحجم الذي طلبته:

ping: local error: message too long, mtu=1500

تعطيك استجابة من موجّه في منتصف المسار الإجابة مباشرة، ويمكنك التوقف عند ذلك:

From 203.0.113.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

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

ping -M do -s 1472 -c 3 203.0.113.10   # 100% loss, so 1500 is too big
ping -M do -s 1272 -c 3 203.0.113.10   # replies, so 1300 fits
ping -M do -s 1372 -c 3 203.0.113.10   # replies, so 1400 fits
ping -M do -s 1422 -c 3 203.0.113.10   # 100% loss, so 1450 is too big
ping -M do -s 1397 -c 3 203.0.113.10   # 100% loss, so 1425 is too big
ping -M do -s 1384 -c 3 203.0.113.10   # 100% loss, so 1412 is too big

تُجري tracepath عملية البحث نفسها تلقائياً، ويستحق تشغيلها مرة واحدة قبل بدء التنصيف:

tracepath -n 203.0.113.10

يعرض سطرها الأخير النتيجة التي عثرت عليها:

     Resume: pmtu 1492 hops 12 back 12

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

طبّق القيمة مباشرة أولاً، لأن التراجع عن التخمين الخاطئ يصبح عندئذ أمراً واحداً:

sudo ip link set mtu 1320 dev wg0

أعد محاولة عملية النقل التي كانت تتوقف. إذا اكتملت، اجعل القيمة دائمة في كتلة [Interface] على العميل:

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
MTU = 1320

sudo wg-quick down wg0 && sudo wg-quick up wg0
ip link show wg0

يجب أن تطبع ip link show wg0 الآن القيمة mtu 1320. إذا طبعت القيمة القديمة، فهذا يعني أن wg-quick لم يقرأ الملف الذي عدّلته. تحقق من أنك عدّلت /etc/wireguard/wg0.conf، وأن MTU موجود ضمن [Interface] وليس ضمن [Peer]، حيث يجري تجاهله.

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

لماذا يعالج ضبط MSS مشكلة TCP فقط دون غيره

إذا كان الخادم يمرّر حركة الشبكة الخاصة بالأقران، وهو ما يحدث في أي إعداد WireGuard قياسي على VPS يستخدم NAT (ترجمة عناوين الشبكة)، فإن قاعدة واحدة تعالج TCP لكل نظير، وتغنيك عن البحث عن قيمة مناسبة في كل عميل لا تتحكم فيه.

إن MSS (الحد الأقصى لحجم المقطع) هو خيار TCP يضعه كل طرف في حزمة SYN لتحديد حجم المقطع الذي يستطيع استقباله. يعيد الضبط كتابة هذا الخيار أثناء مرور الحزمة ليتوافق مع MTU الفعلي للمسار، بحيث يتفق الطرفان على مقطع أصغر قبل انتقال أي بيانات. ينجح ذلك لأنه يحدث أثناء المصافحة، ولأنه لا يعتمد على رسالة ICMP التي يُرجّح أن المسار يحظرها.

باستخدام nftables، أضف هذا الجدول إلى /etc/nftables.conf أسفل الجداول الموجودة لديك:

table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    tcp flags syn tcp option maxseg size set rt mtu
  }
}

أعد التحميل باستخدام sudo systemctl reload nftables. في خادم يستخدم iptables، يكون المكافئ سطراً واحداً:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

تأكد من أن القاعدة تقع على المسار الذي تسلكه الحزم. شغّل sudo nft list table inet mangle أو sudo iptables -t mangle -L FORWARD -n -v أثناء فتح العميل لاتصالات جديدة، وراقب ارتفاع العداد. إذا بقي العداد عند الصفر، فهذا يعني أن الحزم لا تمر عبر نقطة الربط تلك، ولذلك لا تنفّذ القاعدة أي شيء.

والآن الحدود الفعلية. يعالج الضبط TCP فقط ولا يعالج غيره، كما أنه يؤثر في حركة الشبكة المُمرَّرة فقط. لذلك لا تعبر الخدمة التي تعمل على خادم WireGuard نفسه نقطة forward، ولا تخضع للضبط. ويؤثر الضبط أيضاً في الاتصالات التي تُفتح بعد تحميل القاعدة؛ أما الجلسات الموجودة، فتحتفظ بقيمة MSS التي اتفق عليها الطرفان مسبقاً.

لا يتأثر UDP، لأنه لا يستخدم مصافحة يمكن إعادة كتابة خيارها. ومع ذلك، تبقى معظم حركة UDP صالحة للعمل. إذ يختبر QUIC، وهو بروتوكول النقل الذي يعمل تحت HTTP/3، حجم الحزمة القابل للاستخدام بنفسه، ويبدأ بحجم صغير عمداً. الذي لا يبقى صالحاً للعمل هو UDP الذي يرسل مخطط بيانات واحداً كبيراً ويتوقع مروره، مثل استجابة DNSSEC (امتدادات أمان DNS) التي يتجاوز حجمها 1400 بايت. تنتهي مهلة هذه الاستعلامات، ثم تعيد المحاولة باستخدام TCP، فيظهر ذلك للمستخدم على شكل موقع بطيء لا موقع متعطل.

هل يمثل معالج VPS الخاص بي الحد الأقصى للأداء؟

يستخدم WireGuard تشفير ChaCha20-Poly1305، ويتبادل المفاتيح باستخدام Curve25519. لا يوجد AES في مسار البيانات، ولهذا نتيجة يخطئ فيها البعض: تعليمات AES-NI في معالجك لا تفيد WireGuard. إعلان المضيف عن دعم AES-NI لا يعني أنه يوفّر ميزة أداء لـWireGuard. اختير ChaCha20 لأنه سريع عند تشغيله برمجياً، بما في ذلك على المعالجات التي لا تتضمن أي تسريع تشفيري.

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

قِس الأداء أثناء تشغيل عملية نقل:

sudo apt install -y sysstat
mpstat -P ALL 1

اقرأ الأعمدة الثلاثة. %soft هو وقت softirq، حيث تجري معالجة حزم النواة. %steal هو الوقت الذي سلّمه hypervisor إلى جهة أخرى. %idle هو الوقت المتبقي.

يشير اقتراب %soft من 100 على نواتك الوحيدة إلى أن الخادم بلغ الحد الأقصى لمعالجة الحزم. هذا حد فعلي يمكن لزيادة عدد الأنوية رفعه. يعرض top قيمة ksoftirqd/0 في أعلى قائمة العمليات في اللحظة نفسها، وهو الاستنتاج نفسه من زاوية أخرى.

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

هناك عامل آخر، وهو التنفيذ الذي يشغّله العميل. وحدة Linux kernel هي مسار الأداء السريع، وتوزّع تشفير أحد الأقران على عدة أنوية. wireguard-go، وهو تنفيذ userspace، أبطأ. ويستخدمه عملاء macOS وiOS لأن هذين النظامين لا يسمحان للتطبيق بتحميل وحدة kernel.

هل المشكلة في المسار أم في وصلة الطرف الآخر نفسه؟

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

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

# on the client, outside the tunnel
iperf3 -c 203.0.113.10
# then through the tunnel
iperf3 -c 10.8.0.1

إذا كان الرقمان متقاربين، فإن WireGuard يضيف تكلفة ضئيلة جداً، ويكون المسار هو العامل المحدِّد. إذا كان رقم النفق أقل بكثير من الرقم المباشر، بينما ظل %soft منخفضاً، فارجع إلى MTU. يقلل التجزؤ معدل النقل من دون أن يعطّل الاتصال، لذلك يظهر هنا على شكل نسبة فقدان بدلاً من توقف.

اختبر الاتجاهين، لأن اتصالات المنازل تكون عادة غير متماثلة. يعكس iperf3 -c 10.8.0.1 -R اتجاه التدفق، ولذلك يرسل الخادم البيانات. إذا كان اتصال العميل بسرعة 500/20، فلن يرسل عبر النفق أكثر من 20 Mbit، ولن يغير أي تعديل على الخادم ذلك.

ثم اختبر باستخدام تدفقات متوازية:

iperf3 -c 10.8.0.1 -P 4

إذا نقلت أربعة تدفقات معاً بيانات أكثر بكثير من تدفق واحد، فإن اتصال TCP واحداً لا يملأ سعة المسار. يحد حجم نافذة الاستقبال مقسوماً على زمن الذهاب والإياب من معدل نقل التدفق الواحد، ولذلك يحتاج مسار بزمن 150 ms إلى نافذة كبيرة لنقل كمية كبيرة من البيانات. اقرأ الحدود الخاصة بنظامك:

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

القيمة الثالثة في كل سطر هي الحد الأقصى الذي يمكن لـLinux ضبطه تلقائياً. ويحد فقدان الحزم تدفقاً واحداً بشدة أيضاً، لأن التحكم في ازدحام TCP يستجيب لفقدان الحزم، كما أن الاسترداد يصبح مكلفاً على المسارات الطويلة. شغّل mtr -rwc 100 203.0.113.10 من العميل لمدة مئة دورة لمعرفة موضع ظهور الفقدان على طول المسار. الفقدان الذي يبدأ عند قفزة واحدة ويستمر حتى القفزة النهائية حقيقي. أما الفقدان عند قفزة وسطية واحدة ثم اختفاؤه بعدها، فيعني أن ذلك الموجّه يخفض أولوية ICMP، ولا يدل على مشكلة.

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

ما الذي لا يستطيع WireGuard إصلاحه

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

لا يضغط البيانات. لا يوجد ما يعادل comp-lzo في OpenVPN، ولا توجد خطة لإضافة ذلك، لأن ضغط البيانات قبل تشفيرها يسرّب معلومات عن النص الصريح. معظم البيانات الكبيرة مضغوطة مسبقاً، لذلك لا يسبب غياب الضغط تكلفة عملية تُذكر. وهذا أحد الفروق الفعلية التي يجب مراعاتها عند مقارنة WireGuard مع OpenVPN، وهو خيار تصميم مقصود.

يغيّر النفق الكامل المسار الذي تسلكه كل حزمة. فحركة الشبكة التي كانت تنتقل منك إلى CDN قريب (شبكة توصيل المحتوى) تنتقل الآن منك إلى VPS ثم إلى CDN. إذا كان VPS في قارة أخرى، فكل طلب يسلك هذا المسار الالتفافي، ويزداد زمن الرحلة ذهاباً وإياباً تبعاً لذلك. لا توجد قيمة إعداد تقلل هذا الزمن. انقل VPS إلى موقع أقرب، أو استخدم نفقاً مقسّماً بحيث تسلك حركة الشبكة التي تحتاج إلى VPN فقط المسار الأطول. يحدّد AllowedIPs بالكامل أي حركة شبكة تسلك أي مسار، وتشرح آلية توجيه cryptokey كيفية اتخاذ هذا القرار.

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

لا يؤثر PersistentKeepalive في معدل النقل. فهو موجود لإبقاء تعيين NAT مفتوحاً حتى يتمكن الخادم من الوصول إلى عميل خلف موجّه منزلي. يؤدي خفضه إلى أقل من 25 ثانية إلى إضافة حزم، ولا يصلح أي شيء.

نفّذ القياسات بهذا الترتيب

1. أعد إنتاج المشكلة وحدد ما إذا كانت توقفاً كاملاً أم تباطؤاً منتظماً. يشير التوقف الكامل إلى مشكلة في MTU، أما التباطؤ المنتظم فلا يشير إليها.
2. نفّذ اختباراً ثنائياً باستخدام ping -M do من العميل إلى العنوان العام للخادم، وسجّل قيمة MTU للمسار.
3. اطرح 80، واضبط قيمة MTU الناتجة على wg0 في الطرفين، ثم أعد اختبار النقل الذي كان يفشل.
4. أضف ضبط MSS على الخادم إذا كان يمرّر حركة الشبكة الخاصة بالأقران.
5. شغّل mpstat -P ALL 1 أثناء النقل، واقرأ %soft و%steal.
6. شغّل iperf3 خارج النفق وداخله، في الاتجاهين، باستخدام تدفق واحد وباستخدام -P 4.
7. شغّل mtr -rwc 100 إلى الخادم، وابحث عن فقدان يستمر حتى القفزة الأخيرة.

غيّر خطة الخادم فقط بعد أن تشير الخطوة 5 إلى أن وحدة المعالجة المركزية هي الحد الأقصى. لا تكلّف الخطوات من 1 إلى 4 شيئاً، وتحل معظم البلاغات المتعلقة ببطء النفق.

FAQ

لماذا تكون سرعة نفق WireGuard عالية عند اختبار ping وبطيئة عند التنزيل؟

هذا الفرق هو علامة على وجود مشكلة في MTU. تتسع الحزم الصغيرة لكل وصلة في المسار، لذلك يعمل ping وتسجيل الدخول عبر SSH. يرسل النقل الكبير مقاطع بالحجم الكامل. وتكون النسخة المغلّفة منها أكبر من الحجم الذي تقبله إحدى الوصلات. إذا أسقط ذلك الموجّه الحزم من دون وصول رسالة ICMP إلى المصدر، فلن يُبلّغ أي مكوّن عن الفقد، ويتوقف النقل. اعثر على MTU للمسار باستخدام تقسيم ثنائي عبر ping -M do إلى العنوان العام للخادم. اطرح 80 بايتاً لحساب التغليف، واضبط الناتج كقيمة MTU لـwg0 عند الطرفين.

ما قيمة MTU التي ينبغي ضبطها لـWireGuard؟

لا توجد قيمة عامة مناسبة للجميع. ولهذا تحديداً تفشل القيمة الافتراضية 1420 لدى بعض المستخدمين. القيمة 1420 هي 1500 مطروحاً منها 80 بايتاً لرأس WireGuard ورأس UDP ورأس IPv6 الخارجي. إذا كان المسار ينقل أقل من 1500 بايت، وهذا شائع في DSL عبر PPPoE وأينما يعبر traffic نفقاً آخر، فستحتاج إلى قيمة أصغر. قِس MTU للمسار أولاً، ثم اطرح منه 80.

هل يحل ضبط MSS محل ضبط MTU؟

لا. يعيد ضبط MSS كتابة خيار MSS في مصافحة TCP، بحيث يرسل الطرفان مقاطع أصغر. وهذا يصلح TCP من دون تعديل الواجهة. لا يملك UDP مصافحة يمكن إعادة كتابتها، لذلك لا يتأثر. كما ينطبق ضبط MSS على traffic الذي يعيد الخادم توجيهه فقط. لذلك لا تستفيد منه خدمة تعمل على خادم WireGuard نفسه. استخدم كليهما: اضبط MTU صحيحاً على الواجهة، واستخدم ضبط MSS للتعامل مع الأقران الذين لا تتحكم في إعداداتهم.

هل تجعل خطة VPS الأسرع WireGuard أسرع؟

فقط إذا كانت وحدة المعالجة المركزية هي العامل المحدِّد، ويمكن لأمر واحد أن يوضح ذلك. شغّل mpstat -P ALL 1 أثناء إجراء النقل. إذا اقتربت %soft من 100 على نواتك الوحيدة، فهذا يعني أن معالجة الحزم هي الحد الأقصى، وأن زيادة عدد الأنوية سترفع الأداء. تشير قيمة %steal المرتفعة إلى أن المضيف يشغّل أحمالاً زائدة، ولذلك تكون الإجابة استخدام خطة أخرى أو مضيف آخر. إذا كانت القيمتان منخفضتين بينما يظل النفق بطيئاً، فهذا يعني أن وحدة المعالجة المركزية غير مستغلة، ولن تغيّر الخطة الأكبر شيئاً.

لماذا يكون جهاز Mac لدي أبطأ من عميل Linux على الشبكة نفسها؟

يستخدم عميل Linux وحدة WireGuard المضمّنة في النواة. تعالج هذه الوحدة الحزم في مساحة النواة، وتوزّع تشفير أحد الأقران على أنوية وحدة المعالجة المركزية. تستخدم تطبيقات macOS وiOS wireguard-go، وهو تطبيق يعمل في مساحة المستخدم، لأن هذه الأنظمة لا تسمح للتطبيق بتحميل وحدة نواة. تنسخ مساحة المستخدم كل حزمة بين النواة والتطبيق، ويؤدي هذا النسخ إلى خفض معدل النقل. هذا الفرق متوقع، ولا توجد إعدادات لدى العميل تلغيه.