Peerul WireGuard dispare după repornire: găsiți configurația reală

Peerul pe care l-ați adăugat cu wg set răspunde la ping toată după-amiaza și dispare după repornire. Nimic nu s-a corupt: kernelul nu a stocat niciodată acel peer altundeva decât în interfața activă, iar tot ce recreează interfața la pornire l-a reconstruit dintr-un fișier pe care nu l-ați atins. Reparația nu este încă un wg set. Este vorba de a afla ce componentă deține interfața, de a edita starea acelei componente și apoi de a demonstra că peerul supraviețuiește exact evenimentului din ciclul de viață care l-a eliminat.

Reproduceți-l o dată, intenționat

Nu reparați o problemă de repornire înainte de a o putea vedea întâmplându-se. Cu acces la consolă sau în afara benzii disponibil, notați lista de peeri, reporniți prin serviciul care deține interfața și comparați. Dacă peerul este încă acolo, modificarea dumneavoastră a ajuns deja în starea persistentă și depanați evenimentul greșit.

Notați trei fapte în timp ce faceți asta: numele interfeței, unitatea sau profilul care a pornit-o și dacă contorul de handshake de pe peerul supraviețuitor a fost resetat. Un contor resetat înseamnă că interfața a fost distrusă și recreată; un contor neschimbat cu un peer lipsă înseamnă că ceva a editat configurația sub picioarele dumneavoastră.

Cine deține interfața?

WireGuard în sine nu are daemon și nici fișier de configurare. Ceva deasupra lui apelează wg la pornire, iar acel ceva este sursa adevărului. Candidații obișnuiți sunt [email protected], un profil de conexiune NetworkManager, o unitate de rețea specifică distribuției sau un panou de administrare care își scrie propria bază de date.

Întrebați sistemul, nu documentația distribuției dumneavoastră. systemctl status wg-quick@wg0 și nmcli connection show rezolvă de obicei problema cu câte o comandă fiecare. Dacă ambele revendică interfața, ați găsit eroarea înainte de a edita ceva: doi proprietari rescriu același dispozitiv la fiecare pornire, iar ultimul care rulează câștigă.

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

Starea de execuție și starea de pornire nu sunt același fișier

wg set manipulează dispozitivul activ prin netlink. Nu scrie /etc/wireguard/wg0.conf, un profil NetworkManager sau baza de date a unui panou. Un wg show reușit după aceea demonstrează că kernelul a acceptat peerul, nu că ceva îl va restaura.

Există o a doua capcană în direcția opusă. Opțiunea SaveConfig din wg-quick scrie starea curentă a interfeței înapoi în fișierul de configurare atunci când interfața este coborâtă. Când este activă, o modificare făcută în fișier cât timp interfața este ridicată poate fi suprascrisă de oprirea care urmează, iar dumneavoastră veți jura că linia era acolo. Dacă peerul revine mereu, citiți fișierul după o oprire, nu înainte.

NetworkManager se comportă din nou altfel: deține profilul și îl aplică la activare, așa că un .conf editat manual lângă o conexiune NetworkManager activă este doar decor. Alegeți un singur proprietar pentru interfață și lăsați celălalt manager să nu se atingă de ea.

Faceți ca modificarea să ajungă în ambele locuri

Editați mai întâi starea persistentă, lăsați proprietarul să o aplice, apoi verificați starea activă. Această ordine înseamnă că un eșec la orice pas indică un singur lucru în loc de trei.

# 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 afișează configurația activă în aceeași sintaxă pe care o folosește fișierul, ceea ce face cele două direct comparabile. Tratați acea ieșire ca pe un secret: conține chei private, așa că nu o lipiți într-un tichet sau într-un canal de chat. Comparați cheile publice ale peerilor și IP-urile permise și verificați că peerul pe care l-ați eliminat intenționat nu a revenit.

Demonstrați că supraviețuiește evenimentului din ciclul de viață

Reporniți prin proprietar a doua oară, apoi confirmați trei lucruri separate: peerul apare în wg show, contorul de handshake crește după trafic și aplicația care depinde de tunel răspunde efectiv. Un peer listat cu un handshake vechi este o problemă de rutare sau de cheie, nu de persistență, iar această distincție economisește o editare inutilă a configurației.

În final, verificați ce a restaurat repornirea. O repornire care readuce la viață un peer pe care l-ați eliminat deliberat este aceeași eroare cu semn opus și înseamnă de obicei că o copie veche a configurației este încă încărcată de undeva. Notați proprietarul, calea fișierului, cheia publică a peerului și comenzile de verificare lângă configurație, ca următoarea persoană să nu redescopere asta repornind un host de producție.