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 पेक्षा वेगळ्या सहाय्यकाकडून येतात, आणि VPN धोरण फक्त IPv4 व्यापत असताना IPv6 सुरू ठेवल्यास क्लायंटना टनेल टाळणारा मार्ग मिळतो। एकतर IPv6 बाजूची योजना करा किंवा ती हॉटस्पॉट इंटरफेसवर लेखी कारणासह बंद करा।
पोर्ट 53 वर प्रत्यक्षात कोण उत्तर देतो
कॉन्फिगरेशन बदलण्यापूर्वी पोर्ट 53 वर ऐकणारी प्रत्येक प्रक्रिया सूचीबद्ध करा। स्थानिक रिझॉल्व्हर stub, Pi-hole आणि सामायिकरण सहाय्यक चालवणाऱ्या Pi वर, ऐकणाऱ्यांची यादी हे क्वेरींना कोण उत्तर देतो याचे एकमेव विश्वासार्ह नकाशा आहे:
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 मधून यशस्वीपणे बाहेर पडणारी विनंती परतीच्या मार्गावर तरीही पडू शकते, आणि क्लायंट हे एकमेव ठिकाण आहे जिथे संपूर्ण मार्ग दिसतो।