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 ఉద్దేశించిన ఎగువ రిజాల్వర్ ద్వారా పరిష్కరిస్తుంది, మరియు అప్లికేషన్ అభ్యర్థనను పూర్తి చేస్తుంది. విజయవంతమైన ping 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 నుండి విజయవంతంగా బయటకు వెళ్లే అభ్యర్థన తిరిగి వచ్చే మార్గంలో ఇంకా పడిపోవచ్చు, మరియు మొత్తం మార్గం కనిపించే ఏకైక ప్రదేశం క్లయింట్ మాత్రమే.