Pi पर हॉटस्पॉट क्लाइंट TUN VPN से घरेलू LAN तक नहीं पहुँचते

जिन हॉटस्पॉट क्लाइंट को पता मिलता है पर घर का शेयर नहीं खुलता, उनके पास पुल नहीं, वापसी मार्ग की कमी है। TUN पथ, प्रीफ़िक्स मालिकों और NAT को ट्रेस करें।

स्थानीय Wi-Fi और Ethernet क्लाइंट Pi के हॉटस्पॉट से जुड़ते हैं, उसके DHCP दायरे से पता लेते हैं और बिना शिकायत इंटरनेट पेज लोड करते हैं। फिर वही क्लाइंट घर के LAN पर फ़ाइल शेयर या वेब इंटरफ़ेस खोलते समय समय-सीमा पार कर जाते हैं, जबकि Pi खुद सुरंग के ज़रिए उस LAN तक पहुँचता है। वायरलेस परत में कुछ भी टूटा नहीं है। जो कम है वह रूटेड अनुबंध है: हॉटस्पॉट प्रीफ़िक्स को TUN इंटरफ़ेस में ले जाना होगा, और घर की ओर किसी को पता होना चाहिए कि जवाब वहाँ कैसे वापस भेजे जाएँ। एक भी पैकेट पूरी यात्रा पूरी कर सके, इससे पहले दोनों आधे मौजूद होने चाहिए।

तीन अलग कामों वाले तीन जुड़ाव

Linux Ethernet ब्रिज फ़्रेम को गंतव्य MAC पते के अनुसार अग्रेषित करता है। OpenVPN TUN मोड में IP पैकेट ले जाता है और उसमें MAC परत बिल्कुल नहीं होती, इसलिए स्थानीय ब्रिज जोड़ने से सुरंग कभी पोर्ट के रूप में दर्ज नहीं होती। कर्नेल TUN/TAP दस्तावेज़ उस विभाजन को समझाते हैं: TAP डिवाइस Ethernet इंटरफ़ेस जैसा दिखता है, TUN डिवाइस नहीं। दो स्थानीय पोर्ट को ब्रिज करके फिर रूट करने वाला डिज़ाइन राउटर है, इंटरफ़ेस के नाम कुछ भी कहें।

यह अंतर मालिकी तय करता है। क्लाइंट का सबनेट, उनका डिफ़ॉल्ट गेटवे और उस दायरे का DHCP अधिकार Pi की स्थानीय योजना के हैं। घर के DHCP प्रसारण रूटेड सुरंग को पार नहीं करते, और कोई ब्रिज सेटिंग इसे नहीं बदलती; क्लाइंट को घर के DHCP सर्वर की ओर भेजना अलग, जानबूझकर किया गया रिले डिज़ाइन है जिसकी अपनी विफलता विधियाँ हैं।

मॉडेम को भी क्लाइंट ब्रिज से बाहर रखें। PPP जुड़ाव अलग लेबल वाला Ethernet उपकरण नहीं है, और pppd का प्रलेखित डिफ़ॉल्ट-रूट तर्क IPCP बातचीत के बाद चलता है और वह लिंक गिरने पर अपना रूट वापस ले लेता है। DHCP टेम्पलेट की नकल करके हर usb0 का नाम ppp0 रख देना गेटवे, मीट्रिक या जीवनचक्र के बारे में कुछ साबित नहीं करता।

कोई भी कॉन्फ़िग संपादित करने से पहले प्रीफ़िक्स चुनें

अतिव्यापी प्रीफ़िक्स फ़ायरवॉल नियमों से ज़्यादा शाम बर्बाद करते हैं, क्योंकि अतिव्यापन सुरंग स्वस्थ होने पर भी रूट खोज को गलत इंटरफ़ेस पर भेजता है। Pi पर पहले से क्या मौजूद है इसकी सूची बनाकर शुरू करें, फिर परिणाम को चार अलग पूल के रूप में पढ़ें।

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

पहला पूल वह underlay पता है जो कैरियर ने मॉडेम को दिया; उसे क्लाइंट की ओर देखने वाली हर योजना से बाहर रहना चाहिए। दूसरा सर्वर द्वारा चुना गया सुरंग सबनेट है, अक्सर उसका अपना निजी /24। तीसरा हॉटस्पॉट ब्रिज है, और चौथा वह घरेलू प्रीफ़िक्स है जहाँ आप पहुँचना चाहते हैं। इस चलन में हॉटस्पॉट को 172.28.90.0/24 मिलता है जिसमें ब्रिज 172.28.90.1 पर है, और घरेलू सेवा LAN 192.168.77.0/24 रखता है, जो उपभोक्ता राउटर के साथ आने वाले 192.168.1.0/24 और 10.0.0.0/24 डिफ़ॉल्ट तथा 100.64.0.0/10 कैरियर दायरे से बचता है।

हॉटस्पॉट के DHCP दायरे में केवल ब्रिज पते को गेटवे के रूप में घोषित करें, और कुछ नहीं। हॉटस्पॉट क्लाइंट को कभी गेटवे के रूप में घर का पता न दें; उस सेगमेंट तक उनका लिंक-परत पथ नहीं है।

हर दिशा को उसी ओर रूट करें जो उसकी मालिक है

Pi को सुरंग के ज़रिए घरेलू प्रीफ़िक्स के लिए रूट चाहिए। सर्वर मोड में सर्वर आमतौर पर वह रूट धकेलते हैं, इसलिए पहले पुष्टि करें कि अग्रेषण चालू है और कर्नेल tun0 से घरेलू पता हल करता है।

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

अगर ip route get अब भी underlay इंटरफ़ेस बताता है, तो वहीं रुकें; पथ में आगे कुछ भी गलत खोज को ठीक नहीं कर सकता।

घरेलू उपकरणों के पास 172.28.90.0/24 तक कोई रूट नहीं है, इसलिए उनके जवाब डिफ़ॉल्ट गेटवे का पालन करते हैं और राउटर पर मर जाते हैं। दो समर्थित मरम्मतें मौजूद हैं। या तो घरेलू राउटर पर स्थिर रूट जोड़ें जो हॉटस्पॉट प्रीफ़िक्स को VPN सर्वर के LAN पते की ओर भेजे, या, जब सर्वर खुद गेटवे हो, क्लाइंट प्रीफ़िक्स को सर्वर की अपनी रूटिंग तालिका में दर्ज करें। OpenVPN के मल्टी-क्लाइंट मोड में क्लाइंट-विशिष्ट निर्देशिका वह संबंध रखती है: क्लाइंट प्रमाणपत्र के सामान्य नाम पर नामित फ़ाइल, जिसमें iroute 172.28.90.0 255.255.255.0 के साथ वह मिलती route पंक्ति होती है जो उसे सर्वर कर्नेल में स्थापित करती है। सर्वर पर अनुमानित कर्नेल रूट यह कहने के बराबर नहीं है कि कौन सा क्लाइंट प्रीफ़िक्स का मालिक है।

यह काम करे इसके लिए घरेलू नेटवर्क की DHCP सेवा को VPN सर्वर पर न ले जाएँ। पूरे घर के लिए डिफ़ॉल्ट गेटवे बदलना एक निजी वापसी रूट जोड़ने से कहीं बड़ा बदलाव है, और यह DNS, पता आरक्षण और नई लीज़ को अनदेखा करने वाले हर उपकरण को विफलता में घसीटता है।

फ़ायरवॉल का अनुमान लगाए बिना अग्रेषण खोलें

अग्रेषण चालू होने का मतलब यह नहीं कि पैकेट को जाने की अनुमति है। ब्रिज से सुरंग तक यातायात अब भी फ़िल्टर नियमों से टकराता है, और डिफ़ॉल्ट-ड्रॉप अग्रेषण नीति हॉटस्पॉट यातायात को गिरा देती है जबकि Pi का अपना यातायात चलता रहता है, जो ऊपर का बँटा लक्षण ठीक वैसे ही पैदा करता है।

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0 से tun0 तक स्वीकृति नियम और उससे मेल खाती जवाब दिशा, तथा ऐसा postrouting नियम खोजें जो स्रोत को फिर से लिख सके। अगर चेन नीति drop है और कोई नियम मेल नहीं खाता, तो नीति को accept में बदलने के बजाय संकीर्ण स्वीकृतियाँ जोड़ें और फिर परीक्षण करें।

अनुवाद आवश्यकता नहीं, नीति का चुनाव है। घरेलू LAN की ओर स्रोत NAT हर हॉटस्पॉट क्लाइंट को Pi के सुरंग पते जैसा दिखाता है, जिससे घरेलू लॉग में प्रति-क्लाइंट आरोपण खो जाता है और मूल स्रोत की अपेक्षा करने वाली सेवाएँ टूट जाती हैं। NAT के बिना रूटिंग क्लाइंट पते दृश्य रखती है पर ऊपर के वापसी रूट पर निर्भर है। एक चुनें और DNS तथा IPv6 को उसी तरह संभालें, क्योंकि टूटे IPv6 पथ के साथ चलता IPv4 पथ ब्राउज़र में अब भी आधा टूटा पढ़ा जाता है।

आने-जाने की यात्रा जाँचें, फिर उसे जानबूझकर तोड़ें

हॉटस्पॉट क्लाइंट से परीक्षण करें, कभी Pi से नहीं, क्योंकि Pi का अपना यातायात अग्रेषण और वापसी दोनों पथों को दरकिनार करता है। दोनों इंटरफ़ेस देखें जब एक क्लाइंट घरेलू सेवा तक पहुँचने की कोशिश करता है।

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

दोनों कैप्चर साथ पढ़ें। br0 पर ऐसी माँगें जो कभी tun0 पर नहीं दिखतीं, बताती हैं कि Pi अग्रेषित नहीं कर रहा या रूट कहीं और इंगित करता है। tun0 पर बिना जवाब वाली माँगें बताती हैं कि घर की ओर वापसी रूट नहीं है या सर्वर ने पैकेट फ़िल्टर किया। tun0 पर ऐसे जवाब जो फिर कभी br0 पर नहीं दिखते, बताते हैं कि उल्टा फ़िल्टर नियम गायब है, जहाँ सुरंग उत्तम दिखती है और क्लाइंट फिर भी कुछ नहीं देखता।

फिर पथ को जानबूझकर तोड़ें। मॉडेम कनेक्शन नीचे और फिर ऊपर करें और रूट तथा कैप्चर जाँच दोबारा चलाएँ; जो रूट सुरंग से बचता है पर पुनः कनेक्ट पर गायब हो जाता है वह एकबारगी आदेश में नहीं, कनेक्शन प्रोफ़ाइल में होना चाहिए। पुष्टि करें कि सुरंग का परिवहन अब भी underlay से निकलता है, अपने आप से नहीं, जो क्लासिक लूप है जब धकेला गया डिफ़ॉल्ट रूट साथी तक होस्ट रूट के बिना स्वीकार किया जाता है।

डिज़ाइन तभी स्वीकार करें जब हॉटस्पॉट क्लाइंट घरेलू नाम हल कर सके, TCP सेवा खोल सके और एक मॉडेम पुनः कनेक्शन भर सत्र जीवित रख सके। अगर कोई अनुप्रयोग वाकई घरेलू सेगमेंट में Ethernet-स्तर की खोज चाहता है, तो स्थानीय ब्रिज को ब्रिज्ड बताकर प्रसारण आने का इंतज़ार करने के बजाय समर्थित Layer 2 डिज़ाइन चुनें।

संबंधित लेख