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 ની પણ પરવાનગી આપે, તે બીજી સમસ્યા છે જે થવાની રાહ જોઈ રહી છે.