नेटवर्क नेमस्पेस में WireGuard: सॉकेट पीछे क्यों रह गया

इंटरफ़ेस उसी नेमस्पेस में सूचीबद्ध है जो आप चाहते थे, ऐप्लिकेशन उससे बँधा है, और फिर भी कोई टनल ट्रैफ़िक कभी नहीं दिखता। यह Linux कर्नेल के उस WireGuard डिवाइस की पहचान है जो एक नेमस्पेस में बना और दूसरे में ले जाया गया: इंटरफ़ेस चला गया और उसका एन्क्रिप्टेड UDP सॉकेट नहीं गया। अंदरूनी ट्रैफ़िक का महत्व होने से पहले दोनों को सही जगह पर होना चाहिए। जाँच तेज़ है, बस यह जानना ज़रूरी है कि एक नहीं, दो संदर्भों को देखना है।

लक्षण: सही नेमस्पेस, पर पैकेट नहीं

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

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

यह स्थानांतरण में कोई गड़बड़ी नहीं है और पीयर का गलत कॉन्फ़िगरेशन भी नहीं है। कर्नेल कार्यान्वयन ऐसा ही करता है, और WireGuard के नेमस्पेस दस्तावेज़ निर्माण का नियम सीधे बताते हैं।

सॉकेट का जन्मस्थान क्यों है

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

परिणाम चूकना आसान है क्योंकि दोनों आधे हिस्से अलग-अलग जगहों पर जाँचे जाते हैं। अंदरूनी मार्ग उस नेमस्पेस में तय होता है जहाँ ऐप्लिकेशन चलता है, और बाहरी मार्ग वहाँ तय होता है जहाँ सॉकेट रहता है। इनमें से केवल एक जाँचने पर आत्मविश्वासी पर ग़लत निष्कर्ष निकलता है। दोनों जाँचने पर जाँच आम तौर पर एक ही दौर में पूरी हो जाती है।

इसे वहीं बनाइए जहाँ आप सॉकेट चाहते हैं

समाधान यह है कि डिवाइस को बाहर बनाकर स्थानांतरित करने के बजाय लक्ष्य नेमस्पेस के अंदर बनाइए। यह मानते हुए कि स्वीकृत नेमस्पेस पहले से है और नाम अप्रयुक्त है:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

मार्ग के दोनों पक्ष पढ़िए

डिवाइस सही जगह आने पर दोनों निर्णय अलग-अलग सत्यापित करें। ऐप्लिकेशन के संदर्भ से अंदरूनी खोज से शुरू करें, फिर सॉकेट का मालिक संदर्भ से बाहरी मार्ग जाँचें:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

अगर अंदरूनी खोज टनल से हल होती है और बाहरी कैप्चर एन्क्रिप्टेड आदान-प्रदान दिखाता है, तो दोनों आधे सहमत हैं। अगर कैप्चर खाली है, तो सॉकेट अभी कहीं और है, या उसके नेमस्पेस का अंडरले मार्ग अंतिम बिंदु तक नहीं पहुँचता।

एक और जाँच रिकॉर्ड में होनी चाहिए: रीस्टार्ट के बाद डिवाइस कैसे बनता है। जो मैनेजर अलग निर्माण संदर्भ के साथ इंटरफ़ेस फिर बनाता है, वह सॉकेट का जन्मस्थान बदल देता है। एक बार काम कर गया मैन्युअल स्थानांतरण प्रबंधित मार्ग के बारे में प्रमाण नहीं है।