Android செயலி VPN-க்கு வெளியே பெயர்களைத் தீர்க்கிறது: பிணைப்பு சரிபார்ப்புப் பட்டியல்

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

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

படி 1: செயலி எந்த நெட்வொர்க்கில் உள்ளது என்பதை நிரூபிக்கவும்

நிலைப் பட்டியை அல்ல, செயலியின் சொந்தப் பார்வையைப் படியுங்கள். ConnectivityManager இலிருந்து செயலில் உள்ள நெட்வொர்க், அதன் LinkProperties, DNS சேவையகங்களின் பட்டியல் மற்றும் தனியார் DNS அமைப்பைப் பெறுங்கள். பட்டியலில் VPN இன் resolver இருந்தால், செயலிக்கு அதற்கான பாதை உள்ளது; அதில் Wi-Fi இன் resolver இருந்தால், அந்தச் செயல்முறைக்கு சுரங்கப்பாதை இயல்புநிலை நெட்வொர்க் அல்ல.

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

படி 2: VPN போக்குவரத்தைக் கோரி செயல்முறையைப் பிணைக்கவும்

செயலி சுரங்கப்பாதையின் resolver-ஐ கட்டாயம் பயன்படுத்த வேண்டியிருந்தால், VPN போக்குவரத்துடன் கூடிய நெட்வொர்க்கைக் கோரி, கால்-பேக்கில் செயல்முறையைப் பிணைக்கவும், நெட்வொர்க் எப்போது வரும் என்று குறியீடு ஊகிக்காதபடி:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

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

படி 3: பிணைப்பை தேவைக்கு மட்டும் வரம்பிடுங்கள்

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

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

படி 4: CONNECTED கட்டுப்பாட்டை நம்பாதீர்கள்

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

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

படி 5: சான்றுகளைப் பதிவு செய்து வரம்பை மீண்டும் சோதிக்கவும்

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

நீங்கள் ஆதரிக்கும் மிகப் பழைய Android பதிப்பிலும் ஒரு தற்போதைய வெளியீட்டிலும் இதை மீண்டும் செய்யுங்கள். இயல்புநிலைப் பாதையைச் சரியாகத் தோற்றமளிக்கச் செய்யும் resolver நடத்தை சாதனங்களும் பதிப்புகளும் வேறுபடும் சரியான இடமாகும், புதிய சோதனைச் சாதனத்தில் மட்டும் தேர்ச்சி பெறும் பில்ட் நீங்கள் அனுப்பும் வரம்புக்கு சரிபார்க்கப்படவில்லை. adb shell dumpsys connectivity தோல்வியை மீண்டும் உருவாக்கும்போது சாதனம் எந்த நெட்வொர்க்குகள் மற்றும் திறன்களைத் தெரிவிக்கிறது என்பதை விரைவாக உறுதிப்படுத்தும் வழியாகும்.

தொடர்புடைய கட்டுரைகள்