VPN के लिए Linux नेटवर्क नेमस्पेस: ये क्या अलग नहीं करते

VPN को उसके अपने नेमस्पेस के अंदर शुरू करें, वहाँ एक एप्लिकेशन चलाएँ, और ट्रैफ़िक फिर भी होस्ट रूट से बाहर जाता है। कुछ भी टूटा नहीं है: नेमस्पेस केवल उन प्रक्रियाओं को नियंत्रित करता है जो उसमें प्रवेश करती हैं, और लीक उस प्रक्रिया से आया जो कभी प्रवेश नहीं कर पाई। इंटरफ़ेस, पते, रूट, फ़ायरवॉल नियम और सॉकेट वही हैं जिनका नेमस्पेस मालिक है। फ़ाइलें, खाते और पहले से चल रही सेवाएँ नहीं हैं, और यहीं से ज़्यादातर आश्चर्य आते हैं।

नेमस्पेस किसका मालिक है, और सॉकेट कहाँ जन्म लेता है

किसी इंटरफ़ेस को नेमस्पेस में ले जाएँ और होस्ट उसे खो देता है; अंदर सुरंग बनाएँ और होस्ट उसे देख नहीं सकता। यही नेमस्पेस-सीमित VPN का तंत्र है: डिवाइस और उसकी ओर इशारा करने वाले रूट ऐसे संदर्भ में रहते हैं जहाँ केवल चुनी हुई प्रक्रियाएँ ही पहुँच सकती हैं। होस्ट अपना डिफ़ॉल्ट रूट रखता है, इसलिए बाहर का सब कुछ अछूता रहता है।

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

नेमस्पेस क्या अलग नहीं करता

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

समाधान /etc/netns/<name>/resolv.conf पर प्रति-नेमस्पेस फ़ाइल है, या तैयार फ़ाइल का bind mount, जो अंदर से पहुँचने योग्य रिज़ॉल्वर की ओर इशारा करता है। होस्ट पर /etc/resolv.conf संपादित करने से नेमस्पेस जो देखता है उसमें कुछ नहीं बदलता।

प्रक्रियाओं की नियुक्ति ही नियंत्रण है

आपको जो अलगाव मिलता है वह ठीक उन प्रक्रियाओं का अलगाव है जिन्हें आप अंदर शुरू करते हैं। नेमस्पेस के exec सहायक से शुरू हुआ शेल, और वह जो कुछ भी उत्पन्न करता है, अंदर ही रहता है; होस्ट सत्र से शुरू किया गया डेस्कटॉप एप्लिकेशन नहीं। संदर्भ बनाएँ, डिवाइस ले जाएँ, और फिर दोनों पक्ष सिद्ध करें:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

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

एप्लिकेशन के संदर्भ से परखें

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

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

फ़ॉरवर्डिंग, विफलता नीति और सफ़ाई

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

नेमस्पेस के नाम, इंटरफ़ेस और कॉन्फ़िगरेशन का मालिक कौन है, यह दर्ज करें, ताकि सफ़ाई केवल वही हटाए जो परिनियोजन ने बनाया। रोलबैक के दौरान होस्ट नेटवर्किंग रीसेट करना सफ़ाई को व्यवधान में बदल देता है। पृष्ठ network_namespaces(7) छोटा है और उस रास्ते को डिज़ाइन करने से पहले पढ़ने योग्य है।