NetworkManager बनाम wg-quick: आपके WireGuard रूट का मालिक कौन है?
दो मैनेजर एक ही WireGuard लिंक पर दावा कर सकते हैं, और आपने जो कॉन्फ़िग संपादित किया है वह लागू वाला न हो. रूट, नियम और इंटरफ़ेस की स्थिति से मालिक का पता लगाएँ.
आप WireGuard फ़ाइल में AllowedIPs बदलते हैं, टनल को फिर से शुरू करते हैं, और रूटिंग तालिका बिलकुल पहले जैसी दिखती है। आम प्रतिक्रिया है परेशान करने वाले रूट को हटाकर आगे बढ़ना, जो तब तक काम करता है जब तक अगला पुनःकनेक्शन उसे वापस नहीं लगा देता। आपने जो फ़ाइल संपादित की है, ज़रूरी नहीं कि वही ऑब्जेक्ट हो जिसने वह स्थिति बनाई जो आप देख रहे हैं। दो मैनेजर एक ही मशीन पर एक ही प्रोटोकॉल चला सकते हैं, और किसी भी समय इनमें से केवल एक ही इंटरफ़ेस का मालिक होता है।
मिथक: मशीन पर WireGuard का एक ही कॉन्फ़िग है
wg-quick /etc/wireguard/ के अंतर्गत एक फ़ाइल पढ़ता है और जब आप इसे ऊपर लाते हैं तो इंटरफ़ेस बनाता है। NetworkManager अपने ही keyfile प्रारूप में कनेक्शन प्रोफ़ाइल संग्रहीत करता है और सक्रियण पर उसे प्रस्तुत करता है, और wg-quick फ़ाइल आयात करने पर मान उस प्रोफ़ाइल में कॉपी होते हैं, उससे लिंक नहीं होता। बाद में मूल फ़ाइल संपादित करने से कुछ नहीं बदलता, क्योंकि प्रोफ़ाइल अब उसे नहीं पढ़ती। इसलिए साथियों और कुंजियों की वही सूची दो बार मौजूद हो सकती है, दूसरी प्रति लागू रहते हुए।
याद रखने योग्य संकेत: जो बदलाव रीबूट के बाद बचे रहते हैं पर पुनः आयात के बाद नहीं, वे एक भंडार से आते हैं, और जो बदलाव रीबूट पर गायब हो जाते हैं वे दूसरे से आते हैं।
एक व्यावहारिक उदाहरण विभाजन स्पष्ट करता है। तुलना करें nmcli connection show के साथ systemctl status wg-quick@wg0, फिर जाँचें कि रूट वास्तव में किस इंटरफ़ेस पर टिके हैं। अगर सेवा मृत है और इंटरफ़ेस ऊपर है, तो फ़ाइल जो भी कहे, काम प्रोफ़ाइल ही कर रही है।
मिथक: रूटिंग नियम WireGuard का हिस्सा हैं
कर्नेल का WireGuard डिवाइस साथियों और कुंजियों को जानता है, और नीति-आधारित रूटिंग के बारे में कुछ नहीं जानता। आप जो ip rule प्रविष्टियाँ और अतिरिक्त तालिकाएँ देखते हैं, उन्हें उसी टूल ने इंस्टॉल किया जिसने इंटरफ़ेस ऊपर उठाया। wg-quick एक fwmark और एक समर्पित तालिका तथा उसकी ओर इशारा करने वाले नियम जोड़ सकता है, जबकि NetworkManager अपनी ही ipv4 सेटिंग्स के ज़रिए रूट इंस्टॉल करता है और DNS को सिस्टम के उपयोग होने वाले रिज़ॉल्वर बैकएंड पर छोड़ देता है। वही टनल, अलग दुष्प्रभाव।
कुछ भी बदलने से पहले ip rule और ip route show table all पढ़ें, और नोट करें कि हर रूट किस तालिका में रहता है। जो तालिका संख्या आपने कॉन्फ़िगर नहीं की, वह उसे बनाने वाले टूल के बारे में मज़बूत संकेत है।
मिथक: रूट हटाना एक समाधान है
रनटाइम में हटाया गया रूट वह रूट है जिसे मालिक अगले सक्रियण पर फिर से इंस्टॉल करेगा, और सक्रियण आपके बिना भी हो सकता है: लैपटॉप का जागना, लिंक का फ्लैप होना, सेवा का पुनः आरंभ या NetworkManager का ऑटोकनेक्ट। इसीलिए वही रूट लौटता है और इसीलिए वह कामचलाऊ उपाय गलत नहीं, बल्कि अविश्वसनीय लगता है। पहले मैनेजर पहचानें, फिर वह इनपुट बदलें जो वह मैनेजर वास्तव में पढ़ता है।
फिर से कनेक्ट करना और संबंधित सेवा को पुनः आरंभ करना ही वह परीक्षा है जो असली समाधान को साफ़-सुथरे दिखने वाले समाधान से अलग करती है।
एक मालिक चुनें और दूसरे को हटा दें
वह मैनेजर चुनें जिसे आपका परिनियोजन समर्थित करता है, फिर प्रतिस्पर्धी सक्रियण को उसके प्रलेखित नियंत्रण से अक्षम करें, बजाय इसके कि आप उम्मीद करें कि वह निष्क्रिय रहेगा। मास्क किया गया wg-quick सेवा या हटाई गई NetworkManager प्रोफ़ाइल स्पष्ट है; दोनों को सक्षम छोड़कर उन्हें दौड़ कराना नहीं। कुछ भी अक्षम करने से पहले काम करने वाली पहुँच बनाए रखें, क्योंकि आपका रिमोट सत्र ले जाने वाला इंटरफ़ेस वही हो सकता है जिसे आप हटाने वाले हैं।
बदलाव के बाद, शामिल और बहिष्कृत ट्रैफ़िक, फिर DNS, फिर एक बार रीबूट करके सत्यापित करें। यदि एक ही मैनेजर के साथ स्थिति रीबूट के बाद बनी रहती है, तो आपके पास संयोग नहीं, बल्कि एक मालिक है।
सामान्य नियम WireGuard से आगे भी याद रखने योग्य है: जब कोई सेटिंग बार-बार लौटती रहे, तो परिणाम को हटाना बंद करें और उस प्रक्रिया को खोजें जो उसे लगातार पैदा कर रही है।