NetworkManager czy wg-quick: kto zarządza Twoimi trasami WireGuard?

Zmieniasz AllowedIPs w pliku WireGuard, restartujesz tunel, a tabela routingu wygląda dokładnie jak wcześniej. Typowa reakcja to usunięcie przeszkadzającej trasy i pójście dalej, co działa do momentu, gdy następne połączenie przywróci ją z powrotem. Edytowany plik niekoniecznie jest obiektem, który wytworzył stan, który widzisz. Dwa menedżery mogą uruchamiać ten sam protokół na jednej maszynie, a tylko jeden z nich posiada interfejs w danej chwili.

Mit: na maszynie jest jedna konfiguracja WireGuard

wg-quick czyta plik w /etc/wireguard/ i buduje interfejs, gdy go podniesiesz. NetworkManager przechowuje profil połączenia we własnym formacie keyfile i renderuje go przy aktywacji, a import pliku wg-quick kopiuje wartości do tego profilu, zamiast się do niego odwoływać. Edycja oryginału później niczego nie zmienia, bo profil już go nie czyta. Ta sama lista peerów i kluczy może więc istnieć dwukrotnie, przy czym obowiązuje druga kopia.

Warto zapamiętać pewien sygnał: zmiany, które przetrwają restart, ale nie ponowny import, pochodzą z jednego magazynu, a zmiany znikające przy restarcie – z drugiego.

Jeden praktyczny przykład czyni podział oczywistym. Porównaj nmcli connection show z systemctl status wg-quick@wg0, a następnie sprawdź, do którego interfejsu naprawdę przypięte są trasy. Jeśli usługa jest martwa, a interfejs podniesiony, pracę wykonuje profil, cokolwiek mówi plik.

Mit: reguły routingu są częścią WireGuard

Urządzenie WireGuard w jądrze zna peery i klucze, a o routingu politycznym nie wie nic. Wszelkie ip rule wpisy i dodatkowe tabele, które widzisz, zainstalowało narzędzie, które podniosło interfejs. wg-quick może dodać fwmark i dedykowaną tabelę oraz reguły wskazujące na nią, podczas gdy NetworkManager instaluje trasy przez własne ustawienia ipv4 i zostawia DNS temu backendowi resolvera, którego używa system. Ten sam tunel, inne skutki uboczne.

Przeczytaj ip rule i ip route show table all przed jakąkolwiek zmianą i zanotuj, w której tabeli mieszka każda trasa. Numer tabeli, którego nie skonfigurowałeś, to mocna wskazówka dotycząca narzędzia, które ją utworzyło.

Mit: usunięcie trasy to naprawa

Trasa usunięta w czasie działania to trasa, którą właściciel zainstaluje ponownie przy następnej aktywacji, a aktywacja może nastąpić bez ciebie: wybudzenie laptopa, drgnięcie łącza, restart usługi albo automatyczne połączenie NetworkManagera. Dlatego ta sama trasa wraca i dlatego obejście wydaje się zawodne, a nie błędne. Najpierw zidentyfikuj menedżera, potem zmień dane wejściowe, które ten menedżer faktycznie czyta.

Ponowne połączenie i restart odpowiedniej usługi to test, który oddziela prawdziwą naprawę od tej tylko porządnie wyglądającej.

Wybierz jednego właściciela i usuń drugiego

Wybierz menedżera obsługiwanego przez twoje wdrożenie, a następnie wyłącz konkurencyjną aktywację przez jego udokumentowaną kontrolę, zamiast liczyć, że pozostanie bezczynna. Zamaskowana usługa wg-quick albo usunięty profil NetworkManagera są jawne; pozostawienie obu włączonych i ściganie się nimi już nie. Zachowaj działający dostęp, zanim cokolwiek wyłączysz, bo interfejs obsługujący twoją sesję zdalną może być właśnie tym, który zamierzasz usunąć.

Po zmianie sprawdź ruch uwzględniany i wykluczany, potem DNS, a potem zrestartuj raz. Jeśli stan przetrwa restart z jednym menedżerem, masz właściciela, a nie zbieg okoliczności.

Ogólna zasada jest warta zapamiętania także poza WireGuardem: gdy jakieś ustawienie ciągle wraca, przestań usuwać wynik i znajdź proces, który stale go wytwarza.