रिस्टार्ट पछि WireGuard पियर हराउँछ: वास्तविक कन्फिगरेसन खोज्नुहोस्

wg set ले थपेको पियर दिउँसोभरि ping को जवाफ दिन्छ र रिबुटपछि हराउँछ। केही पनि बिग्रिएको थिएन: कर्नेलले त्यो पियरलाई जीवित इन्टरफेसबाहेक कतै राखेन, र बुटको समयमा इन्टरफेस पुनः बनाउने जुनसुकै चीजले तपाईंले छोएको नभएको फाइलबाट त्यो बनायो। मर्मत अर्को wg set होइन। कुन घटकले इन्टरफेसको स्वामित्व राख्छ भनी पत्ता लगाउनु, त्यो घटकको अवस्था सम्पादन गर्नु, र त्यसपछि पियरले त्यसलाई हटाउने ठ्याक्कै त्यही जीवनचक्र घटनाबाट बाँच्न सक्छ भनी प्रमाणित गर्नु नै मर्मत हो।

यसलाई एक पटक जानाजान पुनः उत्पादन गर्नुहोस्

रिस्टार्टको समस्या आफ्नै आँखाले देख्नुअघि सुधार नगर्नुहोस्। कन्सोल वा आउट-अफ-ब्यान्ड पहुँच उपलब्ध भए पियरको सूची टिप्नुहोस्, इन्टरफेसको मालिक भएको सेवाबाट रिस्टार्ट गर्नुहोस्, र तुलना गर्नुहोस्। यदि पियर अझै त्यहीँ छ भने तपाईंको परिवर्तन पहिले नै स्थायी अवस्थामा पुगिसकेको छ र तपाईं गलत घटना डिबग गर्दै हुनुहुन्छ।

यसो गर्दा तीन तथ्य लेख्नुहोस्: इन्टरफेसको नाम, यसलाई सुरु गर्ने युनिट वा प्रोफाइल, र बाँचेको पियरको ह्यान्डसेक काउन्टर रिसेट भयो कि भएन। रिसेट भएको काउन्टर भन्नाले इन्टरफेस नष्ट भई पुनः बनाइयो; काउन्टर नबदली पियर हराएको भन्नाले कसैले तपाईंको खुट्टामुनिको कन्फिगरेसन सम्पादन गर्यो।

इन्टरफेसको मालिक को हो?

WireGuard आफैंसँग कुनै डेमन वा कन्फिगरेसन फाइल छैन। यसको माथिको केही चीजले बुटको समयमा wg बोलाउँछ, र त्यही चीज सत्यको स्रोत हो। सामान्य उम्मेदवारहरू [email protected], NetworkManager जडान प्रोफाइल, वितरण-विशेष नेटवर्क युनिट, वा आफ्नै डाटाबेस लेख्ने व्यवस्थापन प्यानल हुन्।

आफ्नो वितरणको कागजातलाई होइन, सिस्टमलाई सोध्नुहोस्। systemctl status wg-quick@wg0 र nmcli connection show ले सामान्यतया प्रत्येक एक आदेशले यो टुंग्याउँछन्। यदि दुवैले इन्टरफेसको दाबी गर्छन् भने केही पनि सम्पादन गर्नुअघि नै तपाईंले बग भेट्टाउनुभयो: दुई मालिकले प्रत्येक सुरुमा एउटै यन्त्र पुनः लेख्छन्, र अन्तिममा चल्ने जित्छ।

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

रनटाइम अवस्था र स्टार्टअप अवस्था एउटै फाइल होइन

wg set जीवित यन्त्रलाई netlink मार्फत हेराइ गर्छ। यसले /etc/wireguard/wg0.conf, NetworkManager प्रोफाइल वा प्यानलको डाटाबेस लेख्दैन। पछिको सफल wg show ले कर्नेलले पियर स्वीकार गर्यो भनी प्रमाणित गर्छ, केहीले यसलाई पुनःस्थापित गर्छ भनी होइन।

विपरीत दिशामा दोस्रो जाल पनि छ। इन्टरफेस तल झार्दा wg-quick को SaveConfig विकल्पले हालको इन्टरफेस अवस्था कन्फिगरेसन फाइलमा फर्काएर लेख्छ। त्यो सक्रिय हुँदा इन्टरफेस माथि रहेका बेला फाइलमा गरिएको सम्पादन अर्को बन्द हुँदा मेटिन सक्छ, र त्यो लाइन त्यहीँ थियो भनी तपाईं शपथ खानुहुनेछ। यदि पियर बारम्बार फर्किरहन्छ भने फाइल रोकेपछि पढ्नुहोस्, अघि होइन।

NetworkManager फेरि फरक व्यवहार गर्छ: प्रोफाइल उसको हो र सक्रिय गर्दा लागू गर्छ, त्यसैले सक्रिय NetworkManager जडानको छेउमा हातले सम्पादित .conf केवल सजावट हो। इन्टरफेसका लागि एउटै मालिक छान्नुहोस् र अर्को म्यानेजरलाई यसलाई छुन नदिनुहोस्।

सम्पादन दुवै ठाउँमा पुगोस् भनी सुनिश्चित गर्नुहोस्

पहिले स्थायी अवस्था सम्पादन गर्नुहोस्, त्यसपछि मालिकलाई त्यो लागू गर्न दिनुहोस्, र अन्तमा जीवित अवस्था जाँच्नुहोस्। यो क्रम भन्नाले कुनै पनि चरणको असफलता तीन होइन, एउटा कुरामा संकेत गर्छ।

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf जीवित कन्फिगरेसनलाई फाइलले प्रयोग गर्ने त्यही सिन्ट्याक्समा छाप्छ, जसले दुवैलाई सिधै तुलना गर्न मिल्ने बनाउँछ। त्यो आउटपुटलाई गोप्य ठान्नुहोस्: यसमा निजी कुञ्जीहरू छन्, त्यसैले यसलाई टिकट वा च्याट च्यानलमा टाँस्नुहोस् न। पियरका सार्वजनिक कुञ्जी र अनुमति दिइएका IP तुलना गर्नुहोस्, र जानाजान हटाइएको पियर फर्किएको छैन भनी जाँच्नुहोस्।

त्यो जीवनचक्र घटनाबाट बाँच्छ भनी प्रमाणित गर्नुहोस्

मालिकमार्फत दोस्रो पटक रिस्टार्ट गर्नुहोस्, त्यसपछि तीन छुट्टै कुरा पुष्टि गर्नुहोस्: पियर wg show मा देखिन्छ, ट्राफिकपछि ह्यान्डसेक काउन्टर बढ्छ, र टनेलमा निर्भर अनुप्रयोगले साँच्चै जवाफ दिन्छ। पुरानो ह्यान्डसेकसहित सूचीबद्ध पियर राउटिङ वा कुञ्जीको समस्या हो, स्थायित्वको समस्या होइन, र यो भिन्नताले एउटा निष्प्रयोजन कन्फिगरेसन सम्पादन बचाउँछ।

अन्तमा, रिस्टार्टले के पुनःस्थापित गर्यो भनी जाँच्नुहोस्। जानाजान हटाइएको पियरलाई फेरि जीवित बनाउने रिस्टार्ट त्यही बग विपरीत चिन्हसहित हो, र सामान्यतया यसको अर्थ कन्फिगरेसनको पुरानो प्रतिलिपि अझै कतैबाट लोड भइरहेको छ। मालिक, फाइलको बाटो, पियरको सार्वजनिक कुञ्जी र प्रमाणीकरण आदेशहरू कन्फिगरेसनको छेउमा लेख्नुहोस्, ताकि अर्को व्यक्तिले प्रोडक्सन होस्ट रिस्टार्ट गरेर यो फेरि नभेट्टाओस्।