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: кога некоја поставка постојано се враќа, престанете да го бришете резултатот и најдете го процесот што постојано го создава.