ரவுட்டரின் சொந்த DNS VPN சுரங்கத்தை ஏன் தவிர்க்கிறது?

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

பாக்கெட் பிடிப்பு உண்மையில் எந்த ஓட்டத்திற்கு சொந்தம்

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

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

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

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

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

கொள்கை வழி இரண்டாம் வினவலை ஏன் ஒருபோதும் பார்ப்பதில்லை

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

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

pfSense தீர்வி தனது மேல்நோக்கு பாதையை எங்கு தீர்மானிக்கிறது

pfSense இந்தப் பிரிவைத் தெரியும்படி செய்கிறது. கிளையண்ட் போக்குவரத்தைக் கொள்கை வழியாக VPN நுழைவாயில் வழியாக அனுப்பலாம், ஆனால் ஃபயர்வாலின் சொந்தப் போக்குவரத்து LAN விதிகளுக்குப் பதிலாக தீர்வியின் வெளியேற்ற அமைப்பைப் பின்பற்றுகிறது. வலை இடைமுகத்தில் அந்த அமைப்பு Services > DNS Resolver > Outgoing Network Interfaces கீழ் உள்ளது, அதன் மதிப்பு தீர்வி மேல்நோக்கு வினவல்களுக்குப் பயன்படுத்தக்கூடிய இடைமுகங்களின் பட்டியலாகும்.

அங்கே சுரங்க இடைமுகத்தைப் பெயரிடுவதும், அந்த இடைமுகத்தை மட்டும் பெயரிடுவதுமே ரவுட்டரின் சொந்தத் தேடல்களைச் சுரங்கத்தைப் பின்பற்றச் செய்கிறது. இயல்புநிலையில் விட்டால், தீர்வி வழித்தட அட்டவணையிலிருந்து வெளியேற்றத்தைத் தேர்ந்தெடுக்கும், இரட்டை WAN அல்லது VPN புரவலனில் அது பெரும்பாலும் WAN ஆகும்.

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

அமைப்புக்கு முன் தோல்வி நடத்தையைத் தேர்ந்தெடுக்கவும்

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

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

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

இரு பாதைகளையும் சோதித்து முடிவுகளைத் தனித்தனியாக வைத்திருங்கள்

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

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

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

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

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