WireGuard peer nestaje nakon restarta: pronađite pravu konfiguraciju

Peer koji ste dodali pomoću wg set odgovara na ping cijelo poslijepodne, a nakon ponovnog pokretanja ga nema. Ništa nije oštećeno: kernel taj peer nikada nije nigdje pohranio osim u živom interfejsu, a sve što pri pokretanju ponovo stvara interfejs izgradilo ga je iz datoteke koju niste dirali. Popravak nije još jedan wg set. Potrebno je otkriti koja komponenta posjeduje interfejs, urediti stanje te komponente i zatim dokazati da peer preživljava upravo onaj događaj životnog ciklusa koji ga je uklonio.

Reproducirajte to jednom, namjerno

Ne popravljajte problem s restartom dok ga ne možete vidjeti vlastitim očima. Uz dostupan pristup preko konzole ili izvan pojasa, zabilježite listu peerova, restartajte preko servisa koji posjeduje interfejs i uporedite. Ako je peer još tamo, vaša izmjena je već stigla u trajno stanje i otklanjate greške na pogrešnom događaju.

Zapišite tri činjenice dok to radite: naziv interfejsa, unit ili profil koji ga je pokrenuo, i da li se brojač rukovanja na preostalom peeru resetovao. Resetovan brojač znači da je interfejs uništen i ponovo stvoren; nepromijenjen brojač uz peer koji nedostaje znači da je nešto uredilo konfiguraciju ispod vas.

Ko posjeduje interfejs?

Sam WireGuard nema demona ni konfiguracijsku datoteku. Nešto iznad njega poziva wg pri pokretanju i to nešto je izvor istine. Uobičajeni kandidati su [email protected], NetworkManager profil veze, mrežni unit specifičan za distribuciju ili upravljački panel koji piše vlastitu bazu podataka.

Pitajte sistem, a ne dokumentaciju svoje distribucije. systemctl status wg-quick@wg0 i nmcli connection show obično to riješe jednom komandom svaki. Ako oba polažu pravo na interfejs, pronašli ste grešku prije nego što ste bilo šta uredili: dva vlasnika prepisuju isti uređaj pri svakom pokretanju, a pobjedu odnosi onaj koji se izvrši posljednji.

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

Stanje u radu i stanje pri pokretanju nisu ista datoteka

wg set upravlja živim uređajem preko netlinka. Ne upisuje /etc/wireguard/wg0.conf, NetworkManager profil ni bazu podataka panela. Uspješan wg show nakon toga dokazuje da je kernel prihvatio peer, a ne da će ga nešto vratiti.

Postoji i druga zamka u suprotnom smjeru. Opcija SaveConfig u wg-quicku upisuje trenutno stanje interfejsa natrag u konfiguracijsku datoteku kada se interfejs spusti. Kada je uključena, izmjenu datoteke napravljenu dok je interfejs podignut može prepisati gašenje koje slijedi, i zaklet ćete se da je taj red bio tamo. Ako se peer stalno vraća, čitajte datoteku nakon zaustavljanja, ne prije.

NetworkManager se ponaša opet drugačije: on posjeduje profil i primjenjuje ga pri aktivaciji, pa je ručno uređeni .conf pored aktivne NetworkManager veze samo ukras. Odaberite jednog vlasnika interfejsa i pustite da ga drugi menadžer ne dira.

Neka izmjena stigne na oba mjesta

Prvo uredite trajno stanje, zatim pustite vlasnika da ga primijeni, a potom provjerite živo stanje. Taj redoslijed znači da kvar na bilo kojem koraku upućuje na jednu stvar umjesto na tri.

# 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 ispisuje živu konfiguraciju u istoj sintaksi koju koristi datoteka, što dvije čini direktno uporedivim. Tretirajte taj ispis kao tajnu: sadrži privatne ključeve, pa ga ne lijepite u tiket ni u chat kanal. Uporedite javne ključeve peerova i dopuštene IP adrese i provjerite da se peer koji ste namjerno uklonili nije vratio.

Dokažite da preživljava događaj životnog ciklusa

Restartajte preko vlasnika drugi put, pa potvrdite tri odvojene stvari: peer se pojavljuje u wg show, brojač rukovanja raste nakon saobraćaja i aplikacija koja zavisi od tunela zaista odgovara. Peer naveden sa zastarjelim rukovanjem je problem rutiranja ili ključa, a ne problem postojanosti, i ta razlika štedi besmislenu izmjenu konfiguracije.

Na kraju provjerite šta je restart vratio. Restart koji oživljava peer koji ste namjerno uklonili ista je greška sa suprotnim znakom i obično znači da se stara kopija konfiguracije još uvijek učitava negdje. Zapišite vlasnika, putanju datoteke, javni ključ peera i komande za provjeru pored konfiguracije, kako sljedeća osoba to ne bi ponovo otkrila restartujući produkcioni host.