Pi हॉटस्पॉट, Pi-hole और VPN: हर सेवा को अपना काम सौंपें
एक ही Pi पर तीन सहायक चालू करने से पहले तय करें कि DHCP, DNS और पैकेट अग्रेषण का मालिक कौन है। दोहरे मालिक प्रतिस्पर्धी लीज़ और रिज़ॉल्वर लूप पैदा करते हैं।
एक फ़ोन Pi के हॉटस्पॉट से जुड़ता है, पता लेता है, और पेज फिर भी नहीं खुलता। Pi एक हॉटस्पॉट सहायक, Pi-hole और VPN क्लाइंट चला रहा है, और हर एक मानता है कि वह रास्ते का कोई हिस्सा रखता है। ऐसी ज़्यादातर बिल्ड इसलिए विफल नहीं होतीं कि कोई घटक टूटा है, बल्कि इसलिए कि दो घटक एक ही काम करते हैं। किसी भी चीज़ को ट्यून करने से पहले हर फ़ंक्शन के लिए एक मालिक तय करें।
हर फ़ंक्शन के लिए एक मालिक तय करें
यहाँ चार फ़ंक्शन मायने रखते हैं, और हर एक को ठीक एक मालिक चाहिए। नीचे की तालिका फ़ंक्शन, व्यावहारिक मालिक और वह बताती है जो गड़बड़ होता है जब दो सेवाएँ उस पर दावा करती हैं।
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
ओवरलैप आम तौर पर एक बार में एक पैकेट आता है। हॉटस्पॉट सहायक अपनी dnsmasq प्रति इंस्टॉल करता है, Pi-hole को पोर्ट 53 चाहिए, और VPN क्लाइंट रूट जोड़ता है। हर कदम अकेले उचित लगता है, और साथ में वे ऐसी मशीन बनाते हैं जहाँ दूसरी शुरू होने वाली सेवा पहली का व्यवहार चुपचाप बदल देती है।
कुछ और चालू करने से पहले मालिक लिख लें। बिल्ड नोट्स में एक छोटी तालिका बाद के इंस्टॉल को ऐसे फ़ंक्शन पर कब्ज़ा करने से रोकती है जिसका पहले से मालिक था।
एक रेंज चुनें और उसे टनल से दूर रखें
हॉटस्पॉट की रेंज, उसमें Pi का पता, DHCP पूल और वह रिज़ॉल्वर चुनें जो क्लाइंट को मिलता है। उस रेंज को ऊपरी LAN और VPN टनल की रेंज से अलग रखें, क्योंकि ओवरलैप होती सबनेट रूटिंग की समस्या को पता अनुवाद के प्रोजेक्ट में बदल देती हैं। टनल से ओवरलैप होती रेंज Pi को दो समान प्रीफ़िक्स के बीच अनजाने राउटर बना देती है। रेंज और पूल को डिफ़ॉल्ट पर छोड़ने के बजाय हॉटस्पॉट कॉन्फ़िगरेशन में लिखें।
अगर हॉटस्पॉट NetworkManager के साझा मोड के पास है, तो DHCP सर्वर जोड़ने से पहले प्रभावी कनेक्शन जाँचें। साझा मोड अपने सहायक शुरू करता है और अग्रेषण चालू करता है, इसलिए वह उस इंटरफ़ेस के पता प्लान का पहले से मालिक है। सिर्फ़ उपलब्ध होने की वजह से दूसरा सर्वर जोड़ना अतिरेक के बजाय प्रतिस्पर्धी प्रस्ताव बनाता है।
IPv6 पर सोच-समझकर फ़ैसला करें। राउटर घोषणाएँ और DHCPv6 कई सेटअप में DHCPv4 से अलग सहायक से आते हैं, और IPv6 को चालू रखना जबकि VPN नीति सिर्फ़ IPv4 को कवर करती है, क्लाइंट को टनल से बचने वाला रास्ता दे देता है। या तो IPv6 पक्ष की योजना बनाएँ या उसे हॉटस्पॉट इंटरफ़ेस पर लिखित कारण के साथ बंद करें।
पोर्ट 53 पर असल में कौन जवाब देता है
कॉन्फ़िगरेशन बदलने से पहले पोर्ट 53 पर सुनने वाली हर प्रक्रिया की सूची बनाएँ। ऐसे Pi पर जो स्थानीय रिज़ॉल्वर stub, Pi-hole और साझा करने वाला सहायक चलाता है, सुनने वालों की सूची ही इसका एकमात्र भरोसेमंद नक्शा है कि क्वेरी का जवाब कौन देता है:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole की इंटरफ़ेस गाइड समझाती है कि एक इंटरफ़ेस तक सीमित स्वीकृति मोड फिर भी wildcard सॉकेट इस्तेमाल कर सकता है और कहीं और आने वाले पैकेट गिरा सकता है। यह सिर्फ़ चुने हुए इंटरफ़ेस बाँधने के समान नहीं है, जो उस समय इच्छित व्यवस्था है जब किसी दूसरी DNS सेवा को मशीन साझा करनी हो।
दो प्रक्रियाएँ आम तौर पर एक ही पता और पोर्ट नहीं बाँध सकतीं, हालाँकि SO_REUSEPORT साझा बाइंड को सफल बना सकता है; तब भी wildcard सुनने वाला संकरी सेवा के लिए आए पैकेट ले सकता है। मनचाही भूमिका के लिए दस्तावेज़ी मोड चुनें और सेवाओं को इच्छित क्रम में फिर से शुरू करें।
Pi-hole का प्रबंधन पेज हॉटस्पॉट नेटवर्क से बाहर रखें। क्लाइंट को रिज़ॉल्वर चाहिए, वह वेब इंटरफ़ेस या API नहीं जो रिज़ॉल्वर की कॉन्फ़िगरेशन बदल सके।
DNS की दो टाँगें, हर एक के लिए एक नीति
क्लाइंट की क्वेरी फ़ोन से Pi तक जाती है, और एक अलग क्वेरी Pi से उसके ऊपरी रिज़ॉल्वर तक जाती है। अग्रेषित हॉटस्पॉट ट्रैफ़िक से मेल खाता रूटिंग नियम दूसरी टाँग पर अपने आप लागू नहीं होता, क्योंकि Pi वह ट्रैफ़िक स्थानीय रूप से बनाता है। अगर VPN को DNS ढोना है, तो स्थानीय रास्ते को अपनी नीति चाहिए।
लूप से सावधान रहें। Pi-hole के ऊपरी रिज़ॉल्वर को ऐसे पते की ओर मोड़ना जो Pi खुद परोसता है, सीधे या पोर्ट-फ़ॉरवर्ड के ज़रिए, ऐसी क्वेरी बनाता है जो समय खत्म होने तक घूमती रहती हैं। उसे असली ऊपरी रिज़ॉल्वर दें या उन डोमेन के लिए सशर्त फ़ॉरवर्डर दें जिनका वह जवाब नहीं दे सकता।
तय करें कि टनल गिरने पर क्या होगा। स्थानीय रिज़ॉल्वर पर लौटना ब्राउज़िंग को ज़िंदा रखता है लेकिन नाम VPN के बाहर ले जा सकता है; ब्लॉक करना नीति को बरकरार रखता है और खराबी को दिखने वाली गलती बना देता है। दोनों विकल्प उचित हैं, पर उन्हें चुनना होगा, डिफ़ॉल्ट से विरासत में नहीं लेना।
रास्ता और खराबी के समय का व्यवहार साबित करें
परतों में जाँचें: क्लाइंट को पता मिलता है, क्लाइंट Pi के ज़रिए नाम हल करता है, Pi मनचाहे ऊपरी रिज़ॉल्वर के ज़रिए हल करता है, और ऐप्लिकेशन अनुरोध पूरा करता है। सफल पिंग DNS के बारे में कुछ नहीं कहता, और सफल लुकअप अग्रेषण के बारे में कुछ नहीं कहता।
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1फिर टनल रोकें और दोहराएँ। मनचाहा व्यवहार कुछ सेकंड में दिखना चाहिए, Pi-hole या हॉटस्पॉट सेवा को हाथ से फिर से शुरू करने के बाद नहीं। खराबी के दौरान क्लाइंट की रिज़ॉल्वर सेटिंग जाँचें, क्योंकि दूसरा सार्वजनिक रिज़ॉल्वर जवाब देता रहेगा भले ही नीति विफलता की उम्मीद कर रही हो।
अग्रेषण और NAT के लिए एक मालिक रखें और उसे क्लाइंट से जाँचें, खुद Pi से नहीं। Pi से सफलतापूर्वक निकलने वाला अनुरोध वापसी के रास्ते में फिर भी गिर सकता है, और क्लाइंट ही वह एकमात्र जगह है जहाँ पूरा रास्ता दिखता है।