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 प्रदायक सबै नेटवर्क नेमस्पेसको दायराबाहिर छन्, र छुटलाई अज्ञातताका रूपमा हेर्नु त्यो गल्ती हो जो कन्फिगरेसनभन्दा लामो बाँच्छ।