पुनः सुरु गरेपछि मेटिएको 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 लाई बारम्बार पुनःस्थापित गर्दै छ भने, तल्लो स्तरको हटाउने कार्य दोहोर्याउन छोड्नुहोस्। त्यो लेखकले पढ्ने सूची सुधार्नुहोस्, किनभने त्यतिन्जेल हरेक पुनः सुरुवा पहिचान फेरि देखा पर्ने अर्को निम्तो हो।