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 துறைமுகத்திற்கும் அனுமதிக்கும் பரந்த அனுப்புதல் விதி நிகழக் காத்திருக்கும் மற்றொரு சிக்கல்.