Peer WireGuard znika po restarcie: znajdź prawdziwą konfigurację

Peer, którego dodałeś przez wg set, odpowiada na ping przez całe popołudnie i znika po restarcie. Nic się nie zepsuło: jądro nigdy nie zapisało tego peera nigdzie indziej niż w żywym interfejsie, a wszystko, co odtwarza interfejs przy starcie, zbudowało go z pliku, którego nie tknąłeś. Naprawa nie polega na kolejnym wg set. Trzeba ustalić, który komponent posiada interfejs, zmienić stan tego komponentu, a potem udowodnić, że peer przeżywa dokładnie to zdarzenie cyklu życia, które go usunęło.

Odtwórz to raz, celowo

Nie naprawiaj problemu z restartem, dopóki nie zobaczysz go na własne oczy. Mając dostęp do konsoli lub dostęp poza pasmem, zanotuj listę peerów, zrestartuj przez usługę, która posiada interfejs, i porównaj. Jeśli peer nadal tam jest, twoja zmiana już dotarła do trwałego stanu i debugujesz nie to zdarzenie.

Zapisz trzy fakty: nazwę interfejsu, jednostkę lub profil, który go uruchomił, oraz to, czy licznik uścisku dłoni na ocalałym peerze został wyzerowany. Wyzerowany licznik oznacza, że interfejs został zniszczony i utworzony od nowa; niezmieniony licznik przy brakującym peerze oznacza, że coś edytowało konfigurację pod twoimi stopami.

Kto posiada interfejs?

Sam WireGuard nie ma ani demona, ani pliku konfiguracji. Coś nad nim wywołuje przy starcie wg, i to coś jest źródłem prawdy. Typowi kandydaci to [email protected], profil połączenia NetworkManager, jednostka sieciowa właściwa dla dystrybucji albo panel zarządzania, który zapisuje własną bazę danych.

Pytaj system, a nie dokumentację swojej dystrybucji. systemctl status wg-quick@wg0 i nmcli connection show zwykle rozstrzygają to po jednym poleceniu każdy. Jeśli oba roszczą sobie prawo do interfejsu, znalazłeś błąd przed edycją czegokolwiek: dwóch właścicieli przepisuje to samo urządzenie przy każdym starcie, a wygrywa ten, który uruchomi się ostatni.

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

Stan działania i stan startowy to nie ten sam plik

wg set steruje żywym urządzeniem przez netlink. Nie zapisuje /etc/wireguard/wg0.conf, profilu NetworkManager ani bazy danych panelu. Udany wg show potem dowodzi, że jądro przyjęło peera, a nie że coś go przywróci.

Istnieje druga pułapka w przeciwnym kierunku. Opcja SaveConfig w wg-quick zapisuje bieżący stan interfejsu z powrotem do pliku konfiguracji, gdy interfejs jest opuszczany. Gdy jest włączona, edycja pliku wykonana przy działającym interfejsie może zostać nadpisana przez następne wyłączenie, i będziesz przysięgać, że ta linia tam była. Jeśli peer ciągle wraca, czytaj plik po zatrzymaniu, nie przed.

NetworkManager zachowuje się jeszcze inaczej: posiada profil i stosuje go przy aktywacji, więc ręcznie edytowany .conf obok aktywnego połączenia NetworkManager jest tylko dekoracją. Wybierz jednego właściciela interfejsu i pozwól drugiemu menedżerowi go nie ruszać.

Doprowadź do tego, by zmiana trafiła w oba miejsca

Najpierw edytuj stan trwały, potem pozwól właścicielowi go zastosować, a na końcu sprawdź stan żywy. Taka kolejność sprawia, że awaria na dowolnym etapie wskazuje na jedną rzecz, a nie trzy.

# 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 wypisuje żywą konfigurację w tej samej składni, której używa plik, dzięki czemu oba można porównać bezpośrednio. Traktuj to wyjście jak tajemnicę: zawiera klucze prywatne, więc nie wklejaj go do zgłoszenia ani kanału czatu. Porównaj klucze publiczne peerów i dozwolone adresy IP, i sprawdź, czy peer usunięty celowo nie wrócił.

Udowodnij, że przeżywa zdarzenie cyklu życia

Zrestartuj przez właściciela po raz drugi, a następnie potwierdź trzy osobne rzeczy: peer pojawia się w wg show, licznik uścisku dłoni rośnie po ruchu, a aplikacja zależna od tunelu rzeczywiście odpowiada. Peer widoczny ze starym uściskiem dłoni to problem routingu albo klucza, a nie trwałości, i to rozróżnienie oszczędza bezsensowną zmianę konfiguracji.

Na koniec sprawdź, co przywrócił restart. Restart, który wskrzesza celowo usuniętego peera, to ten sam błąd z przeciwnym znakiem, i zwykle oznacza, że stara kopia konfiguracji wciąż jest skądś ładowana. Zapisz właściciela, ścieżkę pliku, klucz publiczny peera i polecenia weryfikacyjne obok konfiguracji, żeby następna osoba nie odkryła tego ponownie, restartując host produkcyjny.