WireGuard सुरंग के बाहर एक Linux प्रक्रिया कैसे चलाएँ

आप रूट संपादित करके किसी प्रोग्राम को पूर्ण-सुरंग वाले WireGuard होस्ट से छूट नहीं दे सकते। रूट गंतव्य के अनुसार मार्ग चुनते हैं, और आप जिसे छूट देना चाहते हैं वह एक प्रक्रिया है, इसलिए कर्नेल के पास मिलाने के लिए कुछ नहीं है। व्यावहारिक तरीका यह है कि उस प्रक्रिया को उसका अपना नेटवर्क संदर्भ दिया जाए: अपने इंटरफ़ेस, पते और डिफ़ॉल्ट रूट वाला एक नेमस्पेस, जो veth जोड़ी से होस्ट से जुड़ा हो। मैंने इसे Ubuntu 24.04 पर wireguard-tools 1.0.20210914 के साथ चलाया, और नेमस्पेस कभी समस्या नहीं था — होस्ट की फ़ॉरवर्डिंग नीति और सुरंग के मार्किंग नियम समस्या थे।

पहले वह प्रकार का संदर्भ चुनें जिसकी आपको आवश्यकता है

व्यवहार में दो रूप दिखते हैं। अगर होस्ट पूर्ण सुरंग चलाता है और एक प्रोग्राम को ISP के रास्ते बाहर निकलना है, तो आप दूसरा नेमस्पेस बनाते हैं, उसे होस्ट से जोड़ते हैं और होस्ट को उसके लिए ट्रैफ़िक फ़ॉरवर्ड और अनुवाद करने देते हैं। अगर किसी नेमस्पेस में पहले से VPN इंटरफ़ेस है और आपको केवल उसके अंदर शुरू होने वाला कमांड चाहिए, तो यह सामान्य ip netns exec मामला है और रूटिंग का अधिकांश काम पहले ही हो चुका है।

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

अगर आवश्यकता वास्तव में यह है कि सुरंग से कुछ भी बाहर न जाए, तो इसके बजाय सुरंग रोक दें। नेमस्पेस मिश्रित स्थिति के लिए है: एक प्रोग्राम बाहर, बाकी सब अंदर, उसी मशीन पर, उसी समय।

दूसरा संदर्भ बनाएँ और उसे होस्ट से जोड़ें

एक उदाहरणीय व्यवस्था: होस्ट में डिफ़ॉल्ट रूट ले जाने वाला WireGuard इंटरफ़ेस है, और clearnet नाम का नेटवर्क नेमस्पेस है, जो veth जोड़ी से होस्ट से जुड़ा है। नीचे दिए पते उदाहरण हैं।

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

आगे बढ़ने से पहले नेमस्पेस की ओर जाँच लें।ip netns exec clearnet ip route को veth रूट और 192.168.100.1 के माध्यम से डिफ़ॉल्ट रूट दिखाना चाहिए, और उस पते पर ping का उत्तर आना चाहिए। अगर होस्ट के पते पर ping विफल हो, तो पते या लिंक की स्थिति गलत है और कोई फ़ायरवॉल नियम मदद नहीं करेगा।

जब नाम हल हों पर कुछ वापस न आए, तो FORWARD पढ़ें

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

कुछ जोड़ने से पहले श्रृंखला पढ़ें:

iptables -S FORWARD
nft list chain inet filter forward

फिर दोनों दिशाओं में ट्रैफ़िक की अनुमति दें, काउंटरों के साथ, ताकि पता चले कि नियम कभी मेल खाया या नहीं:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

शून्य पैकेट काउंटर वाला नियम रास्ते में नहीं है। या तो इंटरफ़ेस के नाम आपकी धारणा से अलग हैं, या श्रृंखला का कोई पिछला नियम पैकेट को पहले स्वीकार, अस्वीकार या वापस कर चुका है। क्रम ठीक करें, नियम का पाठ नहीं।

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

सुरंग के मार्किंग नियमों को नए रास्ते से दूर रखें

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

दो जोड़ रास्तों को अलग करते हैं। नेमस्पेस सबनेट के लिए mangle श्रृंखला में जल्दी लौटें, और एक स्रोत-आधारित नियम जोड़ें जो उस सबनेट को मुख्य तालिका में रखे:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

मेरे होस्ट पर प्राथमिकता 100 सुरंग के नियमों से पहले आती है, इसलिए उस स्रोत के लिए सामान्य तालिका निर्णय लेती है। संख्या को आँख बंद करके न कॉपी करें: जिन प्राथमिकताओं कोwg-quick स्थापित करता है वे संस्करणों और IPv4 तथा IPv6 सेटअप के बीच अलग होती हैं, इसलिए चलाएँip rule show और ऐसी प्राथमिकता चुनें जो आपकी मशीन पर सुरंग के नियमों से पहले पड़े।

नियम सूची पर भरोसा करने के बजाय स्रोत-विशिष्ट खोज से सत्यापित करें:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

अगर पहला कमांड WireGuard इंटरफ़ेस बताता है, तो नया नियम अभी सुरंग नीति से पहले नहीं है। अगर यह WAN इंटरफ़ेस बताता है जबकि दूसरा अब भी veth डिफ़ॉल्ट दिखाता है, तो होस्ट और नेमस्पेस सहमत नहीं हैं और आपको दोनों रूटिंग तालिकाएँ फिर से पढ़नी चाहिए।

वह प्रक्रिया शुरू करें जो कनेक्शन खोलती है

कमांड शुरू करना एक पंक्ति है, पर वह प्रक्रिया शुरू करें जो वास्तव में सॉकेट बनाती है।ip netns exec clearnet curl -s https://ifconfig.me सबसे छोटा ईमानदार परीक्षण है: यह वह पता दिखाता है जो नेमस्पेस दुनिया को प्रस्तुत करता है, न कि वह जो होस्ट उपयोग करता।

किसी सेवा के लिए, नेमस्पेस को पथ से जोड़ें ताकि प्रक्रिया अपने पूरे जीवनकाल उसमें रहे:

[Service]
NetworkNamespacePath=/run/netns/clearnet

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

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

दोनों आउटपुट मेल खाने चाहिए। वही जाँच किसी भी दीर्घकालिक प्रोग्राम के लिए काम करती है, और लॉन्चर ने वही किया जो आपका इरादा था यह मानने के बजाय हर एप्लिकेशन के लिए एक बार करना उचित है।

नाम हल करने का अपना निर्णय चाहिए। नेमस्पेस बनाने से उसे रिज़ॉल्वर कॉन्फ़िगरेशन नहीं मिलता; प्रति-नेमस्पेस फ़ाइलें इसके माध्यम से समर्थित हैं/etc/netns/<name>/resolv.conf और इसके बिना आप ऐसा व्यवहार विरासत में लेते हैं जिसे गलत पढ़ना आसान है। IPv6 को भी वही व्यवहार चाहिए: अगर नेमस्पेस के पास v6 डिफ़ॉल्ट रूट नहीं है जबकि एप्लिकेशन v6 पसंद करता है, तो अनुरोध पीछे हटने से पहले अटक सकते हैं, जो टूटी सुरंग जैसा दिखता है।

फ़्रेमिंग जाँचें, केवल निकास पता नहीं

काम करता सार्वजनिक पता मार्ग सिद्ध करता है, पूरी आवश्यकता नहीं। बाकी इस क्रम में करें:

• ip netns exec clearnet ip route get 1.1.1.1 veth डिफ़ॉल्ट दिखाता है, WireGuard इंटरफ़ेस नहीं।
• अनुरोध चलते समय दोनों नियमों के FORWARD काउंटर बढ़ते हैं।
• एप्लिकेशन प्रक्रिया आपके अपेक्षित नेमस्पेस inode की सूचना देती है।
• पुनः आरंभ के बाद सेवा शुरू होने से पहले नेमस्पेस मौजूद होता है; जल्दी चलने वाली unit विफल हो जाती है, या और बुरा, नेमस्पेस के बाहर चलती है।

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