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-ஐ வெற்றிகரமாக விட்டு வெளியேறும் கோரிக்கை திரும்பும் வழியில் இன்னும் கைவிடப்படலாம், முழுப் பாதையும் தெரியும் ஒரே இடம் கிளையண்ட் மட்டுமே.