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

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