VPN kill switch port 53-ஐத் தடுக்கும்போது DNS தீர்க்கப்படுவதில்லை
Kill switch DNS-ஐ வேண்டுமென்றே தடுக்கலாம். சுரங்கப்பாதைக்குள் மட்டும் தீர்ப்பதை உள்ளூர் resolver விதிவிலக்குடன் ஒப்பிட்டு, எந்த அடுக்கு உண்மையில் தோல்வியடைந்தது என்பதைத் தீர்மானிக்கவும்.
Kill switch சுரங்கப்பாதையை வீழ்த்தும்போது DNS பாதையையும் கூடவே எடுத்துச் செல்கிறது, மீதமிருக்கும் resolver நீங்கள் எதிர்பார்ப்பது அரிதாகவே. இரண்டு வடிவமைப்புகள் அந்தத் தருணத்தை மிகவும் வேறுபட்ட முறையில் கையாள்கின்றன: சுரங்கப்பாதைக்குள் இல்லாத ஒவ்வொரு DNS பாக்கெட்டையும் தடுப்பது, அல்லதுஒரு resolver-ஐ விதிவிலக்காக நிற்க வைப்பது. இரண்டும் நியாயப்படுத்தக்கூடியவை. உலாவி தாவலில் இருந்து அறிகுறிகள் கிட்டத்தட்ட ஒரே மாதிரியாகத் தெரிகின்றன, எனவே முதல் வேலை நீங்கள் உண்மையில் எந்த வடிவமைப்பைப் பயன்படுத்தினீர்கள் என்பதைக் கண்டறிவது.
அந்த வேறுபாட்டை என் கண் முன்னே வைத்திருக்கிறேன், ஏனெனில் திருத்தம் ஒவ்வொரு நிலையிலும் எதிர்மறையானது. ஒரு வடிவமைப்புக்கு பரந்த விதிவிலக்கு தேவை, மற்றொன்றுக்கு குறுகியது. ஊகிப்பது உங்களுக்கு தனியுரிமையையோ அரை நாளையோ இழக்கச் செய்யும்.
ஒரே பழுதுக்கு இரண்டு DNS வடிவமைப்புகள்
வடிவமைப்பு A resolver-ஐ சுரங்கப்பாதைக்குப் பின்னால் உள்ள மற்றொரு சேவையாகவே கருதுகிறது. firewall விதிகள் UDP மற்றும் TCP 53-ஐ சுரங்கப்பாதை இடைமுகத்தில் மட்டுமே அனுமதிக்கின்றன, வாடிக்கையாளருக்கு வழங்கப்படும் முகவரி சுரங்கப்பாதைக்குள் உள்ள resolver ஆகும். சுரங்கப்பாதை விழும்போது தேடல்கள் நிற்கின்றன, அது குறையல்ல, எதிர்பார்க்கப்பட்ட முடிவு.
வடிவமைப்பு B உள்ளூர் வலையமைப்பில் resolver-ஐ அணுகக்கூடியதாக வைத்திருக்கிறது, பொதுவாக 192.168.1.1-இல் உள்ள router அல்லது 127.0.0.53-இல் உள்ள இயக்க முறைமை stub, பெயர் தீர்வு சுரங்கப்பாதையுடன் சாகக்கூடாது என்ற அடிப்படையில். வீட்டு LAN-இல் இது வசதியானது, அங்கு router முழு வீட்டிற்கும் தீர்க்கிறது. ஹோட்டல் அல்லது விமான நிலைய Wi-Fi-இல் அதே விதிவிலக்கு வேறொருவரின் சேவையகத்தைச் சுட்டுகிறது, நீங்கள் தட்டச்சு செய்யும் ஒவ்வொரு பெயரும் வெளிப்படுகிறது, உங்கள் இணையப் போக்குவரத்து தடுக்கப்பட்டிருந்தாலும்.
எல்லை என்பது resolver யாருடையது என்பதுதான். உள்ளூரை நம்பினால், விதிவிலக்கு சிறிய மற்றும் நேர்மையான துளை. நம்பவில்லை என்றால், சுரங்கப்பாதை-மட்டும் வடிவமைப்பே நிலைத்து நிற்கிறது, விலை என்பது விழுந்த சுரங்கப்பாதை எல்லாப் பெயர்களையும் கூடவே எடுத்துச் செல்வதுதான்.
VPN வாடிக்கையாளரின் சொந்தத் தேடல் இன்னும் ஏன் வேலை செய்கிறது
சுரங்கப்பாதை உருவாகும் முன் வாடிக்கையாளர் நுழைவாயிலின் host பெயரைத் தீர்க்க வேண்டும், எனவே கடுமையான தடை வாடிக்கையாளரின் தொடக்கப் பாதையை மூடக்கூடாது. பெரும்பாலான வாடிக்கையாளர்கள் முனை முகவரியைத் தற்காலிகச் சேமிப்பில் வைக்கின்றனர் அல்லது அந்த ஒரு host-க்கு ஆவணப்படுத்தப்பட்ட தொடக்க விதிவிலக்கை வழங்குகின்றனர். உங்கள் விதித் தொகுப்பு அந்தத் தேடலைத் தடுத்தால், சுரங்கப்பாதை ஒருபோதும் திரும்பாது, பதிவுகள் தன் சேவையகத்தை அடைய முடியாத வாடிக்கையாளரைக் காட்டும்; இது DNS இன் அல்ல, கொள்கையின் குறை.
பிரிக்கப்பட்ட DNS இது தோன்றும் இரண்டாவது இடம். வாடிக்கையாளர் உள் மண்டலத்தை தனியார் resolver-க்குத் தள்ளி மற்ற அனைத்தையும் கணினி resolver-இடம் விடுகிறார். வீழ்ச்சிக்குப் பின் பொது பெயர்கள் இன்னும் தீர்க்கப்படலாம், ஆனால் உள் பெயர்கள் நேரம் முடிந்து தோல்வியடையும், ஏனெனில் தனியார் மண்டலத்திற்கு இனி வழி இல்லை. பயனருக்கு அது "VPN இணையத்தை உடைத்தது"; resolver பதிவுக்கு அது ஒருபோதும் வராத வினவல்.
systemd-resolved-இன் கீழ் பிரிவை நேரடியாகப் பார்க்கலாம். resolvectl status ஒவ்வொரு இணைப்பின் DNS சேவையகங்களையும் வழிமாற்றுக் களங்களையும் பட்டியலிடுகிறது, சுரங்கப்பாதை கீழே போன பிறகும் உள் களம் இனி இல்லாத இணைப்பில் உள்ள சேவையகத்தைச் சுட்டிக்கொண்டே இருக்கும். 127.0.0.53-இல் உள்ள stub வினவலை இன்னும் ஏற்கிறது, பின்னர் பதிலளிக்காத மேல்நிலைக்காகக் காத்திருக்கிறது, அதனால்தான் தோல்வி உடனே திரும்பாமல் சில வினாடிகள் எடுக்கிறது.
மறையாக்கப்பட்ட DNS பாக்கெட் வடிகட்டியைத் தவிர்க்காது
DNS over HTTPS மற்றும் DNS over TLS 443 மற்றும் 853-இல் பயணிக்கின்றன, எனவே port 53-ஐத் தடுக்கும் விதி அவற்றைப் பற்றி எதுவும் சொல்லவில்லை. port அடிப்படையில் "DNS"-ஐத் தடுப்பது port பற்றிய கொள்கை, பெயர் தீர்வு பற்றியது அல்ல. உங்கள் kill switch சுரங்கப்பாதைக்கு வெளியே உள்ள எல்லாப் போக்குவரத்தையும் தடுத்தால், DoH தற்செயலாக மூடப்படுகிறது. captive portal அல்லது பொது resolver-க்கு விதிவிலக்கு விட்டிருந்தால், மூடப்படாது.
வாடிக்கையாளர் பக்கக் கட்டுப்பாடுகளே மலிவான நெம்புகோல். canary பெயர்use-application-dns.net தீர்க்கப்படாதபோது Firefox தன் DoH resolver-ஐ விட்டுவிடுகிறது, அதனால்தான் நிர்வகிக்கப்படும் வலையமைப்புகள் அந்தக் களத்தை NXDOMAIN ஆக வெளியிடுகின்றன; நிறுவனக் கொள்கை அதை அணைத்து பின்னிப் பூட்டவும் முடியும். Android Private DNS மற்றும் Chrome இன் பாதுகாப்பான DNS-க்கு அவற்றின் சொந்த சுவிட்சுகளும் இயல்புநிலைகளும் உள்ளன. அவற்றை அணைப்பது resolver முகவரிகளைத் துரத்துவதை விட நம்பகமானது, ஏனெனில் முகவரிப் பட்டியல் மாறும், உங்கள் விதித் தொகுப்பு மாறாது.
இதன் கசிவுடன் எந்தத் தொடர்பும் இல்லாத பதிப்பும் உள்ளது. பின்னப்பட்ட resolver உள்ள பயன்பாட்டிற்கு அங்கு செல்ல வலையமைப்புப் பாதை இன்னும் தேவை. மறையாக்கம் மாற்றுவது வினவலை யார் படிக்கலாம் என்பதை, பாக்கெட் இயந்திரத்திலிருந்து வெளியேற முடியுமா என்பதை அல்ல, எனவே முழு சாதனத்திற்குமான தடை அமைப்பைத் தொடாமலேயே அதை வீழ்த்துகிறது.
அறிகுறியை அடுக்குடன் பொருத்துங்கள்
பெரும்பாலான அறிக்கைகள் ஒரே வாக்கியமாக வருகின்றன, அந்த வாக்கியம் பொதுவாக அடுக்கை ஏற்கனவே பெயரிடுகிறது. கீழே உள்ள அட்டவணை எந்த விதியையும் தொடும் முன் நான் கடப்பது; நோக்கம் வினவல் தடுக்கப்பட்டதா, தவறாக வழிமாற்றப்பட்டதா, அல்லது அனுப்பப்படவே இல்லையா என்பதை முடிவு செய்வது.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
முதல் இரண்டு வரிசைகளே மக்கள் தவறாகக் கண்டறிவது. அமைதியான வீழ்ச்சியும் மறுப்பும் உலாவியில் ஒரே மாதிரி "DNS உடைந்தது" போலத் தெரிகின்றன, ஆனால் அவற்றில் ஒன்று மட்டுமே உங்கள் kill switch தன் வேலையைச் செய்கிறது என்பதைக் குறிக்கிறது. மறுப்பு என்பது ஏதோ பதிலளித்தது என்பதாகும், எனவே தடை நீங்கள் நினைக்கும் இடத்தில் இல்லை.
resolver கொள்கையை மீட்டெடுத்து, பின்னர் நிரூபியுங்கள்
வடிவமைப்பைச் சரிசெய்யுங்கள், அறிகுறியை அல்ல. சுரங்கப்பாதை-மட்டும் தீர்வுக்கு சுரங்கப்பாதை இடைமுகத்தில் 53-ஐ அனுமதியுங்கள், சுரங்கப்பாதை உள்ளமைவுடன் உள் resolver-ஐத் தள்ளுங்கள், இயற்பிய இணைப்பை எந்த DNS அனுமதியும் இல்லாமல் விடுங்கள். wg-quick-இல் resolver-ஐ இடைமுக உள்ளமைவில் எழுதும் வரிDNS = ஆகும், எனவே அதை விட்டுவிடும் சுரங்கப்பாதை பழைய resolver-ஐ அதே இடத்தில் வைத்து ஒவ்வொரு வினவலையும் தவறான பாதைக்கு அனுப்புகிறது. wg-quick கையேடு ஒவ்வொரு தளத்திற்கும் அந்த நடத்தையை ஆவணப்படுத்துகிறது.
பின்னர் இந்த வரிசையில் சரிபார்க்கவும். Linux-இல்resolvectl status செயலில் உள்ள இணைப்பைக் காட்டுகிறது, dig +short example.com பொது பெயரைச் சோதிக்கிறது, dig @10.8.0.1 internal.example.com தனியார் பெயரைச் சோதிக்கிறது, மற்றும்sudo tcpdump -ni any port 53 இரண்டையும் இயக்கும்போது பாக்கெட்டுகள் எந்த இடைமுகத்தைப் பயன்படுத்துகின்றன என்பதைக் காட்டுகிறது. Windows-இல்Get-DnsClientServerAddress -AddressFamily IPv4 மற்றும்Resolve-DnsName example.com அதே இரண்டு உண்மைகளைத் தருகின்றன: யார் உள்ளமைக்கப்பட்டுள்ளார், யார் பதிலளிக்கிறார்.
எதிர்மறைச் சோதனையுடன் முடிக்கவும். சுரங்கப்பாதையைத் துண்டிக்கவும், புதிய பொது பெயர் தோல்வியடைவதை உறுதி செய்யவும், தனியார் பெயர் தோல்வியடைவதை உறுதி செய்யவும், மற்றும்port 53 இன் எந்தப் பாக்கெட்டும் இயற்பிய தகவமைப்பியை விட்டு வெளியேறவில்லை என்பதை உறுதி செய்யவும். தற்காலிகச் சேமிப்பில் உள்ள பதில்களுக்கு மட்டும் நிலைக்கும் தடை எதற்கும் நிலைக்காது.
டிக்கெட்டை மூடும் முன் சரிபார்ப்புப் பட்டியல்:
- பழுதின் போது பயன்படுத்தப்பட்ட resolver கொள்கை நோக்குவதே.
- வாடிக்கையாளரின் சொந்த முனைத் தேடல் தற்காலிகச் சேமிப்பு அல்லது விதிவிலக்கு மூலம் இன்னும் அனுமதிக்கப்படுகிறது.
- DoH மற்றும் DoT தடையால் மூடப்பட்டுள்ளன அல்லது கொள்கையால் முடக்கப்பட்டுள்ளன.
- சுரங்கப்பாதை போன பிறகு தனியார் களங்கள் திறந்த நிலையில் அல்ல, மூடிய நிலையில் தோல்வியடையும்.