OpenVPN क्लायंट दुसऱ्या होस्टवरील Pi-hole रिझोल्व्हरकडे पाठवा

OpenVPN प्रोफाइलमध्ये Pi-hole चा पत्ता टाकणे त्याकडे मार्ग तयार करत नाही, त्याला विचारण्याची परवानगी देत नाही आणि क्लायंट तो वापरेल याची हमी देत नाही। Pi-hole वेगळ्या LAN मशीनवर असताना चार गोष्टी जुळल्या पाहिजेत: क्लायंटकडून मार्ग, गेटवेकडून फॉरवर्डिंग, पूलकडे परतीचा मार्ग आणि Pi-hole वरच स्वीकृती धोरण। प्रत्येक बिघाड लॉगमध्ये वेगळा दिसतो। ते याच क्रमाने हाताळणे शेवटचा आधी दुरुस्त करण्यापेक्षा जलद आहे। नेहमीचा शॉर्टकट, प्रत्येक स्रोतासाठी रिकर्शन उघडणे, छोटी अडचण कायमच्या अडचणीत बदलतो।

ढकललेला DNS पर्याय काय करतो आणि काय करत नाही

सर्व्हर खालील निर्देशासह रिझोल्व्हरची जाहिरात करतो, 192.168.50.53 हा Pi-hole होस्ट आहे असे गृहीत धरून। क्लायंट पर्याय प्राप्त करतो आणि, त्याच्या प्लॅटफॉर्म आणि रिझोल्व्हर एकत्रीकरणानुसार , तो टनेल इंटरफेसवर लागू करतो किंवा स्थानिक स्टबच्या बाजूने दुर्लक्ष करतो। रूट ओळ DNS ओळीइतकीच महत्त्वाची आहे, कारण ज्या रिझोल्व्हरपर्यंत क्लायंट पोहोचत नाही तो कोणताही रिझोल्व्हर नाही। यातील काहीही सर्व्हरच्या बाजूने दिसत नाही।

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

पर्याय मिळणे हे तो वापरण्यासारखे नाही। रिझोल्व्हर व्यवस्थापक असलेला Linux क्लायंट ढकललेला सर्व्हर स्वीकारू शकतो आणि त्याला फक्त काही डोमेन पाठवू शकतो; जो क्लायंट स्वतः DNS सांभाळतो तो सेटिंग पूर्णपणे बदलू शकतो। ढकललेले रूट काही प्लॅटफॉर्मवर मर्यादितही असतात, ज्यामुळे पर्याय स्वीकारला गेला तरी रिझोल्व्हर अगम्य राहतो। क्लायंटवर पहा कोणता सर्व्हर उत्तर देतो, सर्व्हरवर नाही काय पाठवले गेले।

पर्याय सर्व्हरच्या बाजूबद्दलही काही सांगत नाही। DNS रहदारीला तरीही क्लायंटकडून गेटवेकडे आणि गेटवेकडून Pi-hole कडे जावे लागते, त्यापूर्वी कोणताही पर्याय अर्थपूर्ण होतो। हरवलेला मार्ग आणि नाकारलेली क्वेरी क्लायंटच्या बाजूने सारखीच दिसतात, म्हणून आधी गेटवेवर फॉरवर्डिंगची खात्री करा।

Pi-hole कडून पूलकडे परतीचा मार्ग

क्लायंटचा स्रोत पत्ता टिकवला गेल्यास Pi-hole VPN पूलमधील पत्त्याला उत्तर देतो। त्याचे स्वतःचे राउटिंग टेबल कदाचित या पूलबद्दल काहीही जाणत नाही, म्हणून उत्तर त्याच्या डीफॉल्ट गेटवेकडे जाते आणि गायब होते। क्वेरी लॉग जुळणाऱ्या उत्तराशिवाय विनंती दाखवतो, ज्याला फायरवॉल समस्या समजणे सोपे आहे।

LAN राउटरला पूलसाठी स्थिर रूट द्या ज्यात OpenVPN गेटवे पुढील हॉप असेल, किंवा Pi-hole कडे फॉरवर्ड करण्यापूर्वी गेटवेवर स्रोताचे भाषांतर करा। पहिले प्रत्येक क्लायंटचे पत्ते Pi-hole च्या क्वेरी लॉगमध्ये दिसत ठेवते। दुसरे परतीच्या रूटची अट काढते पण प्रत्येक क्वेरी गेटवेकडून आलेली दाखवते। कोणतेही चुकीचे नाही; ते वेगळ्या प्रश्नांना उत्तर देतात।

प्रति-क्लायंट अहवाल किंवा धोरण महत्त्वाचे असल्यास स्थिर रूट हा चांगला सौदा आहे। LAN दुसऱ्या कोणाच्या ताब्यात असल्यास आणि रूट उपलब्ध नसल्यास, भाषांतर हा व्यवहार्य पर्याय आहे, क्लायंटची ओळख गमावल्याची नोंद ठेवून। तुम्ही कोणते निवडले ते लिहा, कारण पुढील प्रत्येक लॉग प्रश्न त्यावर अवलंबून आहे।

राउट केलेल्या क्लायंटसाठी Pi-hole ची ऐकण्याची पद्धत

DNS अंतर्गत सेटिंग्ज पानावरील इंटरफेस ऐकण्याच्या वर्तनाचा ड्रॉपडाउन ठरवतो की Pi-hole कोणत्या स्रोतांना उत्तर देतो। सर्वात कडक पर्याय फक्त थेट जोडलेल्या नेटवर्कमधील क्लायंट स्वीकारतो; जो पर्याय उपकरणांना जास्तीत जास्त एक हॉप दूरपर्यंत परवानगी देतो तो हे शेजारच्या राउटरमागील सबनेटपर्यंत वाढवतो, आणि राउट केलेला VPN क्लायंट अगदी असाच दिसतो। पॅकेट खरोखर LAN इंटरफेसवर येते, पण त्याचा स्रोत पत्ता दुसऱ्या सबनेटचा आहे। हे धोरणाचे नाकारणे आहे, राउटिंगचा बिघाड नाही, आणि लॉग वाचताना हा फरक महत्त्वाचा आहे।

Pi-hole ची ऐकण्याची मार्गदर्शिका स्थानिकरीत्या जोडलेले स्रोत राउट केलेल्या मूळांपासून वेगळे करते, आणि आगमन इंटरफेस निकष नाही। असा मोड निवडा जो संपूर्ण इंटरनेटला परवानगी न देता VPN पूलला परवानगी देतो, नंतर तो फायरवॉल नियमाशी जोडा जो DNS फक्त पूलमधून स्वीकारतो।

पहिली क्वेरी चालण्यासाठी सर्व मूळांसाठी रिकर्शन उघडणे ही चुकीची दुरुस्ती आहे। ती खाजगी रिझोल्व्हरला उघडा बनवते, आणि सुधारणा मर्यादित परवानगी आहे, जागतिक नाही।

उत्तर क्वेरी लॉगशी जुळवा

क्लायंटला विचारा, नंतर सर्व्हर तपासा आणि दोन्हींची तुलना करा। systemd-resolved क्लायंटवर खालील कमांड सांगतात कोणत्या रिझोल्व्हरने उत्तर तयार केले आणि प्रति लिंक कोणते सर्व्हर संरचित आहेत। असे नाव वापरा जे फक्त Pi-hole जाणते, कारण Pi-hole च्या पत्त्यावर थेट क्वेरी पोहोच सिद्ध करते, संरचना नाही।

resolvectl query intranet.example.lan
resolvectl dns

अपेक्षित उत्तर 192.168.50.53 ला सर्व्हर म्हणून नाव देते आणि असा पत्ता परत करते जो फक्त तोच रिझोल्व्हर जाणत असेल। नंतर Pi-hole चे स्वतःचे दृश्य पहा: pihole -t क्वेरी लॉग थेट फॉलो करते, आणि प्रत्येक ओळ स्रोत पत्ता घेऊन येते। स्रोत क्लायंटचा टनेल पत्ता असल्यास पूलचा रूट अभंग आहे। तो गेटवेचा LAN पत्ता असल्यास स्रोत भाषांतर सुरू आहे आणि क्लायंटचा स्वतःचा पत्ता कधीही दिसणार नाही।

लॉगमध्ये काहीच दिसत नसल्यास क्वेरी कधीच Pi-hole पर्यंत पोहोचली नाही आणि पुढील तपासणी गेटवेवर फॉरवर्डिंग आहे। क्वेरी दिसत असून उत्तर परत येत नसल्यास समस्या परतीच्या मार्गात आहे, म्हणजे मागील विभागात। अशा प्रकारे बिघाड विभागणे राउटिंग चुकीला फायरवॉल नियम समजण्यापासून थांबवते।

गेटवेचा फॉरवर्डिंग नियम तपासा

गेटवेने क्लायंटचे DNS पॅकेट Pi-hole कडे फॉरवर्ड करावे लागतात, आणि जो नियम हे करतो तो गृहीत धरण्याऐवजी वाचला पाहिजे। खालील कमांड पोर्ट 53 ला स्पर्श करणारे नियम काउंटरसह सूचीबद्ध करतात, nftables होस्टवर आणि iptables होस्टवर। अस्तित्वात असलेला पण शून्य जुळणी दाखवणारा नियम हा संकेत आहे की रहदारी भाषांतरापूर्वी टाकली जात आहे।

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

काउंटर वाचा, फक्त नियम नाही। जो नियम कधीच जुळत नाही त्याचा अर्थ पॅकेट दुसऱ्या इंटरफेसने बाहेर पडते, किंवा क्लायंटने ते कधीच पाठवले नाही। जो नियम प्रत्येक क्वेरीला जुळतो त्याचा अर्थ फॉरवर्डिंग चालू आहे आणि समस्या मार्गात पुढे आहे।

होस्ट कोणतेही साधन वापरो, तपासणी अरुंद ठेवा: पूल स्रोत म्हणून, पोर्ट 53 गंतव्य म्हणून आणि Pi-hole एकमेव परवानगी असलेले लक्ष्य म्हणून। रुंद फॉरवर्डिंग नियम जो पोर्ट 80 लाही परवानगी देतो, ती आणखी एक समस्या आहे जी घडण्याची वाट पाहत आहे।