રીસ્ટાર્ટ પછી ડિલીટ કરેલ WireGuard peer કેમ પાછો આવે છે

ઓળખ ચાલતા ઇન્ટરફેસમાંથી અદૃશ્ય થઈ જાય છે અને ફેરફાર પૂરો લાગે છે. સેવા ફરી શરૂ થાય ત્યારે તે પાછી આવે છે, જે એવું લાગે કે WireGuard આદેશને અવગણી રહ્યું છે. ખરેખર જે થયું તે વધુ સરળ છે: બૂટ વખતની રૂપરેખામાં હજી પણ peer છે.

બે સ્થિતિ એ યાદી રાખે છે. રદ કરવું ત્યારે જ સાચું છે જ્યારે બંને તેને ગુમાવે.

wg set ખરેખર શું બદલે છે

wg set wg0 peer <public-key> remove આદેશ કર્નલમાં ચાલતું ઇન્ટરફેસ સંપાદિત કરે છે. તે ડિસ્ક પર કંઈ લખતો નથી. રૂપરેખા ફાઇલ, NetworkManager પ્રોફાઇલ કે રાઉટરની સાચવેલી સ્થિતિ અસ્પૃશ્ય રહે છે. આ ડિઝાઇન છે, ખામી નથી.

એ વિભાજન જાણી જોઈને છે, કારણ કે સાધનને ખબર નથી કે ઇન્ટરફેસનો માલિક કોણ છે. રનટાઇમ આદેશ બીજા કોઈ દ્વારા સંચાલિત ઇન્ટરફેસ સામે સુરક્ષિત હોવો જોઈએ. તે અનુમાન કરી શકતો નથી કે ટકાઉ નકલ ક્યાં રહે છે. પરિણામ સરળતાથી કહી શકાય: રનટાઇમ દરમિયાન દૂર કરવું રચનાથી જ અસ્થાયી છે.

તેથી peer આગલા રીસ્ટાર્ટ પર પાછો આવે છે, અને તેની મૂળ મંજૂર કરેલી પ્રીફિક્સ સાથે પાછો આવે છે. તેના દ્વારા રૂટ થતું દરેક વસ્તુ પણ ફરીથી બને છે. આમ કથિત રીતે રદ કરેલી ઓળખ ફરી લોડ કર્યા પછી તેના ભૂતપૂર્વ ગંતવ્યો સુધી પહોંચી શકે છે. રનટાઇમ આઉટપુટમાં કોઈને ચેતવણી મળી ન હતી.

ફાઇલ સંપાદિત કરતાં પહેલાં લખનારને શોધો

ઇન્ટરફેસનો એક માલિક છે. તે ફાઇલ વાંચતું wg-quick હોઈ શકે, પ્રોફાઇલ લાગુ કરતું NetworkManager, રાઉટરની પોતાની ઇન્ટરફેસ રૂપરેખા, અથવા શરૂઆતમાં ઇન્ટરફેસ ફરીથી બનાવતું કન્ટેનર એન્ટ્રીપોઇન્ટ. માલિક ક્યારેય ન વાંચે એવી ફાઇલ સંપાદિત કરવાથી કોઈ ટકાઉ ફેરફાર થતો નથી.

ચાલતા ઇન્ટરફેસથી શરૂ કરો અને પબ્લિક કી ઓળખો, કારણ કે નામ અને સરનામાં કી કરતાં નબળા ઓળખકર્તા છે. પછી એ યાદીની માલિક ખરેખર વાંચે છે તે સાચવેલી રૂપરેખા સાથે સરખામણી કરો.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

જે જીવંત ઇન્ટરફેસની peer યાદી અને ફાઇલનો સમાવિષ્ટ મેળ ખાતા નથી, તે આખું નિદાન છે. બૂટ વખતે સાચવેલી રૂપરેખા જીતે છે અને રનટાઇમ સ્થિતિ હારે છે. બંનેમાંથી કોઈપણ બદલતાં પહેલાં તેમની સરખામણી કરો.

SaveConfig નો સરંજામ

wg-quick એક ગડી ઉમેરે છે જે હાથે ફાઇલો સંપાદિત કરનારાઓને પકડે છે. SaveConfig સક્ષમ હોય ત્યારે તેનું દસ્તાવેજીકૃત બંધ થવાનું વર્તન વર્તમાન રનટાઇમ સ્થિતિને રૂપરેખા ફાઇલ પર લખે છે.

તે ટકાઉપણાની સામાન્ય દિશા ઉલટાવે છે. તમે ફાઇલમાંથી peer દૂર કરો છો, પછી સેવા થોભે છે. ચાલતી સ્થિતિ તમારા સંપાદન પર લખાય છે અને તમે હમણાં જ ડિલીટ કરેલ peer પાછો લાવે છે.

તેથી ક્રમ મહત્વનો છે: ઇન્ટરફેસ બંધ હોય ત્યારે ફાઇલ સંપાદિત કરો, અથવા સંપાદન પહેલાં SaveConfig બંધ કરો, પછી ઇન્ટરફેસ ફરી ચાલુ કરો અને શું લોડ થયું તેની ખાતરી કરો. ઇન્ટરફેસ ચાલુ હોય ત્યારે હાથે કરેલું સંપાદન બંધ થવાના લેખન સાથેની દોડ છે.

બંને સ્થિતિ બદલો, પછી ફરી લોડ કરો

રનટાઇમમાં કી દ્વારા peer દૂર કરો. સાચવેલી રૂપરેખામાં એ જ બ્લોક માલિકની સમર્થિત ક્રિયા દ્વારા દૂર કરો, તેની આસપાસ સંપાદન કરીને નહીં.

પછી peer શું વહન કરતો હતો તે તપાસો. રદ કરેલી ઓળખનું હતું એવું રૂટ કરેલું નેટવર્ક જાણી જોઈને ફરી સોંપવું કે દૂર કરવું જોઈએ, આગળ સંપાદિત થનાર peer દ્વારા ચૂપચાપ વારસામાં મળવું નહીં.

જો ગેટવે તમારી વ્યવસ્થાપકીય પહોંચ પણ વહન કરે તો પુનઃપ્રાપ્તિ માર્ગ ખુલ્લો રાખો. ખોટો peer દૂર કરતો રીસ્ટાર્ટ સ્વયં સર્જિત અટકાવ છે. ખોટો રૂટ દૂર કરતા રીસ્ટાર્ટ માટે પણ એ જ લાગુ પડે છે.

સફળ પરીક્ષણ કેવું દેખાય છે

સેવા ફરી લોડ કરો કે ફરી શરૂ કરો, પછી peer યાદી ફરી વાંચો. જૂની કી ગેરહાજર હોવી જોઈએ, અને જે peer તમે રાખવા માંગતા હતા તે હજી પણ હાજર અને કાર્યરત હોવા જોઈએ.

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

સ્થિતિ જ્યાં પરવાનગી આપે ત્યાં ખાતરી કરો કે જૂની ઓળખ હવે તેના ભૂતપૂર્વ સ્રોતો સુધી પહોંચતી નથી. રીસ્ટાર્ટ પહેલાંની વ્યવસ્થિત ઇન્ટરફેસ યાદી અડધી પરીક્ષા છે. બીજી અડધી એ છે કે ઓળખ ત્યારબાદ શું કરી શકે છે.

જો કોઈ મેનેજર peer ને વારંવાર પાછો લાવે છે, તો નીચલા સ્તરનું દૂર કરવાનું પુનરાવર્તન કરવાનું બંધ કરો. એ લખનાર જે ઇન્વેન્ટરી વાંચે છે તે સુધારો, કારણ કે ત્યાં સુધી દરેક રીસ્ટાર્ટ ઓળખ માટે ફરી દેખાવાનું બીજું આમંત્રણ છે.