نظير WireGuard يختفي بعد إعادة التشغيل: ابحث عن الإعداد الحقيقي

النظير الذي أضفته باستخدام wg set يستجيب لأوامر ping طوال فترة بعد الظهر ثم يختفي بعد إعادة التشغيل. لم يتلف شيء: لم تخزّن النواة ذلك النظير في أي مكان إلا في الواجهة الحيّة، وكل ما يعيد إنشاء الواجهة عند الإقلاع بناه من ملف لم تلمسه. الإصلاح ليس wg set آخر. الإصلاح هو معرفة أي مكوّن يملك الواجهة، وتعديل حالة ذلك المكوّن، ثم إثبات أن النظير ينجو من حدث دورة الحياة نفسه الذي أزاله.

أعِد إنتاج المشكلة مرة واحدة عن قصد

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

اكتب ثلاث حقائق أثناء ذلك: اسم الواجهة، والوحدة أو ملف التعريف الذي بدأها، وما إذا كان عدّاد المصافحة عند النظير الباقي قد صُفّر. عدّاد مُصفّر يعني أن الواجهة دُمّرت وأُعيد إنشاؤها؛ وعدّاد لم يتغيّر مع نظير مفقود يعني أن شيئًا عدّل الإعداد تحتك.

من يملك الواجهة؟

WireGuard نفسه لا يملك خادمًا خلفيًا ولا ملف إعداد. شيء فوقه يستدعي wg عند الإقلاع، وهذا الشيء هو مصدر الحقيقة. المرشّحون المعتادون هم [email protected]، أو ملف تعريف اتصال NetworkManager، أو وحدة شبكة خاصة بالتوزيعة، أو لوحة إدارة تكتب قاعدة بياناتها الخاصة.

اسأل النظام لا وثائق توزيعتك. systemctl status wg-quick@wg0 و nmcli connection show سيحسمان الأمر عادة بأمر واحد لكل منهما. إذا ادّعى كلاهما الواجهة، فقد وجدت الخلل قبل تعديل أي شيء: مالكان يعيدان كتابة الجهاز نفسه في كل بدء، والفائز هو آخر من ينفَّذ.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

حالة التشغيل وحالة الإقلاع ليستا الملف نفسه

wg set يتلاعب بالجهاز الحيّ عبر netlink. وهو لا يكتب /etc/wireguard/wg0.conf ولا ملف تعريف NetworkManager ولا قاعدة بيانات لوحة. نجاح wg show بعد ذلك يثبت أن النواة قبلت النظير، لا أن شيئًا سيعيده.

ثمة فخّ ثانٍ في الاتجاه المعاكس. خيار SaveConfig في wg-quick يكتب حالة الواجهة الحالية مرة أخرى إلى ملف الإعداد عند إنزال الواجهة. وعند تفعيله، يمكن أن يطمس الإغلاقُ التالي تعديلًا أُجري على الملف أثناء عمل الواجهة، وستقسم إن السطر كان موجودًا. إذا ظل النظير يعود إلى حالته السابقة، فاقرأ الملف بعد الإيقاف لا قبله.

NetworkManager يتصرّف بشكل مختلف مرة أخرى: فهو يملك ملف التعريف ويطبّقه عند التنشيط، لذا فإن ملف .conf محرَّر يدويًا بجوار اتصال NetworkManager نشط هو زينة فقط. اختر مالكًا واحدًا للواجهة ودع المدير الآخر يتركها.

اجعل التعديل يصل إلى المكانين

عدّل الحالة الدائمة أولًا، ثم دع المالك يطبّقها، ثم تحقّق من الحالة الحيّة. هذا الترتيب يعني أن أي فشل في أي خطوة يشير إلى شيء واحد بدلًا من ثلاثة.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf يطبع الإعداد الحيّ بالصيغة نفسها التي يستخدمها الملف، وهذا يجعل المقارنة بينهما مباشرة. تعامل مع ذلك الناتج كسرّ: فهو يحتوي مفاتيح خاصة، لذا لا تلصقه في تذكرة أو قناة محادثة. قارن المفاتيح العامة للنظير وعناوين IP المسموح بها، وتأكد من أن النظير الذي أزلته عن قصد لم يعد.

أثبت أنه ينجو من حدث دورة الحياة

أعد التشغيل عبر المالك مرة ثانية، ثم أكّد ثلاثة أمور منفصلة: ظهور النظير في wg show، وارتفاع عدّاد المصافحة بعد مرور حركة، واستجابة التطبيق الذي يعتمد على النفق فعليًا. النظير المدرج بمصافحة قديمة يعاني مشكلة توجيه أو مفتاح، لا مشكلة استمرارية، وهذا التمييز يوفّر تعديل إعداد بلا جدوى.

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