Чаму wg-quick перазапісвае wg0.conf пры спыненні інтэрфейса

Вы дадаяце пір у /etc/wireguard/wg0.conf, запускаеце systemctl restart wg-quick@wg0, і пір знікае з файла, калі вы зноў заглядаеце. Нішто нічога не пашкодзіла. Перазапуск — гэта спыненне, за якім ідзе запуск, і крок спынення можа запісаць бягучы стан выканання паверх файла, які вы толькі што адрэдагавалі. Налада, якая за гэта адказвае, жыве ў тым самым файле, які вы рэдагавалі, і менавіта гэта робіць цыкл такім заблытаным, калі вы сутыкаецеся з ім упершыню.

Два станы, адзін файл і захаванне пры выключэнні

Стан выканання WireGuard і файл канфігурацыі wg-quick звязаныя, але розныя. Файл — гэта ўваход: wg-quick чытае яго, стварае інтэрфейс, задае адрасы і маршруты і наладжвае піры. Прылада ядра — гэта жывы аб’ект, і нізкаўзроўневыя змены, зробленыя з дапамогай wg, ніколі не запісваюць сябе назад.

Акрамя аднаго кірунку. Калі SaveConfig = true з’яўляецца ў раздзеле інтэрфейса, wg-quick захоўвае жывую канфігурацыю ў файл як частку апускання інтэрфейса. Кіраўніцтва wg-quick папярэджвае менавіта пра гэта: змены, зробленыя ў файле, пакуль інтэрфейс уключаны, могуць быць перазапісаныя, калі ён выдаляецца. Гэта захаванне ў момант выключэння, а не фонавы таймер, таму яно спрацоўвае толькі тады, калі нешта спыняе інтэрфейс.

Чытайце табліцу як папярэджанне пра парадак. Кожная выпадковая страта ў гэтай вобласці паходзіць ад рэдагавання, якое адбылося да захавання, а не пасля яго.

Спачатку спыніце, потым рэдагуйце, апошнім запусціце

Калі файл — ваша крыніца праўды, зрабіце файл аўтарытэтным праз пабудову, а не праз надзею. Апусціце інтэрфейс, пераканайцеся, што ён знік, потым рэдагуйце, потым падніміце яго зноў. Правіла простае: ніякага рэдагавання не існуе, пакуль яшчэ можа выканацца захаванне.

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 і заблытвае наступнага чалавека, які ўрэшце адрэдагуе не той.