Dlaczego wg-quick nadpisuje wg0.conf, gdy zatrzymujesz interfejs

Dodajesz peera do /etc/wireguard/wg0.conf, uruchamiasz systemctl restart wg-quick@wg0, a przy następnym spojrzeniu peera nie ma w pliku. Nic niczego nie uszkodziło. Restart to zatrzymanie, po którym następuje start, a krok zatrzymania może zapisać bieżący stan działania z powrotem na pliku, który właśnie edytowałeś. Odpowiedzialne ustawienie mieszka w tym samym pliku, który edytowałeś, i właśnie to sprawia, że pętla jest tak myląca za pierwszym razem.

Dwa stany, jeden plik i zapis przy wyłączaniu

Stan działania WireGuard i plik konfiguracyjny wg-quick są powiązane, ale różne. Plik jest wejściem: wg-quick go czyta, tworzy interfejs, ustawia adresy i trasy oraz konfiguruje peery. Urządzenie jądra jest żywym obiektem, a zmiany niskiego poziomu wykonane za pomocą wg nigdy nie zapisują się same.

Z wyjątkiem jednego kierunku. Gdy SaveConfig = true pojawia się w sekcji interfejsu, wg-quick zapisuje żywą konfigurację do pliku jako część opuszczania interfejsu. Podręcznik wg-quick ostrzega dokładnie przed tym: zmiany w pliku podczas działania interfejsu mogą zostać nadpisane, gdy interfejs zostanie usunięty. To zapis przy wyłączaniu, a nie timer w tle, więc uruchamia się tylko wtedy, gdy coś zatrzyma interfejs.

Czytaj tabelę jako ostrzeżenie o kolejności. Każda przypadkowa utrata w tym obszarze pochodzi z edycji, która nastąpiła przed zapisem, a nie po nim.

Najpierw zatrzymaj, potem edytuj, na końcu uruchom

Jeśli plik jest twoim źródłem prawdy, uczyń plik autorytatywnym przez konstrukcję, a nie przez nadzieję. Opuść interfejs, potwierdź, że zniknął, następnie edytuj, a potem podnieś go ponownie. Zasada jest prosta: żadna edycja nie istnieje, dopóki zapis może jeszcze działać.

sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0

Linia kopii zapasowej nie jest ceremonią. Jeśli tunel jest twoim sposobem dotarcia do tej maszyny, krok opuszczania może zakończyć twoją sesję, a kopia na dysku plus konsola lub ścieżka poza pasmem to jedyne działające wycofanie. Sprawdź tę drugą linię, zanim jej zaufasz: nieaktualna nazwa interfejsu w skrypcie, który po cichu zawodzi, to sposób, w jaki ludzie edytują plik, który wciąż żyje.

Ustawienie SaveConfig = false przed normalnym opuszczeniem to druga akceptowana droga i musi się odbyć w pliku, który wg-quick naprawdę czyta. Zapobiega temu jednemu automatycznemu zapisowi. Nie sprawia, że osobny profil NetworkManager, eksport routera lub punkt wejścia kontenera przeładują twoje zmiany, ponieważ ci menedżerowie w ogóle nie czytają tego pliku.

Stosuj zmiany peerów bez rozrywania interfejsu

Nie każda edycja wymaga przerwy. Zmiany na poziomie peera można zastosować do działającego interfejsu, konwertując plik na konfigurację i synchronizując ją, co całkowicie omija krok opuszczania, a więc omija zapis:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakes

Krok strip ma znaczenie. Wypisuje plik z usuniętymi kluczami należącymi tylko do wg-quick, dzięki czemu adresy, DNS i dyrektywy routingu nie trafiają do narzędzia, które ich nie rozumie. Następnie synchronizacja stosuje peery i klucze do żywego urządzenia bez ponownego tworzenia interfejsu, więc istniejące sesje i trasy przetrwają.

Bądź precyzyjny co do ograniczeń. Synchronizacja peerów nie zmienia adresu interfejsu, tras dodanych przez wg-quick ani konfiguracji resolvera, ponieważ żadna z tych rzeczy nie należy do urządzenia WireGuard. Dodanie podsieci do AllowedIPs i oczekiwanie, że jądro ją routowało, to klasyczne błędne odczytanie; trasę musi dodać wg-quick przy podnoszeniu albo ty.

Sprawdź, kto jest właścicielem interfejsu, zanim cokolwiek edytujesz

Na pulpicie lub serwerze zarządzanym przez system konfiguracji plik może być wyjściem, a nie wejściem. Połączenie NetworkManager, profil generowany przez router lub skrypt startowy kontenera mogą wszystkie posiadać tę samą nazwę interfejsu, a w takim przypadku bezbłędna sekwencja wg-quick nadal edytuje niewłaściwy artefakt.

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

Trzecie polecenie wypisuje żywą konfigurację w tym samym formacie co plik, łącznie z kluczem prywatnym, co jest przydatne do porównania i niebezpieczne w zgłoszeniu. Zredaguj go przed wklejeniem; klucz prywatny w wątku pomocy to trwałe naruszenie, a nie literówka.

Jeśli jednostka usługi jest nieaktywna, ale interfejs istnieje, coś innego go utworzyło i plik nie jest autorytatywny. Ta jedna obserwacja oszczędza godzinę edytowania pliku, którego nikt nie czyta.

Zweryfikuj następny restart, a potem zachowaj wycofanie

Test, który naprawdę dowodzi poprawki, to drugi restart, ponieważ właśnie ta sekwencja zawiodła za pierwszym razem. Potwierdź, że peer to przetrwa i że żywa konfiguracja nadal odpowiada temu, co jest na dysku:

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

Uruchom restart dwa razy. Jedno czyste przejście może być szczęściem: pierwszy restart może zużyć zmianę działania, która nie została jeszcze zapisana, więc drugi jest tym, który mówi ci, że plik i działanie były zgodne na końcu pierwszego.

Zachowaj kopię zapasową od początku procesu, aż wykonasz podwójny restart, a potem ją usuń lub przenieś poza katalog konfiguracji. Zabłąkany wg0.conf.bak obok prawdziwego pliku jest nieszkodliwy dla wg-quick i mylący dla następnej osoby, która w końcu edytuje niewłaściwy.