Pi-hole v6 WireGuard வாடிக்கையாளர்களின் DNS வினவல்களை ஏன் புறக்கணிக்கிறது

Pi-hole v6 போர்ட் 53 இல் ஒரு DNS வினவலைப் பெற்று, வந்த பாக்கெட்டுக்கு பதில் அளிக்க அனுமதி உண்டா என்பதைத் தீர்மானிக்கிறது. WireGuard ஹோஸ்ட்டில் இந்த இரண்டாவது முடிவே, LAN இலிருந்து தீர்வி ஆரோக்கியமாகத் தெரியும்போது வாடிக்கையாளருக்கு நேரம் முடிவது ஏன் என்பதற்கான காரணமாக இருக்கும். போர்ட் திறந்துள்ளது, FTL இயங்குகிறது, ஆனாலும் 10.90.0.1 இலிருந்து எதுவும் திரும்பி வரவில்லை. பதில் வெளியேறும் முன் மூன்று விஷயங்கள் ஒன்றுக்கொன்று தாக்கம் செலுத்துகின்றன: dns.interface, dns.listeningMode மற்றும் இரண்டிற்கும் முன்னால் உள்ள ஃபயர்வால்.

கேட்கும் சாக்கெட் யாருக்கு பதில் கிடைக்கும் என்பதைத் தீர்மானிக்கவில்லை

FTL போர்ட் 53 இல் UDP மற்றும் TCP கேட்பவர்களைத் திறக்கிறது. இயல்புநிலை உள்ளமைவில் சாக்கெட் பெரும்பாலும் wildcard ஆக இருக்கும், எனவே ss -lunp | grep :53 VPN வாடிக்கையாளர்களுக்கு சேவை வழங்கப்பட்டாலும் இல்லாவிட்டாலும் 0.0.0.0:53 மற்றும் [::]:53 ஐக் காட்டுகிறது. wildcard சாக்கெட் பாக்கெட்டை ஏற்றுக்கொள்கிறது, பின்னர் FTL பதில் அளிக்கும் முன் தனது இடைமுகம் மற்றும் மூல விதிகளைப் பயன்படுத்துகிறது. அதனால்தான் "போர்ட் கேட்டுக்கொண்டிருக்கிறது" என்பது சுரங்க வாடிக்கையாளரைப் பற்றி மிகக் குறைவாகவே நிரூபிக்கிறது.

நீங்கள் செயலில் இருப்பதாக நினைக்கும் கோப்புக்குப் பதிலாக இயங்கும் உள்ளமைவைப் படியுங்கள். pihole-FTL --config dns.interface மற்றும் pihole-FTL --config dns.listeningMode உண்மையான மதிப்புகளை அச்சிடுகின்றன, மேலும் கொள்கலன், சூழல் மாறி அல்லது பயன்பாட்டு மேலாளர் அந்த அமைப்பை வைத்திருக்கும்போது அவை ஹோஸ்ட் கோப்பிலிருந்து வேறுபடலாம். Pi-hole FTL உள்ளமைவு குறிப்பு பயன்முறைகளையும் அவற்றில் எது இடைமுகத்தைச் சார்ந்தது என்பதையும் பட்டியலிடுகிறது.

LOCAL எந்த துணைப்பிணையம் என்று கேட்கிறது, SINGLE எந்த இடைமுகம் என்று கேட்கிறது

LOCAL, இயல்புநிலை, மூல முகவரி ஹோஸ்ட்டின் இடைமுகங்களில் ஒன்றில் உள்ளமைக்கப்பட்ட துணைப்பிணையத்தைச் சேர்ந்த வினவல்களுக்குப் பதிலளிக்கிறது. 10.90.0.1/24 கொண்ட எளிய wg0 அந்தச் சோதனையைக் கடக்கிறது, ஏனெனில் 10.90.0.2 இல் உள்ள வாடிக்கையாளர் சுரங்க துணைப்பிணையத்திற்குள் இருக்கிறார். பியரின் மறுபக்கத்தில் திசைவிக்கப்பட்ட வாடிக்கையாளர், அல்லது வேறு முன்னொட்டில் NAT பின்னால் மறைந்திருக்கும் வாடிக்கையாளர், பாக்கெட் wg0 க்கு வந்தாலும் அதைக் கடக்கவில்லை, மேலும் பதிவில் எந்த வினவலும் தெரியவில்லை.

SINGLE கேள்வியை மாற்றுகிறது. இது dns.interface இல் பெயரிடப்பட்ட இடைமுகத்திற்கு வரும் வினவல்களை loopback உட்பட ஏற்றுக்கொண்டு மூல துணைப்பிணையத்தைப் புறக்கணிக்கிறது. சங்கிலி அல்லது திசைவிக்கப்பட்ட VPN அமைப்பில் தாக்குப்பிடிக்கும் பயன்முறை இதுவே. இரண்டு விசைகளையும் ஒன்றாக அமைக்கவும், ஏனெனில் பெயரிடப்பட்ட இடைமுகம் இல்லாத பயன்முறை முழுமையான அறிவுறுத்தல் அல்ல:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND சாக்கெட்டை மாற்றுகிறது, அதற்கு விலை உண்டு

BIND wildcard சாக்கெட்டை வடிகட்டுவதில்லை; போர்ட் 53 ஐ பெயரிடப்பட்ட இடைமுகத்தில் உள்ள முகவரிகளுடன் மட்டுமே இணைக்கிறது, எனவே கர்னல் வேறெங்கும் வரும் பாக்கெட்டுகளை நிராகரிக்கிறது. இது SINGLE ஐ விட கடுமையானது, அதன் ஒத்தசொல் அல்ல. விலை துவக்கத்தில் தெரிகிறது: FTL தொடங்கும்போது wg0 மேலே இல்லாவிட்டால், இணைக்க முகவரி இல்லாமல் இருக்கலாம், இடைமுகம் தோன்றி FTL மீண்டும் தொடங்கும் வரை தீர்வி கேட்பவர் இல்லாமல் இயங்கலாம்.

தொடக்க வரிசையை நீங்கள் கட்டுப்படுத்தும்போது BIND தேர்ந்தெடுக்கவும், எடுத்துக்காட்டாக WireGuard இடைமுகத்திற்குப் பின் வரிசைப்படுத்தப்பட்ட systemd அலகு, மேலும் FTL பார்ப்பதற்கு முன் கர்னல் அலைந்து திரியும் பாக்கெட்டுகளை வீச வேண்டும் என்று விரும்பும்போது. சுரங்கம் வந்து போகும்போது, அல்லது FTL க்குப் பின் தொடங்கும் கருவி இடைமுகத்தை உருவாக்கும்போது SINGLE தேர்ந்தெடுக்கவும்.

ஃபயர்வால் இரண்டாவது வாசல்

சரியான FTL பயன்முறையும் ஹோஸ்ட் ஃபயர்வால் wg0 இல் போர்ட் 53 ஐ வீசினால் தோல்வியடையும். இரண்டு நெறிமுறைகளுக்கும் VPN மூல வரம்பை அனுமதித்து இணையப் பக்கத்தை மூடி வைக்கவும். inet filter அட்டவணையில் உள்ள input சங்கிலியுடன் nftables இல் விதிகள் இப்படித் தெரிகின்றன:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

சுரங்கம் IPv6 எடுத்துச் சென்றால் பொருந்தும் IPv6 விதிகளைச் சேர்க்கவும், அவற்றைச் சங்கிலியின் drop கொள்கைக்கு முன் வைக்கவும். ஹோஸ்ட் ufw அல்லது firewalld பயன்படுத்தினால், கருவிகளைக் கலக்காமல் அதே மேலாளரில் அதே பொருத்தத்தை வெளிப்படுத்தவும். இணைய ரவுட்டரிலிருந்து போர்ட் 53 ஐ முன்னனுப்ப வேண்டாம்; வாடிக்கையாளர்கள் சுரங்கம் வழியாக தீர்வியின் VPN முகவரியை அடைய வேண்டும்.

இரண்டு பாதைகள் தனித்தே இருக்கின்றன. வாடிக்கையாளர் வினவல்கள் FTL இல் முடிகின்றன. FTL இன் சொந்த மேல்நிலைத் தேடல்கள் ஹோஸ்ட்டின் திசைவழி அட்டவணைப்படி வெளியேறுகின்றன, அது சுரங்கத்தைப் பயன்படுத்தலாம் அல்லது பயன்படுத்தாமல் இருக்கலாம், எனவே பதிலளித்து பயனுள்ள எதையும் திருப்பித் தராத தீர்வி மேல்நிலைப் பிரச்சினை. வலை நிர்வாகமும் API யும் தங்கள் சொந்த போர்ட்டுகளில் கேட்கின்றன, அவற்றுக்குத் தனிக் கட்டுப்பாடு தேவை.

பதிலையும் மறுப்பையும் சரிபார்க்கவும்

VPN வாடிக்கையாளரிலிருந்து, இரண்டு நெறிமுறைகளிலும் தீர்வியின் முகவரியைக் கேளுங்கள்: dig @10.90.0.1 example.com மற்றும் dig +tcp @10.90.0.1 example.com. பின்னர் நிர்வாக இடைமுகத்தில் வினவல் பதிவைப் பார்த்து FTL வினவலைப் பதிவு செய்ததை உறுதிசெய்யவும். பதிவு உள்ளீடு இல்லாத வாடிக்கையாளர் நேரம் முடிவு ஃபயர்வால் அல்லது இடைமுக வடிகட்டியைச் சுட்டுகிறது; பதில் இல்லாத பதிவு உள்ளீடு மேல்நிலைத் தீர்வைச் சுட்டுகிறது.

VPN க்கு வெளியே உள்ள ஹோஸ்ட்டிலிருந்து எதிர்மறைப் பாதையைச் சோதிக்கவும். dig @10.90.0.1 example.com நேரம் முடிய வேண்டும், மேலும் ss -lunp தீர்வியில் போர்ட் 53 பொது முகவரியுடன் இணைந்திருப்பதைக் காட்டக்கூடாது. சேவையை ஒருமுறை மறுதொடக்கம் செய்து, பின்னர் ஹோஸ்ட்டை மீள்துவக்கி, wg0 மீண்டும் தோன்றிய பிறகும் தீர்வி பதிலளிப்பதை உறுதிசெய்யவும். அடுத்த மீள்துவக்கம் வரை மட்டும் வேலை செய்யும் வினவல் முடிந்த மாற்றம் அல்ல.