WireGuard يفشل بعد الخمول: اختبر الاتجاه أولًا
تعيين NAT منتهٍ وراديو نائم وتطبيق بائت تتشابه بعد فترة هدوء. اختبر الوارد والصادر كلاً على حدة قبل إضافة keepalive.
أربعة أسئلة تسبق أي تغيير في الإعدادات: هل يعمل المورد نفسه بينما العميل نشط، وكم دامت فترة الخمول، وهل نام الجهاز أو غيّر الشبكة، وهل يظهر العطل فقط في الحركة التي يبدأها الطرف الآخر. الإجابات تفصل تعيين NAT منتهيًا عن راديو نائم وعن تطبيق بائت. وهي تخبرك أيضًا هل كان keepalive ذا صلة أصلًا. ابدأ بالاتجاه، لأنه يكلف أمرًا واحدًا ويستبعد نصف الأسباب الممكنة.
أي اتجاه يفشل؟
الطلب الصادر الجديد من العميل والحركة التي تصل إليه بعد فترة هدوء تختبر المعدات ذات الحالة بطريقتين مختلفتين. الحزم الصادرة تعيد بناء التعيين وهي تغادر، أما الحزم الواردة فتحتاج أن يكون التعيين القديم قد نجا. هذا التفاوت هو الاختبار كله. إذا كان العميل يستطيع الوصول إلى الخارج ولا يصل شيء إلى الداخل، فالمرجح أن التعيين انتهى، وإن لم يعمل أي منهما فالنفق أو وصول العميل إلى الشبكة مفقود.
لاحظ كم دامت فترة الهدوء، وهل نام الجهاز أو انتقل إلى شبكة أخرى في أثناء ذلك. هاتان الحقيقتان تغيّران التشخيص قبل أي إعداد.
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer
شغّل تلك الأوامر الثلاثة قبل فترة الهدوء وبعدها، لأن كل واحد يجيب عن جزء مختلف من السؤال. طابع زمني للمصافحة لم يتحرك يقول إن الطرفين توقّفا عن التحدث، بينما نقطة نهاية تغيّرت تقول إن التعيين تحرّك بدل أن يموت. عدّادات النقل تُظهر هل وصل أي شيء أصلًا، وهو الفرق بين تعيين بائت وتطبيق صامت. اكتب الأرقام في الموضعين، لأن المقارنة هي الدليل.
النوم والراديو وحالة التطبيق
على هاتف أو حاسوب محمول، قد يكون الجهاز النائم فقد الوصول إلى الشبكة كليًا، ولا يستطيع keepalive إعادة راديو مغلق ولا إكمال بوابة أسيرة لم تُلبَّ بعد. المنصات المحمولة تعلّق العمل في الخلفية بحكم السياسة، لذا فإن استمرار الحركة الدورية يعتمد على المنصة وعلى ما تفاوض عليه التطبيق معها. الاتصال المخزَّن هو الحالة الثالثة وأكثرها تضليلًا، لأن عودة النفق ليست نفس إعادة اتصال التطبيق به.
أعد فتح التطبيق بعد فترة الخمول بدلًا من الوثوق بالتبويب الذي بقي مفتوحًا. إذا نجح طلب جديد حيث فشلت الجلسة القديمة، فالنفق لم يكن المشكلة أبدًا.
ما الذي يفعله keepalive فعليًا
PersistentKeepalive يرسل حزمة فارغة موثقة دوريًا إلى طرف آخر، وهو ما يكفي لإبقاء تعيين NAT حيًا بين الطرفين ولإبقاء نقطة نهاية الطرف الآخر محدّثة، كما يصف البدء السريع في WireGuard. وهو لا يصلح راديو نائمًا ولا مسارًا مفقودًا ولا تطبيقًا لا يعيد المحاولة أبدًا. اختر الفاصل عبر إعدادات العميل المدعومة، ولا تفعّل قيمة عدوانية في كل مكان لمجرد أن عرض الحالة يصمت.
معظم فترات الخمول ليست أعطالًا. النفق الذي يعيد الاتصال بعد خمس دقائق من الصمت يتصرف بشكل صحيح، والمشكلة هي فقط الحالة التي كان يُفترض أن يصل فيها شيء من الطرف الآخر.
انتظر الفاصل الذي كان يفشل
أجرِ تغييرًا واحدًا مدعومًا، ثم دع الفترة نفسها من الخمول تنقضي قبل إعادة اختبار ذلك المورد. الانتظار جزء من الاختبار لا شكليّة. النجاح الفوري بعد إعادة الاتصال لا يقول شيئًا عن عَرَض طويل الخمول، لأن إعادة الاتصال هي بالضبط الحدث الذي يعيد ضبط الحالة. إذا ظهرت المشكلة أيضًا أثناء الاستخدام النشط، فارجع إلى فحوص المصافحة ومسار البيانات بدلًا من إضافة مزيد من الحركة الدورية.
احتفظ بتغيير واحد لكل اختبار واكتب مدة الخمول المستخدمة. بدون ذلك ينحرف كل مقارنة لاحقة ولا يستطيع أحد معرفة أي تغيير كان مهمًا. سجّل الحقائق الأربع معًا: الاتجاه والمدة وحالة النوم وسلوك التطبيق.