Android DNS சரியாகப் படிக்கவும்: நெட்வொர்க் வாரியாக, resolv.conf-இல் அல்ல

நீங்கள் சாதனத்தில் shell எடுக்கிறீர்கள், /etc/resolv.conf படிக்கிறீர்கள் அல்லது பழைய net.dns1 மதிப்பைத் தோண்டி எடுக்கிறீர்கள், ஒரு முகவரி கிடைக்கிறது. உங்கள் முன் இருக்கும் செயலி முற்றிலும் வேறொன்றின் வழியாகத் தீர்க்கிறது. தற்போதைய Android வெளியீட்டில் resolver நெட்வொர்க் வாரியாக உள்ளது: கணினி ஒவ்வொரு Network-க்கும் கொள்கையை வைத்து, கோரிக்கையை அனுப்பிய socket-க்கு அதைப் பயன்படுத்துகிறது. கோப்பும் பழைய பண்பும் எச்சங்கள், அவற்றில் எதுவும் உங்கள் வினவல் உண்மையில் எடுத்த பாதையை விவரிக்கவில்லை.

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

resolver ஒரு நெட்வொர்க்கிற்குச் சொந்தம், சாதனத்திற்கு அல்ல

Android 9 மற்றும் அதற்குப் பின் பெயர் தீர்வு socket இணைக்கப்பட்ட Network-ஐ அடிப்படையாகக் கொண்ட கணினி resolver வழியாகச் செல்கிறது. ஒவ்வொரு நெட்வொர்க்கும் அதன் சொந்த LinkProperties-ஐக் கொண்டுள்ளது, அந்தப் பண்புகள் அந்த நெட்வொர்க்கிற்கு மட்டும் DNS சேவையகப் பட்டியல், தேடல் டொமைன்கள் மற்றும் Private DNS நிலையை வைத்திருக்கின்றன. அந்த மாதிரியில் ஒரு கோப்பிலிருந்து படிக்கக்கூடிய ஒரே சாதன-அளவிலான பட்டியலுடன் பொருந்துவது எதுவும் இல்லை.

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

பாதிக்கப்பட்ட செயலியின் உள்ளேயிருந்து ஸ்னாப்ஷாட்டைப் படிக்கவும்

செயலியையே கேளுங்கள். Context மற்றும் வழக்கமான android.permission.ACCESS_NETWORK_STATE அனுமதி உள்ள முறை, கணினிப் பண்புகளைத் தொடாமல் ஸ்னாப்ஷாட்டைப் படிக்க முடியும்:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork உங்கள் செயல்முறையின் இயல்புநிலை நெட்வொர்க், சாதனத்தின் ஒரே நெட்வொர்க் அல்ல, அழைப்பவருக்குப் பயன்படக்கூடிய இயல்புநிலை இல்லாதபோது null ஆக இருக்கலாம். தடுக்கப்பட்ட இயல்புநிலை VPN வழக்கமான காரணம். isPrivateDnsActive அந்த நெட்வொர்க்கின் வினவல்கள் TLS வழியாகப் பெயரிடப்பட்ட resolver-க்குச் செல்கிறதா என்று சொல்கிறது, இது எளிய UDP 53 சோதனை என்ன காட்டும் என்பதை மாற்றுகிறது. API மேற்பரப்பு LinkProperties கீழ் ஆவணப்படுத்தப்பட்டுள்ளது, அதில் ஒவ்வொரு மதிப்பும் கட்டமைப்பின் ஸ்னாப்ஷாட், ஒரு குறிப்பிட்ட வினவல் ஒரு குறிப்பிட்ட சேவையகத்தை அடைந்தது என்பதற்கான சான்று அல்ல.

இயல்புநிலை நெட்வொர்க் வேலை செய்வது இல்லாதபோது

ஸ்னாப்ஷாட் இயல்புநிலைக்கு மட்டுமே பதிலளிக்கிறது. செயலி தன் செயல்முறையை அல்லது ஒரு socket-ஐ வேறு நெட்வொர்க்குடன் பிணைக்கலாம், பின்னர் தீர்வு அந்தத் தேர்வைப் பின்பற்றுகிறது, உங்கள் கண்டறிதல் இன்னும் இயல்புநிலையைத் தெரிவிக்கிறது. தன் சொந்த DNS-over-HTTPS resolver-ஐக் கொண்டு வரும் உலாவி கணினிப் பட்டியலைக் கேட்கவே இல்லை, எனவே அதன் பதில்கள் மீதமுள்ள சாதனத்தைப் பற்றி எதுவும் சொல்லவில்லை. பணி விவரக்குறிப்புச் செயலி தன் கொள்கையுடன் தனி பயனரின் கீழ் இயங்குகிறது. சேவையகங்களைக் குறைகூறும் முன் பிணைப்பைச் சரிபார்க்கவும்.

VPN ஒருங்கிணைப்பு மறுபாதி. dhcp-option DNS வரியை OpenVPN விவரக்குறிப்பில் ஏற்பதும் அந்த முகவரியை Android VPN நெட்வொர்க்கில் பதிவு செய்வதும் இரு தனி படிகள், சேவையகத்திற்கான விடுபட்ட வழி தவறான முகவரி போலவே அமைதியாகத் தோல்வியடைகிறது. மேம்பாட்டு இயந்திரத்திலிருந்து adb shell dumpsys connectivity build அனுமதிக்கும்போது அதே இணைப்புப் பண்புகளை நெட்வொர்க் வாரியாக அச்சிடுகிறது, இது குறியீடு எழுதாமல் பட்டியலை உறுதிப்படுத்துகிறது.

கட்டமைப்பை நீங்கள் செய்ய அனுமதிக்கப்பட்ட ஒரு தீர்வுடன் ஒப்பிடுங்கள்

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

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

இந்த முரண்பாடு எந்த அடுக்கிற்குச் சொந்தம் என்பதைச் சரிசெய்யுங்கள்

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

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

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