WireGuard партньор изчезва след рестарт: намерете истинската конфигурация

Партньор, добавен с wg set, работи до следващия рестарт, защото интерфейсът се пресъздава от файл или профил, който никога не сте редактирали. Първо намерете собственика.

Партньорът, който добавихте с wg set, отговаря на ping цял следобед и изчезва след рестарта. Нищо не се е повредило: ядрото никога не е съхранявало този партньор никъде другаде освен в живия интерфейс и каквото пресъздава интерфейса при зареждане, го е изградило от файл, който не сте докоснали. Поправката не е още един wg set. Тя е да разберете кой компонент притежава интерфейса, да редактирате състоянието на този компонент и след това да докажете, че партньорът оцелява точно при събитието от жизнения цикъл, което го е премахнало.

Възпроизведете го веднъж, нарочно

Не поправяйте проблем с рестарт, преди да можете да го наблюдавате. С достъп през конзола или извън обхвата запишете списъка с партньори, рестартирайте през услугата, която притежава интерфейса, и сравнете. Ако партньорът е още там, промяната ви вече е достигнала до постоянното състояние и дебъгвате грешното събитие.

Запишете три факта, докато правите това: името на интерфейса, unit-а или профила, който го е стартирал, и дали броячът на ръкостискането при оцелелия партньор се е нулирал. Нулиран брояч означава, че интерфейсът е бил унищожен и пресъздаден; непроменен брояч при липсващ партньор означава, че нещо е редактирало конфигурацията под вас.

Кой притежава интерфейса?

Самият WireGuard няма демон и няма конфигурационен файл. Нещо над него извиква wg при зареждане и това нещо е източникът на истина. Обичайните кандидати са [email protected], профил за връзка на NetworkManager, мрежов unit за конкретната дистрибуция или панел за управление, който пише собствена база данни.

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

Накрая проверете какво е възстановил рестартът. Рестарт, който връща партньор, който нарочно сте премахнали, е същият бъг с обратен знак и обикновено означава, че старo копие на конфигурацията все още се зарежда отнякъде. Запишете собственика, пътя до файла, публичния ключ на партньора и командите за проверка до конфигурацията, за да не преоткрива следващият човек това, като рестартира продукционен хост.

Подобни статии