توقّف WireGuard: حدّ MTU أم قاعدة توجيه مفقودة؟
لا شيء يتجاوز الخادم يعني مشكلة في التمرير أو في مسار العودة. الطلبات الصغيرة التي تنجح بينما تتعطّل الكبيرة هي بصمة حجم الحزمة.
العادة هي خفض MTU بمجرّد أن يسيء WireGuard التصرّف، وهذه العادة تُخفي عيباً مختلفاً. البوّابة التي لا تُمرّر والمسار الذي لا يحمل الحزم الكبيرة يُنتجان نمطين يمكن تمييزهما: أحدهما يفشل في الاتجاهين وفي كل حجم، والآخر ينجح مع الطلبات الصغيرة ويموت مع الكبيرة. حدّد أيّ شكل لديك قبل تغيير أي رقم. الاختبار رخيص وهو يزيل نصف الأسباب المحتملة.
فشلان، شكلان مختلفان
تظهر مشكلة التمرير فوراً بعد الخادم. تنجح المصافحة، ويستجيب عنوان النفق، ولا شيء خلف البوّابة يمكن الوصول إليه حتى بطلب صغير. وصلت الحزمة إلى الخادم ولم تُمرَّر، أو لم يكن للردّ طريق عودة.
لا تظهر مشكلة الحجم إلا فوق حدّ معيّن. يعمل DNS ومصافحة TCP ونداء API صغير، بينما يتعلّق تنزيل ملف أو ردّ كبير. الحزم التي اتّسعت سافرت من طرف إلى طرف، والتي لم تتّسع أُسقطت في مكان ما دون تقرير مفيد.
تلك الأوصاف تشير إلى أشخاص مختلفين وملفات إعداد مختلفة، ولهذا فإن قياس الشكل أنفع من التخمين. لا يمكن لنقرة ping واحدة إلى البوّابة أن تفصل بينهما.
استبعد التمرير قبل أن تصغّر أي شيء
اختبر وجهة تتجاوز البوّابة، لا البوّابة نفسها. لا يُثبت الـ ping إلى عنوان نفق الخادم إلا أن الواجهة عاملة وأنك تصل إلى الجهاز الذي يُنهي النفق. يعتمد مرور حركة الشبكة الأوسع على تمكين تمرير IP على ذلك الجهاز وعلى جدار ناري يسمح بالتدفّق المُمرَّر. يجب أن يكون الاثنان صحيحين، وأيّهما كان خاطئاً يُنتج الصمت نفسه.
توجيه العودة لا يقلّ أهمية. إذا لم تعرف شبكة الوجهة كيف تصل إلى عنوان نفق العميل، يصل الطلب ويختفي الردّ، ويبلّغ العميل عن مهلة تبدو مطابقة لتمرير مُسقَط.
حيث يستخدم التصميم ترجمة العناوين، تكون قاعدة الترجمة جزءاً من مسار العودة ذلك. إزالتها أثناء مطاردة مشكلة MTU تحوّل تصميماً عاملاً إلى تصميم معطّل، فاقرأ القواعد القائمة قبل تعديلها.
قِس من أين يبدأ الانقطاع
اقرأ حالة التمرير وقواعد التصفية أولاً. هذه فحوص للقراءة فقط وهي تجيب عن السؤال الرخيص:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9ثم اختبر الأحجام ببت عدم التجزئة، من العميل، نحو مضيف يتجاوز البوّابة:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9إذا نجح الفحص الأول وفشل الثاني بخطأ تجزئة، فالمسار يخبرك بحجمه الصالح. وإذا لم ينجح أيّ منهما، فأنت تنظر إلى تمرير أو توجيه، وMTU ليس المتغيّر الذي يجب تغييره.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
أصلح الطبقة التي أثبتّها
عندما يكون التمرير هو العيب، فالتصحيح قاعدة تمرير أو مسار، يُعبَّر عنه بأضيق نطاق يسمح به التصميم. وعندما يكون الحجم هو العيب، فالتصحيح MTU يراعي التغليف على هذا المسار بعينه، ويُطبَّق على الواجهة التي تحتاجه لا على كل محوّل في الأسطول.
في كلتا الحالتين، أعد المهمة نفسها إلى الوجهة نفسها بعد ذلك. إذا اكتمل النقل الكبير الأصلي الآن، فقد عالج التغيير الطبقة التي كانت تفشل. وإذا تحسّن الفحص الصغير فقط، فقد عالجت عرَضاً والحدّ الحقيقي ما زال قائماً.
اكتب أيّ شكل لاحظته قبل التغيير. ذلك السطر الواحد، المسجَّل بجانب الإصلاح، هو ما يمنع الشخص التالي من خفض MTU لم يكن المشكلة قطّ.