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 बाट सफलतापूर्वक निस्कने अनुरोध फर्कने बाटोमा अझै खस्न सक्छ, र क्लाइन्ट नै सम्पूर्ण मार्ग देखिने एकमात्र ठाउँ हो।