Peer-i i WireGuard humbet pas rinisjes: gjeni konfigurimin e vërtetë

Peer-i që shtuat me wg set përgjigjet ndaj ping gjithë pasditen dhe humbet pas rinisjes. Asgjë nuk u dëmtua: kernel-i nuk e ruajti kurrë atë peer diku tjetër përveç në ndërfaqen aktive, dhe çdo gjë që rikrijon ndërfaqen gjatë nisjes e ndërtoi atë nga një skedar që nuk e keni prekur. Riparimi nuk është një wg set tjetër. Bëhet fjalë për të zbuluar cili komponent zotëron ndërfaqen, për të redaktuar gjendjen e atij komponenti dhe më pas për të provuar se peer-i i mbijeton pikërisht atij ngjarjeje të ciklit të jetës që e hoqi.

Riprodhoni një herë, me qëllim

Mos e rregulloni një problem rinisjeje para se ta shihni duke ndodhur. Me akses konsol ose jashtë brezit në dispozicion, shënoni listën e peer-ve, rinisni përmes shërbimit që zotëron ndërfaqen dhe krahasoni. Nëse peer-i është ende aty, ndryshimi juaj ka arritur tashmë gjendjen e vazhdueshme dhe po korrigjoni ngjarjen e gabuar.

Shënoni tre fakte ndërsa e bëni këtë: emrin e ndërfaqes, njësinë ose profilin që e nisi, dhe nëse numëruesi i shtrëngimit të duarve tek peer-i që mbijetoi u rivendos. Numërues i rivendosur do të thotë që ndërfaqja u shkatërrua dhe u rikrijua; numërues i pandryshuar me një peer që mungon do të thotë që diçka redaktoi konfigurimin nën këmbët tuaja.

Kush e zotëron ndërfaqen?

Vetë WireGuard nuk ka daemon dhe nuk ka skedar konfigurimi. Diçka mbi të thërret wg gjatë nisjes, dhe ajo diçka është burimi i së vërtetës. Kandidatët e zakonshëm janë [email protected], një profil lidhjeje i NetworkManager, një njësi rrjeti specifike për shpërndarjen ose një panel administrimi që shkruan bazën e vet të të dhënave.

Pyetni sistemin, jo dokumentacionin e shpërndarjes tuaj. systemctl status wg-quick@wg0 dhe nmcli connection show zakonisht e zgjidhin çështjen me nga një komandë secili. Nëse të dy pretendojnë ndërfaqen, e keni gjetur gabimin para se të redaktoni gjithçka: dy pronarë rishkruajnë të njëjtën pajisje në çdo nisje, dhe fiton ai që ekzekutohet i fundit.

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

Gjendja e kohës së punës dhe gjendja e nisjes nuk janë i njëjti skedar

wg set manipulon pajisjen aktive përmes netlink. Ai nuk shkruan /etc/wireguard/wg0.conf, një profil NetworkManager ose bazën e të dhënave të një paneli. Një wg show i suksesshëm më pas provon që kernel-i e pranoi peer-in, jo se diçka do ta rikthejë.

Ka një kurth të dytë në drejtimin e kundërt. Opsioni SaveConfig i wg-quick shkruan gjendjen aktuale të ndërfaqes përsëri në skedarin e konfigurimit kur ndërfaqja ulet. Kur është aktiv, një redaktim i bërë në skedar ndërsa ndërfaqja është lart mund të mbishkruhet nga fikja që vjen, dhe do të betoheni se ajo rresht ishte aty. Nëse peer-i kthehet vazhdimisht, lexoni skedarin pas një ndaljeje, jo para.

NetworkManager sillet ndryshe përsëri: ai e zotëron profilin dhe e zbaton në aktivizim, kështu që një .conf i redaktuar me dorë pranë një lidhjeje aktive NetworkManager është thjesht dekor. Zgjidhni një pronar për ndërfaqen dhe lëreni menaxherin tjetër të mos e prekë.

Sigurohuni që ndryshimi të ulet në të dyja vendet

Redaktoni fillimisht gjendjen e vazhdueshme, më pas lëreni pronarin ta zbatojë, dhe në fund verifikoni gjendjen aktive. Ky rend do të thotë që një dështim në çdo hap tregon një gjë në vend të tre.

# 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 shtyp konfigurimin aktiv në të njëjtën sintaksë që përdor skedari, gjë që i bën të dy të krahasueshëm drejtpërdrejt. Trajtojeni atë dalje si sekret: përmban çelësa privatë, prandaj mos e ngjitni në një tiketë ose kanal bisede. Krahasoni çelësat publikë të peer-ve dhe IP-të e lejuara, dhe kontrolloni që peer-i i hequr me qëllim nuk është kthyer.

Provoni se i mbijeton ngjarjes së ciklit të jetës

Rinisni përmes pronarit një herë të dytë, më pas konfirmoni tre gjëra të ndara: peer-i shfaqet në wg show, numëruesi i shtrëngimit të duarve rritet pas trafikut, dhe aplikacioni që varet nga tuneli përgjigjet vërtet. Një peer i listuar me shtrëngim duarsh të vjetër është problem rrugëtimi ose çelësi, jo problem vazhdimësie, dhe ky dallim kursen një redaktim të panevojshëm konfigurimi.

Së fundi, kontrolloni çfarë rivendosi rinisja. Një rinisje që ringjall një peer që e hoqët me qëllim është i njëjti gabim me shenjë të kundërt, dhe zakonisht do të thotë që një kopje e vjetër e konfigurimit vazhdon të ngarkohet nga diku. Shënoni pronarin, rrugën e skedarit, çelësin publik të peer-it dhe komandat e verifikimit pranë konfigurimit, që personi tjetër të mos e rizbulojë këtë duke rinisur një host prodhimi.