چرا wg-quick هنگام توقف رابط، wg0.conf را بازنویسی می‌کند
SaveConfig یک ذخیره‌سازی هنگام خاموش‌شدن است، نه همگام‌سازی پس‌زمینه. فایل را وقتی تونل فعال است ویرایش کنید، و راه‌اندازی مجدد می‌تواند وضعیت قدیمی را روی آن بنویسد.
یک همتا به /etc/wireguard/wg0.conf اضافه می‌کنید، systemctl restart wg-quick@wg0 را اجرا می‌کنید، و وقتی دوباره نگاه می‌کنید همتا از فایل رفته است. هیچ چیز چیزی را خراب نکرده است. راه‌اندازی مجدد یک توقف است که پس از آن یک شروع می‌آید، و مرحله توقف می‌تواند وضعیت زمان اجرای کنونی را روی فایلی که تازه ویرایش کردید بنویسد. تنظیم مسئول در همان فایلی زندگی می‌کند که ویرایش می‌کردید، و همین است که حلقه را اولین بار که به آن برمی‌خورید این‌قدر گیج‌کننده می‌کند.
دو وضعیت، یک فایل، و یک ذخیره‌سازی هنگام خاموش‌شدن
وضعیت زمان اجرای WireGuard و فایل پیکربندی wg-quick مرتبط اما متفاوت‌اند. فایل ورودی است: wg-quick آن را می‌خواند، رابط را می‌سازد، نشانی‌ها و مسیرها را تنظیم می‌کند و همتاها را پیکربندی می‌کند. دستگاه هسته شیء زنده است، و تغییرات سطح پایینی که با wg انجام می‌شود هرگز خود را بازنویسی نمی‌کند.
به‌جز در یک جهت. وقتی SaveConfig = true در بخش رابط ظاهر می‌شود، wg-quick پیکربندی زنده را به‌عنوان بخشی از پایین آوردن رابط در فایل ذخیره می‌کند. راهنمای wg-quick دقیقاً از همین هشدار می‌دهد: تغییراتی که در حین فعال بودن رابط در فایل داده می‌شود ممکن است هنگام حذف آن بازنویسی شوند. این ذخیره‌سازی هنگام خاموش‌شدن است، نه یک تایمر پس‌زمینه، پس فقط وقتی چیزی رابط را متوقف کند فعال می‌شود.
| Action | What it writes | When it surprises you |
|---|---|---|
wg set on a live interface | Kernel state only | After reboot, when the file was never updated |
wg-quick down with SaveConfig | Live state into the file | Right after you edited the file |
wg syncconf | Kernel state only | Never; it does not touch the file |
wg-quick up | Kernel state from the file | If the file is stale, you get the old tunnel |
جدول را به‌عنوان هشداری درباره ترتیب بخوانید. هر از دست رفتن تصادفی در این حوزه از ویرایشی می‌آید که پیش از ذخیره‌سازی رخ داده است، نه پس از آن.
اول متوقف کنید، دوم ویرایش کنید، آخر شروع کنید
اگر فایل منبع حقیقت شماست، فایل را با ساختار معتبر کنید نه با امید. رابط را پایین بیاورید، تأیید کنید که رفته است، سپس ویرایش کنید و سپس دوباره بالا بیاورید. قاعده ساده است: هیچ ویرایشی وجود ندارد تا وقتی ذخیره‌سازی هنوز می‌تواند اجرا شود.
sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0خط پشتیبان‌گیری تشریفات نیست. اگر تونل راه رسیدن شما به این ماشین است، مرحله پایین آوردن می‌تواند نشست شما را پایان دهد، و یک نسخه روی دیسک به‌همراه یک کنسول یا مسیر خارج از باند تنها بازگردانی‌ای است که کار می‌کند. پیش از اعتماد به آن خط دوم، بررسی‌اش کنید: نام رابط قدیمی در اسکریپتی که بی‌صدا شکست می‌خورد همان روشی است که مردم فایلی را ویرایش می‌کنند که هنوز زنده است.
تنظیم SaveConfig = false پیش از یک پایین آوردن معمولی مسیر پذیرفته‌شده دیگر است، و باید در فایلی انجام شود که wg-quick واقعاً می‌خواند. جلوی آن یک ذخیره‌سازی خودکار را می‌گیرد. باعث نمی‌شود یک نمایه جداگانه NetworkManager، یک خروجی روتر یا یک نقطه ورود کانتینر ویرایش‌های شما را دوباره بارگذاری کنند، چون آن مدیران اصلاً این فایل را نمی‌خوانند.
تغییرات همتا را بدون پاره کردن رابط اعمال کنید
هر ویرایشی نیاز به قطعی ندارد. تغییرات سطح همتا را می‌توان با تبدیل فایل به یک پیکربندی و همگام‌سازی آن روی رابط در حال اجرا اعمال کرد، که مرحله پایین آوردن را کاملاً دور می‌زند و در نتیجه از ذخیره‌سازی هم دوری می‌کند:
sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakesمرحله strip مهم است. فایل را با حذف کلیدهایی که فقط مخصوص wg-quick هستند چاپ می‌کند، تا نشانی‌ها، DNS و دستورهای مسیریابی به ابزاری نروند که آن‌ها را نمی‌فهمد. سپس همگام‌سازی همتاها و کلیدها را بدون بازسازی رابط روی دستگاه زنده اعمال می‌کند، پس نشست‌ها و مسیرهای موجود زنده می‌مانند.
درباره محدودیت‌ها دقیق باشید. همگام‌سازی همتاها نشانی رابط، مسیرهایی که wg-quick افزوده است یا پیکربندی حل‌کننده را تغییر نمی‌دهد، چون هیچ‌یک از این‌ها به دستگاه WireGuard تعلق ندارد. افزودن یک زیرشبکه به AllowedIPs و انتظار اینکه هسته آن را مسیریابی کند همان بدخوانی کلاسیک است؛ مسیر باید هنگام بالا آمدن توسط wg-quick یا توسط شما افزوده شود.
پیش از ویرایش هر چیزی بررسی کنید رابط مال کیست
روی یک رومیزی یا سروری که با یک سامانه پیکربندی مدیریت می‌شود، فایل می‌تواند خروجی باشد نه ورودی. یک اتصال NetworkManager، نمایه‌ای که روتر تولید می‌کند یا اسکریپت شروع یک کانتینر می‌توانند همه مالک همان نام رابط باشند، و در این حالت یک توالی بی‌عیب wg-quick همچنان مصنوع اشتباه را ویرایش می‌کند.
systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5دستور سوم پیکربندی زنده را در همان قالب فایل چاپ می‌کند، شامل کلید خصوصی، که برای مقایسه مفید و در یک تیکت خطرناک است. پیش از چسباندن آن را بپوشانید؛ کلید خصوصی در یک رشته پشتیبانی یک افشای دائمی است، نه یک غلط تایپی.
اگر واحد سرویس غیرفعال است اما رابط وجود دارد، چیز دیگری آن را ساخته و فایل معتبر نیست. همان یک مشاهده یک ساعت ویرایش فایلی را ذخیره می‌کند که هیچ‌چیز آن را نمی‌خواند.
راه‌اندازی مجدد بعدی را بررسی کنید و سپس یک بازگردانی نگه دارید
آزمونی که واقعاً اصلاح را ثابت می‌کند یک راه‌اندازی مجدد دوم است، چون همان توالی بود که بار اول شکست خورد. تأیید کنید که همتا از آن جان سالم به در می‌برد و پیکربندی زنده هنوز با آنچه روی دیسک است مطابقت دارد:
sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.confراه‌اندازی مجدد را دو بار اجرا کنید. یک عبور پاک می‌تواند شانس باشد: راه‌اندازی مجدد اول ممکن است تغییری در زمان اجرا را مصرف کند که هنوز ذخیره نشده بود، پس دومی همان است که به شما می‌گوید فایل و زمان اجرا در پایان اولی توافق داشتند.
پشتیبان را از ابتدای فرایند نگه دارید تا راه‌اندازی مجدد دوگانه را انجام دهید، سپس آن را حذف کنید یا از پوشه پیکربندی بیرون ببرید. یک wg0.conf.bak سرگردان کنار فایل واقعی برای wg-quick بی‌ضرر و برای نفر بعدی گیج‌کننده است، کسی که در نهایت اشتباهی را ویرایش می‌کند.