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కు కూడా అనుమతించే విస్తృత ఫార్వర్డింగ్ నియమం జరగడానికి ఎదురుచూస్తున్న మరో సమస్య.