एक ही 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 दस्तावेज़ीकरण रेंज से आता है, इसलिए जब आप यह पढ़ रहे हैं तब यह किसी असली सर्वर से टकरा नहीं सकता।

टनल को उसके अपने सर्वर तक का रास्ता चुराने से रोकें

जो OpenVPN क्लाइंट redirect-gateway स्वीकार करता है वह डिफ़ॉल्ट रूट ले लेता है और उसे टनल में भेज देता है। यह तब सही है जब हर एक्सेस पॉइंट क्लाइंट को 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 उस नेटवर्क से अगम्य है जिसे आप उसे ठीक करने के लिए इस्तेमाल करते।