Android இல் VPN கண்டறிதல்: tun0 மற்றும் ping ஏன் திசைதிருப்புகின்றன

இன்டர்ஃபேஸ் பெயர் ஒரு மரபு; ping ஒரு ஹோஸ்ட் அணுகக்கூடியதாக இருந்ததை நிரூபிக்கிறது. நெட்வொர்க் என்ன அறிவிக்கிறது என்று NetworkCapabilities-ஐக் கேட்டு, பின்னர் கால்பேக்குகளுக்கு பதிலளிக்கவும்.

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

கட்டுக்கதை: tun0 இருந்தால் VPN இயங்குகிறது

Android VPN ஆப்ஸ் என்பவை கணினிக்கு tun கோப்பு விவரிப்பியை வழங்கும் VpnService செயலாக்கங்கள். இன்டர்ஃபேஸ் பெயர் அதை உருவாக்கியவரிடமிருந்து வருகிறது: OpenVPN பொதுவாக tun0 உருவாக்குகிறது, PPTP மற்றும் L2TP ppp0 உருவாக்குகின்றன, WireGuard தனது இன்டர்ஃபேஸை சுரங்கப்பாதையின் பெயரால் அழைக்கிறது, IPsec சுரங்கப்பாதை பாரம்பரிய பெயரே காட்டாமல் இருக்கலாம். எனவே /proc/net/dev படிப்பதோ NetworkInterface பொருட்களை எண்ணுவதோ உண்மையை அல்ல, மரபைத் தேடுகிறது.

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

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

கட்டுக்கதை: வெற்றிகரமான ping என்பது சுரங்கப்பாதை போக்குவரத்தை எடுத்துச் செல்கிறது

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

ICMP மற்றும் TCP தனித்தனியாக வடிகட்டப்படுகின்றன. எதிரொலி கோரிக்கைகளை அனுமதித்து ஒரு சேவைக்குத் தேவையான TCP போர்ட்டை விட்டுவிடும் சுரங்கப்பாதை ping சோதனையில் தேர்ச்சிபெற்று ஆப்ஸில் தோல்வியடையும், அது சாதனத்தின் பண்பு அல்ல, எதிர்பக்க ஃபயர்வால் விதி. வெற்றிகரமான ping இன் ஒரே நேர்மையான வாசிப்பு, இந்த இலக்கு இந்த தருணத்தில் இந்த நெறிமுறைக்கு பதிலளித்தது என்பதே.

பிளாட்ஃபார்ம் உண்மையில் என்ன தெரிவிக்கிறது

API 21 முதல் ConnectivityManager.getAllNetworks() கணினி அறிந்த ஒவ்வொரு நெட்வொர்க்கையும் திருப்பித் தருகிறது, getNetworkCapabilities(network) அந்த நெட்வொர்க் என்ன அறிவிக்கிறது எனத் தெரிவிக்கிறது. VPN நெட்வொர்க் TRANSPORT_VPN கொண்டுள்ளது. எல்லா நெட்வொர்க்குகளிலும் சுழல்வது ஒரு கேள்விக்குப் பதிலளிக்கிறது: இந்த சாதனத்தில் இப்போது ஏதேனும் VPN இயங்குகிறதா?

இரண்டாவது, குறுகிய கேள்விக்கு வேறு அழைப்பு தேவை. getActiveNetwork() ஆப்ஸின் போக்குவரத்து இப்போது பயன்படுத்தும் நெட்வொர்க்கைத் திருப்பித் தருகிறது, அதில் அதே திறனைச் சோதிப்பது பதிலளிக்கிறது: எனது போக்குவரத்து VPN வழியாகச் செல்லுமா? இரண்டும் பொருந்தாமல் இருக்கலாம், அந்த முரண்பாடு தகவலளிக்கிறது. இயங்கும் ஆனால் தற்போதையதல்லாத VPN ஒவ்வொரு ஆப்ஸ் வழிமாற்றத்தையோ பிரிக்கப்பட்ட சுரங்கப்பாதை உள்ளமைவையோ சுட்டுகிறது, காணாமல் போன சுரங்கப்பாதையை அல்ல.

Network active = cm.getActiveNetwork();
NetworkCapabilities caps = cm.getNetworkCapabilities(active);
boolean viaVpn = caps != null
    && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

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

NetworkInfo API உடன் அதே கட்டுக்கதை

NetworkInfo உடன் ConnectivityManager.TYPE_VPN இந்தச் சோதனையின் இரண்டாம் தலைமுறை, அது ஒரு காரணத்தால் காலாவதியானது. நவீன வெளியீடுகளில் சுரங்கப்பாதை இணைக்கப்பட்டிருந்தும் VPN-க்குத் திருப்பித் தரப்படும் பொருள் null ஆக இருக்கலாம், எனவே null-ஐ «VPN இல்லை» எனக் கருதும் குறியீடு பதில் மிக முக்கியமான சாதனங்களில் அமைதியாக பொய்யான எதிர்மறையைத் தெரிவிக்கிறது.

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

கருத்துக்கணிப்புக்குப் பதிலாக கால்பேக்குகளுக்கு பதிலளிக்கவும்

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

NetworkRequest req = new NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .removeCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
    .build();
cm.registerNetworkCallback(req, callback);

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

பதில் இன்னும் உங்களுக்குச் சொல்ல முடியாதது

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

எனவே சோதனை பார்த்ததைப் பதிவு செய்யுங்கள், பூலியன் மட்டும் அல்ல. நெட்வொர்க் அடையாளங்காட்டி, அறிவிக்கப்பட்ட டிரான்ஸ்போர்ட்டுகள், அந்த நெட்வொர்க் செயலில் இருந்ததா என்பதைப் பதிவு செய்யுங்கள். «VPN கண்டறியப்படவில்லை» எனும் அறிக்கை பயனற்றது, ஆனால் ஒரு நெட்வொர்க் TRANSPORT_VPN அறிவித்தது ஆனால் getActiveNetwork() Wi-Fi திருப்பித் தந்தது எனும் அறிக்கை நேரடியாக வழிமாற்றத்தையோ விலக்கல் பட்டியலையோ சுட்டுகிறது, அது யாராவது செயல்படக்கூடிய திருத்தம்.

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