Pse wg-quick rishkruan wg0.conf kur ndalon ndërfaqen

Shto një peer në /etc/wireguard/wg0.conf, ekzekuton systemctl restart wg-quick@wg0, dhe peer-i zhduket nga skedari kur shikon përsëri. Asgjë nuk korruptoi asgjë. Një rinisje është një ndalim i ndjekur nga një nisje, dhe hapi i ndalimit mund të shkruajë gjendjen aktuale të ekzekutimit sipër skedarit që sapo redaktove. Cilësimi përgjegjës jeton në të njëjtin skedar që po redaktoje, dhe kjo është ajo që e bën ciklin kaq konfuz herën e parë që e has.

Dy gjendje, një skedar dhe një ruajtje në fikje

Gjendja e ekzekutimit e WireGuard dhe një skedar konfigurimi i wg-quick janë të lidhura por të dallueshme. Skedari është hyrje: wg-quick e lexon, krijon ndërfaqen, vendos adresat dhe rrugët dhe konfiguron peer-ët. Pajisja e kernelit është objekti i gjallë, dhe ndryshimet e nivelit të ulët të bëra me wg nuk shkruhen kurrë vetë përsëri.

Përveç në një drejtim. Kur SaveConfig = true shfaqet në seksionin e ndërfaqes, wg-quick ruan konfigurimin e gjallë në skedar si pjesë e uljes së ndërfaqes. Manuali i wg-quick paralajmëron pikërisht për këtë: ndryshimet e bëra në skedar ndërsa ndërfaqja është aktive mund të mbishkruhen kur ajo hiqet. Është një ruajtje në fikje, jo një kohëmatës në sfond, kështu që aktivizohet vetëm kur diçka ndalon ndërfaqen.

Lexo tabelën si një paralajmërim për rendin. Çdo humbje aksidentale në këtë fushë vjen nga një redaktim që ndodhi para një ruajtjeje dhe jo pas saj.

Ndal së pari, redakto së dyti, nis së fundi

Nëse skedari është burimi yt i së vërtetës, bëje skedarin autoritativ me ndërtim dhe jo me shpresë. Ule ndërfaqen, konfirmo që u zhduk, pastaj redakto dhe pastaj ngrije përsëri. Rregulli është i thjeshtë: asnjë redaktim nuk ekziston ndërsa një ruajtje mund të ekzekutohet ende.

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

Rreshti i kopjes rezervë nuk është ceremoni. Nëse tuneli është mënyra si arrin në këtë makinë, hapi i uljes mund të përfundojë sesionin tënd, dhe një kopje në disk plus një konsolë ose një rrugë jashtë brezit është e vetmja kthim që funksionon. Kontrollo atë rresht të dytë përpara se t'i besosh: një emër i vjetëruar ndërfaqeje në një skript që dështon në heshtje është mënyra si njerëzit redaktojnë një skedar që është ende i gjallë.

Vendosja e SaveConfig = false para një uljeje normale është rruga tjetër e pranuar, dhe duhet bërë në skedarin që wg-quick lexon vërtet. Ajo parandalon atë ruajtje të vetme automatike. Nuk bën që një profil i veçantë i NetworkManager, një eksport routeri ose një pikë hyrjeje kontejneri të ringarkojnë redaktimet e tua, sepse ata menaxherë nuk e lexojnë fare këtë skedar.

Zbato ndryshimet e peer-ëve pa e grisur ndërfaqen

Jo çdo redaktim kërkon ndërprerje. Ndryshimet në nivel peer mund të zbatohen në një ndërfaqe në punë duke e kthyer skedarin në një konfigurim dhe duke e sinkronizuar, gjë që shmang plotësisht hapin e uljes dhe për rrjedhojë shmang ruajtjen:

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

Hapi strip ka rëndësi. Ai printon skedarin me çelësat që i përkasin vetëm wg-quick të hequr, kështu që adresat, DNS dhe direktivat e rrugëzimit nuk shkojnë në një mjet që nuk i kupton. Pastaj sinkronizimi zbaton peer-ët dhe çelësat në pajisjen e gjallë pa rikrijuar ndërfaqen, kështu që sesionet dhe rrugët ekzistuese mbijetojnë.

Jini të saktë për kufijtë. Sinkronizimi i peer-ëve nuk ndryshon adresën e ndërfaqes, rrugët e shtuara nga wg-quick ose konfigurimin e zgjidhësit, sepse asnjë prej tyre nuk i përket pajisjes WireGuard. Shtimi i një nënrrjeti në AllowedIPs dhe pritja që kernel-i ta rrugëzojë është lexsimi klasik i gabuar; rruga duhet të shtohet nga wg-quick në ngritje ose nga ti.

Kontrollo kush e zotëron ndërfaqen përpara se të redaktosh çdo gjë

Në një desktop ose server të menaxhuar nga një sistem konfigurimi, skedari mund të jetë dalje dhe jo hyrje. Një lidhje NetworkManager, një profil i gjeneruar nga routeri ose një skript nisjeje kontejneri mund të zotërojnë të gjithë të njëjtin emër ndërfaqeje, dhe në atë rast një sekuencë e patëmetë e wg-quick prapë redakton artefaktin e gabuar.

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

Komanda e tretë printon konfigurimin e gjallë në të njëjtin format si skedari, përfshirë çelësin privat, gjë që është e dobishme për krahasim dhe e rrezikshme në një tiketë. Redaktoje para se ta ngjitësh; një çelës privat në një fije mbështetjeje është kompromis i përhershëm, jo një gabim shtypi.

Nëse njësia e shërbimit është joaktive por ndërfaqja ekziston, diçka tjetër e krijoi dhe skedari nuk është autoritativ. Ai vëzhgim i vetëm kursen një orë redaktimi të një skedari që asgjë nuk e lexon.

Verifiko rinisjen tjetër dhe pastaj mbaj një kthim

Testi që vërtet e provon rregullimin është një rinisje e dytë, sepse ajo është sekuenca që dështoi herën e parë. Konfirmo që peer-i i mbijeton dhe që konfigurimi i gjallë ende përputhet me atë që është në disk:

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

Ekzekuto rinisjen dy herë. Një kalim i vetëm i pastër mund të jetë fat: rinisja e parë mund të konsumojë një ndryshim ekzekutimi që nuk ishte ruajtur ende, kështu që e dyta është ajo që të thotë se skedari dhe ekzekutimi ranë dakord në fund të së parës.

Mbaje kopjen rezervë nga fillimi i procesit derisa të kesh bërë rinisjen e dyfishtë, pastaj fshije ose zhvendose jashtë drejtorisë së konfigurimit. Një wg0.conf.bak i humbur pranë skedarit të vërtetë është i padëmshëm për wg-quick dhe konfuz për personin tjetër, i cili përfundimisht do të redaktojë të gabuarin.