VPN नेमस्पेस के अंदर का ऐप LAN से पहुँच से बाहर है

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

LAN पते पर कोई जवाब क्यों नहीं देता

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

इसीलिए होस्ट पर curl विफल होता है जबकि नेमस्पेस के अंदर वही कमांड सफल होती है। ऐप्लिकेशन स्वस्थ है; पता बस होस्ट के स्टैक में मौजूद नहीं है।

socat हॉप से एक पोर्ट प्रकाशित करें

socat उपयोगकर्ता-स्पेस में दोनों स्टैक को जोड़ता है, जो तब काफ़ी है जब एक ही TCP पोर्ट को पार जाना हो। होस्ट की ओर LAN पर सुनती है और हर स्वीकृत कनेक्शन के लिए नेमस्पेस के अंदर दूसरा socat शुरू करती है जो ऐप के लूपबैक से जुड़ता है। अंदर की प्रक्रिया ऐप्लिकेशन तक ठीक वैसे ही पहुँचती है जैसे कोई स्थानीय क्लाइंट पहुँचता। नेमस्पेस के रूटिंग में कुछ नहीं बदलता, इसलिए ऐप टनल को अपना इकलौता निकास इस्तेमाल करता रहता है।

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

बाहरी प्रक्रिया को root या नेमस्पेस में घुसने की क्षमता चाहिए। अगर VPN गिर जाए, तो ऐप अपना रास्ता खो देता है और प्रकाशित पोर्ट बंद होकर विफल हो जाता है, और जेल से आपको यही व्यवहार चाहिए।

एक से ज़्यादा पोर्ट पार हों तो veth जोड़ी इस्तेमाल करें

जब कई पोर्ट या प्रोटोकॉल पार होने हों, या दूसरे होस्ट को कनेक्शन शुरू करने हों, तब veth जोड़ी सही जवाब है। एक सिरा होस्ट में रहता है, दूसरा नेमस्पेस में जाता है, और छोटा /30 दोनों तरफ़ को स्थिर पता देता है। फिर होस्ट रूट जोड़ी के ऊपर से नेमस्पेस का पता भेजता है।

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

जेल तोड़ने का इरादा न हो तो होस्ट के रास्ते डिफ़ॉल्ट रूट न जोड़ें। टनल ही निकास रहना चाहिए, इसलिए जोड़ी के ऊपर से सिर्फ़ प्रकाशित सेवा पते तक पहुँचा जा सकता है। नेमस्पेस को उसकी अपनी रिज़ॉल्वर फ़ाइल भी दें, क्योंकि ip netns exec /etc/netns/vpn/resolv.conf पढ़ता है और उसके बिना जेल के अंदर नाम हल करना खाली रहता है।

होस्ट से नहीं, दूसरी मशीन से परखें

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

ip netns exec vpn ss -lntp

अगर होस्ट का कनेक्शन काम करता है और LAN का नहीं, तो गायब हिस्सा हॉप या रूट है, बँधने का पता नहीं। चालू tun डिवाइस को अंदर ले जाने के बजाय नेमस्पेस के अंदर OpenVPN शुरू करें, क्योंकि इंटरफ़ेस को हिलाने से वह बंद हो जाता है और ऐसे रूट मिट सकते हैं जिन्हें फिर आप बाहर से ठीक नहीं कर सकेंगे। रिकवरी कमांड जेल के अंदर नहीं, कंसोल पर रखें।