एका Pi वर hostapd आणि OpenVPN: डीफॉल्ट रूट कोणाचा?

फोन ॲक्सेस पॉइंटशी जोडले जातात, पत्ता मिळवतात आणि नंतर टनेल वर आल्यावर काहीही गाठत नाहीत. त्या स्थितीत hostapd सहसा निरोगी असते, आणि OpenVPN देखील; तुटते ते डीफॉल्ट रूट, जे एकतर ब्रिजवर कधीच नव्हते किंवा टनेलने VPN सर्व्हरपर्यंतचा मार्ग न सोडता ते बदलले. हे मार्गदर्शक तो रूट त्याच्या जागी परत आणते आणि निकाल Pi वरून नव्हे तर क्लायंटवरून सिद्ध करते. प्रत्येक पायरी उलटवता येते, आणि येथे काहीही टनेलचे कॉन्फिगरेशन बदलत नाही, तुम्हाला त्यात कोणती रहदारी हवी आहे हे कळेपर्यंत.

काहीही संपादित करण्यापूर्वी इंटरफेसची यादी करा

नेहमीची रचना वायरलेस रेडिओ आणि वायर्ड पोर्ट br0 मध्ये ठेवते, ब्रिजविरुद्ध hostapd सुरू करते आणि dnsmasq मधून भाडेपट्टे वाटते, तर OpenVPN क्लायंट tun0 तयार करतो. मग तीन वेगळ्या गरजा एकासारख्या दिसतात: ॲक्सेस पॉइंट क्लायंटना त्यांचा गेटवे म्हणून Pi हवा, Pi ला त्याच्या सर्व्हरपर्यंत पोहोचण्यासाठी इंटरनेटवर रूट हवा, आणि ब्रिजला ते क्लायंट वापरू शकतील असा गेटवे पत्ता हवा.

बदलण्यापूर्वी सध्याची स्थिती वाचा, कारण या चार कमांड इंटरफेसची समस्या राउटिंगच्या समस्येपासून वेगळी करतात.

ip -br addr
ip route show
ip link show master br0
bridge link show

जर br0 कडे पत्ता असेल पण डीफॉल्ट रूट नसेल, तर क्लायंट Pi पर्यंत पोहोचतात आणि त्यापुढे काहीही नाही. जर टनेल खाली असताना डीफॉल्ट रूट tun0 कडे निर्देश करत असेल, तर Pi कडे कार्यरत मार्गच नाही, आणि क्लायंटचे लक्षण अगदी तसेच दिसते. दोन्ही प्रकरणे फोनवरून सारखीच दिसतात, म्हणून रूट टेबल थेट वाचावे लागते.

ब्रिजला त्याचा स्वतःचा डीफॉल्ट रूट द्या

Raspberry Pi OS इंटरफेस फाइल लिहिल्यानंतर ब्रिज तयार झाला असेल तेव्हा ब्रिजला डीफॉल्ट रूटशिवाय ठेवते. ब्लॉक /etc/dhcpcd.conf मध्ये असावा, आणि त्याने Pi नव्हे तर वरच्या राउटरचे नाव घ्यावे.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

त्या उदाहरणात 192.168.50.1 हा विद्यमान राउटर आहे आणि 192.168.50.2 हा त्याच सबनेटमधील Pi चा ब्रिज पत्ता आहे, म्हणून संख्या कॉपी करण्याऐवजी तुमची स्वतःची योजना वापरा. ब्रिजच्या सदस्यांनीही राउटर मागू नयेत, अन्यथा Pi कडे स्पर्धा करणारे डीफॉल्ट राहतात, ज्यांचा विजेता हेतूनुसार नव्हे तर मेट्रिक आणि वेळेनुसार ठरतो.

systemctl restart dhcpcd नंतर ip route show default ने br0 एकदाच दाखवावे आणि वायर्ड पोर्टवरून डुप्लिकेट नसावे. टेबल नव्हे तर शोधाची खात्री करा, कारण जुनी नोंद विजेत्या नोंदीच्या शेजारी बसू शकते: ip -4 route get 203.0.113.10 ने br0 चे नाव घ्यावे. तो पत्ता TEST-NET-3 दस्तऐवजीकरण श्रेणीतून येतो, म्हणून हे वाचत असताना तो खऱ्या सर्व्हरशी टकरू शकत नाही.

टनेलला त्याच्या स्वतःच्या सर्व्हरचा मार्ग चोरण्यापासून थांबवा

redirect-gateway स्वीकारणारा OpenVPN क्लायंट डीफॉल्ट रूट ताब्यात घेतो आणि तो टनेलमध्ये नेतो. प्रत्येक ॲक्सेस पॉइंट क्लायंटने VPN वापरायला हवा तेव्हा हे बरोबर आहे, आणि फक्त काही गंतव्यांनी वापरायला हवा तेव्हा चूक आहे. कोणत्याही परिस्थितीत, Pi चे सर्व्हरशी स्वतःचे कनेक्शन तो अजून बांधत असलेल्या टनेलच्या आतून जाऊ नये. OpenVPN डीफॉल्ट पुनर्निर्देशित करताना मूळ गेटवेमार्गे दूरच्या बाजूला होस्ट रूट जोडतो, आणि हेच ते वर्तन जे वाहतूक जिवंत ठेवते; तो मार्ग नसेल तर टनेल स्थिर होताच कोसळते.

जोडण्यापूर्वी आणि नंतर त्या वाहतूक मार्गाची झटपट तुलना त्या दहा सेकंदांना योग्य आहे. ip -4 route get 203.0.113.10 ने दोन्ही अवस्थांमध्ये अंतर्निहित उपकरणाचे नाव घ्यावे, फक्त मेट्रिक बदलते. टनेल वर आल्यावर त्याने tun0 चे नाव घेतल्यास होस्ट रूट कधीच स्थापित झाला नाही आणि पुढील पुन्हा जोडणी अयशस्वी होईल.

फक्त निवडक प्रीफिक्स टनेल ओलांडायला हवेत तेव्हा route-nopull वापरा आणि हवे ते रूट हाताने जोडा, किंवा सर्व्हरवरून अरुंद संच पाठवा. त्या रचनेत ब्रिज डीफॉल्ट रूट ठेवतो, आणि DNS पुढील निर्णय बनते: dnsmasq ला घरगुती रिझॉल्व्हरकडे फॉरवर्ड करणे फक्त तिथे खरोखर राहणाऱ्या नावांसाठी अर्थपूर्ण आहे.

फॉरवर्डिंग आणि NAT चा निर्णय घ्या

पूर्ण टनेलसाठी Pi वर फॉरवर्डिंग सक्षम असणे आणि ॲक्सेस पॉइंट सबनेट राउट करण्यास तयार असलेला पलीकडचा गेटवे आवश्यक आहे. इतर कशापेक्षाही आधी फॉरवर्डिंग तपासा, कारण शून्य प्रत्येक रूट बदल निरर्थक करते.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT नियम हा तो शॉर्टकट आहे जो सर्व्हरने ॲक्सेस पॉइंट प्रीफिक्स स्वीकारला नाही तेव्हा काम करतो, पण त्याची किंमत म्हणजे पलीकडच्या लॉगमध्ये प्रत्येक क्लायंट Pi चा टनेल पत्ता म्हणून दिसेल. NAT शिवाय प्रीफिक्स राउट केल्यास पत्ते दृश्यमान राहतात आणि घरच्या बाजूला 192.168.50.0/24 साठी परतीच्या रूटवर अवलंबून असते.

फायरवॉल नियमांच्या शेजारी निवड लिहून ठेवा, कारण रचनेत अदृश्य NAT नियम सहा महिन्यांनंतर अस्पष्ट होतो. IPv6 त्याच निर्णयात ठेवा; तुटलेल्या IPv6 मार्गाच्या शेजारी कार्यरत IPv4 मार्ग ब्राउझरमध्ये तरीही अर्धा तुटलेला वाचला जातो.

क्लायंटवरून पडताळा, नंतर स्वच्छ रोलबॅक करा

ॲक्सेस पॉइंटवरील फोन किंवा लॅपटॉपवरून या क्रमाने चाचणी करा: dnsmasq कडून भाडेपट्टा, ब्रिज पत्त्यावर ping, नंतर टनेलच्या पलीकडील गंतव्य. प्रत्येक पायरी एक स्तर वेगळा करते, एकच निरुपयोगी अपयश निर्माण करण्याऐवजी.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

नंतर Pi कडे अजूनही स्वतःचा बाहेर जाण्याचा मार्ग आहे याची खात्री करा: ip route get 203.0.113.10 ने अंतर्निहित उपकरणाचे नाव घ्यावे, आणि सर्व्हरने ICMP परवानगी दिल्यास ping -c 3 -I br0 203.0.113.10 ने उत्तर द्यावे. पहिल्या दोन क्लायंट पायऱ्या उत्तीर्ण झाल्या आणि तिसरी अयशस्वी झाली तर दोष फॉरवर्डिंग किंवा NAT मध्ये आहे. दुसरी पायरी अयशस्वी झाली तर ब्रिज किंवा DHCP अजून अपूर्ण आहे.

रोलबॅक म्हणजे एक फाइल संपादन आणि दोन कमांड: ब्लॉक काढा, dhcpcd पुन्हा सुरू करा, आणि डीफॉल्ट रूट स्पष्टपणे ip route replace default via 192.168.50.1 dev br0 ने बदला. देखभाल विंडो बंद होण्यापूर्वी हे करा, नंतर नाही, कारण डीफॉल्ट रूट गमावलेला Pi दुरुस्तीसाठी वापरणाऱ्या नेटवर्कवरून पोहोचता येत नाही.