रीस्टार्ट के बाद हटाया गया 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 सूची दोबारा पढ़ें। पुरानी कुंजी अनुपस्थित होनी चाहिए, और जिन peers को आप रखना चाहते थे वे अब भी मौजूद और काम कर रहे होने चाहिए।

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

जहाँ स्थिति अनुमति दे, पुष्टि करें कि पुरानी पहचान अब अपने पुराने संसाधनों तक नहीं पहुँचती। रीस्टार्ट से पहले की साफ़-सुथरी इंटरफ़ेस सूची आधी परीक्षा है। दूसरी आधी यह है कि पहचान उसके बाद अब भी क्या कर सकती है।

अगर कोई प्रबंधक peer को बार-बार बहाल करता रहे, तो निचले स्तर पर हटाने को दोहराना बंद करें। उस लेखक द्वारा पढ़ी जाने वाली सूची ठीक करें, क्योंकि तब तक हर रीस्टार्ट पहचान के फिर से प्रकट होने का एक और निमंत्रण है।