रीस्टार्टनंतर हटवलेला 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 सतत पुनर्संचयित करत असेल, तर निम्न स्तरावरील काढण्याची पुनरावृत्ती थांबवा. तो लेखक जी यादी वाचतो ती दुरुस्त करा, कारण तोपर्यंत प्रत्येक रीस्टार्ट म्हणजे ओळखीला पुन्हा प्रकट होण्याचे आणखी एक निमंत्रण.