DNS திசைதிருப்பலுக்குப் பின் dnsmasq வினவல்கள் VPN-ஐ விட்டு வெளியேறுவது ஏன்

LAN கிளையண்ட் தன் VPN-ஐ சரியாக அடைகிறது, இருப்பினும் அதன் DNS வினவல்கள் தவறான மேல்நிலை இணைப்பில் தோன்றுகின்றன. இது வழக்கமான பொருளில் ஒரு கசிவு அல்ல; ரவுட்டர் வினவலை அனுப்புவதை நிறுத்தி தானே அதற்குப் பதிலளிக்கும்போது இது நடக்கிறது. இடையீடு இலக்கை உள்ளூர் சாக்கெட்டுக்கு மீண்டும் எழுதுகிறது, பின்னர் தீர்வான் தன் சொந்த மூல முகவரியுடனும் தன் சொந்த வழித்தட முடிவுடனும் இரண்டாவது, தொடர்பில்லாத உரையாடலைத் திறக்கிறது. கிளையண்டின் ஓட்டத்தில் இடப்படும் குறிகள் முதல் உரையாடலை விவரிக்கின்றன, இரண்டாவது பற்றி எதுவும் சொல்லவில்லை.

குறி வினவலுடன் பயணம் செய்யாது

பாக்கெட் குறிகள் conntrack பதிவிலும் பறக்கும் பாக்கெட்டிலும் வாழ்கின்றன. ஒரு REDIRECT விதி அந்தப் பறத்தலை முடிவுக்குக் கொண்டுவருகிறது: சுமை உள்ளூர் சாக்கெட்டுக்கு ஒப்படைக்கப்படுகிறது, அசல் பதிவு தன் வேலையை முடித்துவிட்டது. அதன் பிறகு ரவுட்டரை விட்டு வெளியேறுவது தீர்வான் செயல்முறை உருவாக்கிய புதிய சாக்கெட், அதன் மூலம் ரவுட்டரின் சொந்த முகவரி.

அதனால்தான் LAN கிளையண்டின் முகவரியில் விசையிடப்பட்ட கொள்கை வழித்தடம் ஒருபோதும் மேல்நிலை வினவலுடன் பொருந்தாது. புதிய சாக்கெட் கிளையண்டுக்கு அல்ல, dnsmasq-க்கு உரியது, மேலும் கர்னல் வழித்தடத்தை ரவுட்டரின் சொந்தப் போக்குவரத்துக்கு மதிப்பிடுகிறது. மூல விதிகள், இடைமுக விதிகள், குறி விதிகள் அனைத்தும் வேறு tuple-ஐப் பார்க்கின்றன. குறி பரவுகிறது என்று கருதுவதே இந்த அமைப்பில் மிகப் பொதுவான தவறு, கிளையண்ட் பக்கப் பிடிப்பில் அது தெரியாது.

இரு உரையாடல்களும் உண்மையில் ஒரு பெயரையும் ஒரு நேரத்தையும் பங்கிடுகின்றன, பிடிப்பை விரைவாகப் பார்க்கும்போது அவை ஒரே ஓட்டமாகத் தோன்றுவதற்குக் காரணம் அதுவே.

எங்கே அனுப்புதல் உள்ளூர் தீர்வாக மாறுகிறது

53-ஆம் துறைமுகம் திசைதிருப்பப்படுகிறதா, வேறு ஹோஸ்ட்டுக்கு மொழிபெயர்க்கப்படுகிறதா, அல்லது அப்படியே விடப்படுகிறதா என்பதைக் கண்டறிந்து தொடங்குங்கள், ஏனெனில் மூன்று நிலைகளும் வெவ்வேறாக நடக்கின்றன. உள்ளூர் துறைமுகத்துக்கான திசைதிருப்பல் அனுப்புதலை முடிவுக்குக் கொண்டுவருகிறது, வேறு இயந்திரத்துக்கான மொழிபெயர்ப்பு பாக்கெட்டை அசைவில் வைத்து கிளையண்டின் tuple-ஐ அர்த்தமுள்ளதாக வைத்திருக்கிறது.

இரு நெறிமுறைகளையும் பாருங்கள். UDP மற்றும் TCP வழியாக அடையக்கூடிய தீர்வான் இரண்டிலும் சோதிக்கப்படும், UDP-ஐ மட்டும் உள்ளடக்கும் விதித்தொகுப்பு பெரிய பதில்களுக்கு அமைதியான துளையை விட்டுச் செல்கிறது. ரவுட்டரின் சொந்த கட்டமைப்பு மேலாளர் உருவாக்கும் விதிகளும் கணக்கிடப்படுகின்றன, உருவாக்கப்பட்ட கோப்பைத் திருத்துவது பொதுவாக அடுத்த மறுஏற்றலுக்குத் தோற்கிறது.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

அந்த வெளியீடுகள் முறையே மூன்று கேள்விகளுக்குப் பதிலளிக்கின்றன: வினவலை எது மீண்டும் எழுதுகிறது, அதை எது பெறுகிறது, கேட்கும் சாக்கெட்டை எந்தச் செயல்முறை வைத்திருக்கிறது. உரிமையாளர் தெரிந்தபின் மேல்நிலைக் கொள்கைக்கு வாழ இடம் உண்டு.

தீர்வானுக்கு அதன் சொந்த வெளியேற்றக் கொள்கையைக் கொடுங்கள்

சில பெயர்களுக்கு மட்டும் சுரங்கப்பாதை தேவைப்படும்போது களம்-சார்ந்த மேல்நிலை மிகத் தூய்மையான கருவி. dnsmasq ஒரு களத்துக்கு வரம்பிடப்பட்ட server வரியை ஏற்கிறது, விருப்பத் தேர்வான இடைமுகம் அல்லது மூல முகவரியுடன் வினவலைத் தேர்ந்தெடுத்த சாதனத்திலிருந்து வெளியே அனுப்புகிறது. அந்த வழிகாட்டுதலே இரண்டாம் உரையாடலை VPN-ஐப் பின்தொடரச் செய்கிறது.

server=/corp.example/10.30.0.53@tun_work
log-queries

மேலே உள்ள களம், முகவரி, இடைமுகம் ஆகியவை உங்கள் சொந்த மதிப்புகளுக்கான இடம்காட்டிகள். களத் தேர்வும் வெளியேற்றக் கட்டுப்பாடும் தனித்தனி முடிவுகளாகவே இருக்கின்றன: வழித்தடம் இருக்க வேண்டும், மூல முகவரிக்கு மேல்நிலைத் தீர்வான் அனுமதி அளிக்க வேண்டும், தீச்சுவர் பதிலை அனுமதிக்க வேண்டும். இடைமுக வழிகாட்டல் மட்டும் fail-closed அல்ல, ஏனெனில் மறைந்த சுரங்கப்பாதை தீர்வானை வேறு வழியில் விழவிடலாம். தனிப்பட்டதாக இருக்க வேண்டிய பெயர்வெளியிலிருந்து எந்தப் பொது மாற்றையும் விலக்கி வையுங்கள்.

வரியை உருவாக்கப்பட்ட கோப்பில் அல்ல, ரவுட்டர் ஆதரிக்கும் கட்டமைப்பு உரிமையாளரிடம் வையுங்கள், இல்லையேல் அடுத்த மறுஏற்றல் சரிசெய்தலை அழிக்கும்.

பகிரப்பட்ட தேக்ககம் எதைப் பாதுகாக்க முடியாது

ஒரு தேக்ககத்துடன் ஒரு அனுப்புநர் ஒவ்வொரு LAN கிளையண்டுக்கும் சேவை செய்கிறார், அது சில வலைப்பிண்ணல்களுக்குத் தேவையான வேறுபாட்டை உடைக்கிறது. இரு கிளையண்டுகள் ஒரே பெயரை வெவ்வேறாகத் தீர்க்க வேண்டுமெனில், யார் கேட்டார்கள் என்பதை மீட்டெடுக்கப் பகிரப்பட்ட சாக்கெட்டுக்கு வழியில்லை. ஒவ்வொரு கிளையண்டுக்குமான கொள்கை தனித்தனி தீர்வான் நிகழ்வுகளிலோ அடையாளத்தைத் தக்கவைக்கும் அனுப்புதல் அம்சத்திலோ வாழ வேண்டும்.

தேக்ககப்படுத்திய பதிலும் புதிய வழியைப் பற்றிய சான்று அல்ல. மேல்நிலை வழித்தடம் உடைந்திருக்கும்போதே பதில் நினைவகத்திலிருந்து வரலாம்.

53-ஆம் துறைமுக விதிகள் DNS-ஐ HTTPS அல்லது TLS வழியாகப் பேசும் பயன்பாடுகளைப் பற்றி எதுவும் சொல்லவில்லை. அந்த வினவல்கள் ஒருபோதும் திசைதிருப்பலை அடைவதில்லை, எனவே 53-ஆம் துறைமுகத்தில் மட்டும் கட்டப்பட்ட கொள்கை போக்குவரத்தின் ஒரு துணைக்கணத்தை விவரிக்கிறது என்று ஆவணப்படுத்தப்பட வேண்டும்.

இரண்டாம் உரையாடலைச் சரிபாருங்கள், முதலாவதை அல்ல

நீங்கள் கட்டுப்படுத்தும் ஒரு பெயருடன் சோதித்து இரு பக்கங்களையும் பாருங்கள். கிளையண்ட் பக்கப் பிடிப்பு வினவல் LAN-ஐ விட்டது என்பதை நிரூபிக்கிறது; அதன் பின் எங்கே சென்றது என்பதை ரவுட்டர் பக்கம் மட்டுமே நிரூபிக்கிறது.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

ஒவ்வொரு முயற்சிக்கும் முன் தேக்ககத்தைக் காலி செய்யுங்கள், ஏனெனில் சூடான பதில் உடைந்த மேல்நிலையை மறைக்கிறது. TCP வழியாக மீண்டும் செய்யுங்கள், பின்னர் சுரங்கப்பாதையை அணைத்த நிலையில் மீண்டும் செய்யுங்கள், தீர்வான் தன் விருப்பமான வழி போனபோது என்ன செய்கிறது என்பதைப் பார்க்க. அந்தக் கடைசி நடத்தையே வடிவமைப்பு fail-closed-ஆ என்பதையோ வெறும் அதிர்ஷ்டமா என்பதையோ தீர்மானிக்கிறது.