NetworkManager срещу wg-quick: кой притежава вашите маршрути WireGuard?

Променяте AllowedIPs във файла на WireGuard, рестартирате тунела и таблицата за маршрутизация изглежда точно както преди. Обичайната реакция е да изтриете проблемния маршрут и да продължите, което работи, докато следващото повторно свързване не го върне. Файлът, който редактирахте, не е непременно обектът, създал състоянието, което виждате. Два мениджъра могат да работят с един и същ протокол на една машина и само един от тях притежава интерфейса в даден момент.

Мит: на машината има една конфигурация на WireGuard

wg-quick чете файл под /etc/wireguard/ и изгражда интерфейса, когато го вдигнете. NetworkManager съхранява профил на връзката в собствен keyfile формат и го представя при активиране, а импортирането на wg-quick файл копира стойностите в този профил, вместо да сочи към него. Редактирането на оригинала след това не променя нищо, защото профилът вече не го чете. Така един и същ списък от партньори и ключове може да съществува два пъти, като действа второто копие.

Един признак, който си струва да запомните: промени, които оцеляват след рестарт, но не и след повторен импорт, идват от едно хранилище, а промени, които изчезват при рестарт, идват от другото.

Един практически пример прави разделението очевидно. Сравнете nmcli connection show с systemctl status wg-quick@wg0, после проверете към кой интерфейс всъщност принадлежат маршрутите. Ако услугата е мъртва, а интерфейсът е вдигнат, работата върши профилът, каквото и да казва файлът.

Мит: правилата за маршрутизация са част от WireGuard

Устройството WireGuard в ядрото познава партньори и ключове и не знае нищо за маршрутизация по политика. Каквито и ip rule записи и допълнителни таблици да видите, те са инсталирани от инструмента, който е вдигнал интерфейса. wg-quick може да добави fwmark и отделна таблица плюс правила, сочещи към нея, докато NetworkManager инсталира маршрути чрез собствените си ipv4 настройки и оставя DNS на който и резолверен бекенд да ползва системата. Същият тунел, различни странични ефекти.

Прочетете ip rule и ip route show table all преди да промените каквото и да е, и отбележете в коя таблица живее всеки маршрут. Номер на таблица, който не сте конфигурирали, е силен намек за инструмента, който я е създал.

Мит: изтриването на маршрута е поправка

Маршрут, изтрит по време на работа, е маршрут, който собственикът ще преинсталира при следващото активиране, а активирането може да стане без вас: събуждане на лаптоп, смущение на връзката, рестарт на услуга или автоматично свързване на NetworkManager. Затова същият маршрут се връща и затова заобиколното решение изглежда ненадеждно, а не грешно. Първо определете мениджъра, после променете входа, който той действително чете.

Повторното свързване и рестартирането на съответната услуга са тестът, който отделя истинската поправка от добре изглеждащата.

Изберете един собственик и премахнете другия

Изберете мениджъра, който разгръщането ви поддържа, после изключете конкуриращото активиране чрез документирания му контрол, вместо да се надявате, че ще остане бездейно. Маскирана wg-quick услуга или изтрит NetworkManager профил е явно; да оставите и двете включени и да ги оставите да се надпреварват не е. Запазете работещ достъп, преди да изключите нещо, защото интерфейсът, който носи отдалечената ви сесия, може да е този, който сте на път да премахнете.

След промяната проверете включения и изключения трафик, после DNS, после рестартирайте веднъж. Ако състоянието оцелее след рестарт с един мениджър, имате собственик, а не съвпадение.

Общото правило си струва да се помни и извън WireGuard: когато дадена настройка се връща отново и отново, спрете да триете резултата и намерете процеса, който продължава да го създава.