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 प्रदाता हे सर्व नेटवर्क नेमस्पेसच्या व्याप्तीबाहेर आहेत, आणि सुटीकडे अनामिकता म्हणून पाहणे ही ती चूक आहे जी संरचनेपेक्षा जास्त जगते।