همتای 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 ظاهر می‌شود، شمارنده دست‌دادن پس از ترافیک افزایش می‌یابد و برنامه‌ای که به تونل وابسته است واقعاً پاسخ می‌دهد. همتایی که با دست‌دادن قدیمی فهرست می‌شود مشکل مسیریابی یا کلید است، نه مشکل پایداری، و همین تمایز یک ویرایش بی‌فایده پیکربندی را ذخیره می‌کند.

در پایان بررسی کنید راه‌اندازی دوباره چه چیزی را بازگردانده است. راه‌اندازی دوباره‌ای که همتایی را زنده می‌کند که عمداً حذفش کرده بودید، همان باگ با علامت مخالف است و معمولاً یعنی نسخه قدیمی پیکربندی هنوز از جایی بارگذاری می‌شود. مالک، مسیر فایل، کلید عمومی همتا و فرمان‌های بررسی را کنار پیکربندی ثبت کنید تا نفر بعدی این را با راه‌اندازی دوباره یک میزبان عملیاتی دوباره کشف نکند.