WireGuard AllowedIPs: वह रूट जो NetworkManager ने कभी नहीं जोड़ा
एक मान्य WireGuard प्रोफ़ाइल हैंडशेक पूरा करके भी कुछ नहीं भेज सकता। कर्नेल तालिका की AllowedIPs से तुलना करें, फिर रूट पथ को एक मालिक दें।
हैंडशेक काउंटर अपडेट होता है, इंटरफ़ेस अपना पता बनाए रखता है, और दूसरी तरफ़ जाता ping कहीं नहीं पहुँचता। यह संयोजन लोगों को उलझाता है, क्योंकि काम करता हैंडशेक ऐसा प्रमाण लगता है कि टनल तैयार है। ऐसा नहीं है: टनल पूरी तरह वार्ता-पूर्ण हो सकता है और फिर भी उसमें ट्रैफ़िक भेजने वाला कोई रूट न हो, और ये दो अलग काम हैं जो दो अलग स्थिति-टुकड़े करते हैं। सुधार पूरी तरह इस पर निर्भर है कि दोनों में से कौन गायब है, इसलिए पहला कदम वही पता लगाना है।
wg-quick दोनों काम बिना माँगे करता है। NetworkManager का अंतर्निहित WireGuard समर्थन भी डिफ़ॉल्ट रूप से peer रूट स्थापित करता है, जो संदिग्धों को बंद विकल्प, दूसरी रूटिंग तालिका या किसी और माध्यम से आयात की गई कॉन्फ़िगरेशन तक सीमित कर देता है।
रूट के पीछे भागने से पहले टनल की पुष्टि करें
wg show इंटरफ़ेस, peer, अंतिम बिंदु और नवीनतम हैंडशेक की आयु छापता है, और ip addr show पुष्टि करता है कि पता मौजूद है। हाल का हैंडशेक अर्थ है कि कुंजियाँ, अंतिम बिंदु और UDP पथ काम कर रहे हैं। जो भी टूटा है वह उनके नीचे बैठता है: रूटिंग, फ़िल्टरिंग या नाम विभेदन।
फिर कर्नेल से पूछें कि वह काल्पनिक के बजाय वास्तविक गंतव्य के साथ क्या करेगा: ip route get 10.42.7.9। उत्तर बाहर जाने वाला इंटरफ़ेस और वह स्रोत पता बताता है जो पैकेट ले जाएगा। जब वह भौतिक अडैप्टर बताता है, तो पैकेट कभी टनल में प्रवेश नहीं करता, हैंडशेक कितना भी स्वस्थ लगे।
AllowedIPs एक फ़िल्टर और एक रूट सूची है
AllowedIPs के उपसर्ग दो काम करते हैं। वे चुनते हैं कि कौन peer बाहर जाता गंतव्य ले जाएगा, और वे आने वाले पैकेट के स्रोत पते की जाँच करते हैं, जो क्रिप्टोकुंजी रूटिंग की सीमा है। wg-quick में वे स्वचालित रूट स्थापना भी चलाते हैं, और यही अतिरिक्त व्यवहार वह कारण है कि वही कॉन्फ़िगरेशन टर्मिनल से काम करता है और डेस्कटॉप क्लाइंट से नहीं।
इस लेख के पीछे के मामले में प्रोफ़ाइल अंतर्निहित समर्थन के बजाय किसी तीसरे पक्ष के प्लगइन से आयात हुई थी, और इंटरफ़ेस उपसर्ग रूट के बिना ऊपर आया। तालिका की सूची तुरंत दिखा देती है: ip route show में केवल इंटरफ़ेस पते का जुड़ा रूट है, दूर के रेंज के लिए कुछ नहीं।
पूछें कि peer रूट बिल्कुल सक्षम हैं या नहीं
कुछ भी बदलने से पहले सेटिंग पढ़ें: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg। जब peer-routes no दिखाता है, तो समर्थित सुधार nmcli connection modify work-wg wireguard.peer-routes yes है, और उसके बाद फिर से कनेक्ट करना। इसके बजाय स्थिर रूट जोड़ना अगली सक्रियता तक काम करता है और फिर चुपचाप गायब हो जाता है। वही गायब होना संकेत है: हर सुबह पहेली की तरह लौटने वाला रूट प्रोफ़ाइल स्थापित नहीं करती।
अगर विकल्प पहले से सक्षम है, तो ip route show table all | grep 10 से जाँचें कि उपसर्ग किसी दूसरी तालिका में रहता है या नहीं। जो तालिका मुख्य नहीं है उसका रूट गायब नहीं है, वह केवल ऐसी खोज के लिए अदृश्य है जो केवल मुख्य तालिका देखती है। ऊपर नकली प्रविष्टि ढेर करने के बजाय नीति रूटिंग सुधारें।
उपसर्ग को चल रहे सिस्टम में नहीं, कनेक्शन में जोड़ें
कनेक्शन संपादक में WireGuard पृष्ठ peer और उसकी AllowedIPs रखता है, और IPv4 पृष्ठ अतिरिक्त रूट रखता है। वहाँ जोड़ा रूट फिर से कनेक्ट होने पर भी टिकता है क्योंकि वह प्रोफ़ाइल का हिस्सा है। कमांड लाइन पर समतुल्य है खाली-गेटवे रूप में कनेक्शन में रूट जोड़ना, फिर बदलाव लागू होने के लिए कनेक्शन को नीचे और ऊपर करना।
आपको ज़रूरी होस्टों को ढकने वाला सबसे संकरा उपसर्ग चुनें। प्रदाता का उदाहरण /8 कॉपी करने से उसके भीतर आने वाले स्थानीय रेंज निगल सकते हैं, और परिणामी विफलताएँ ज़्यादा चौड़े रूट के बजाय टूटी टनल जैसी दिखती हैं।
विभाजित टनलिंग उपसर्ग सूची से तय होती है
विभाजित टनल के लिए कोई स्विच नहीं है; उपसर्ग सूची ही निर्णय है। ऑफ़िस LAN के लिए एक रेंज और लैब नेटवर्क के लिए एक रेंज रखने वाला peer ठीक वही गंतव्य टनल से भेजता है और बाकी सबको अकेला छोड़ देता है। एक अकेले होस्ट को /32 चाहिए, और दो जगहों पर अतिव्यापी रेंजों को होस्ट उपसर्ग चाहिए जब तक कोई सबनेट का फिर से क्रमांकन न करे।
टनल से कुछ न भेजने का चुनाव उसी निर्णय को उसकी सीमा तक ले जाता है: न्यूनतम सूची लिंक को ऊपर रखती है जबकि सामान्य ट्रैफ़िक अपने सामान्य पथ पर चलता रहता है। मंशा लिख लें, वरना अगला पाठक छोटी सूची को चूक मानकर सहायतापूर्वक उसे बढ़ा देगा।
रूट तालिका के लिए एक मालिक
wg-quick और NetworkManager दोनों मानते हैं कि इंटरफ़ेस के रूट उनके हैं। wg-quick के लिए लिखी कॉन्फ़िगरेशन आयात करें और फिर wg-quick सेवा भी शुरू करें, तो आपको नकली या परस्पर विरोधी प्रविष्टियाँ मिलेंगी जिनका व्यवहार इस पर निर्भर है कि कौन अंत में चला। एक मालिक चुनें और दूसरे को हटाएँ: अगर NetworkManager कनेक्शन संभालता है, तो उस इंटरफ़ेस के लिए wg-quick यूनिट बंद करें, और उसी डिवाइस के लिए कभी दूसरी प्रोफ़ाइल न जोड़ें।
जब विभाजन को गंतव्य के बजाय भौतिक अडैप्टर का अनुसरण करना हो, तो आप नीति रूटिंग में आ गए हैं, और नीति रूटिंग को भी एक ही लेखक चाहिए। ip route get को दोहराकर जाँचें, फिर दूर के उपसर्ग के भीतर के होस्ट तक ऐसी चीज़ से पहुँचें जो उसका चुना स्रोत पता छापे। अगर प्रोफ़ाइल में हो तो IPv6 और DNS अलग से जाँचें।