Пір 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, лічыльнік рукапаціску расце пасля трафіку, а праграма, якая залежыць ад тунэлю, сапраўды адказвае. Пір са старым рукапаціскам — гэта праблема маршрутызацыі або ключа, а не праблема захавання, і гэтае размежаванне зэканоміць бескарысную праўку канфіга.

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