Android VpnService இல் பிளவு டன்னலிங்: உண்மையில் எதை வழிமாற்றலாம்

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

builder தளத்திற்கு என்ன கொடுத்தது என்பதை உறுதிப்படுத்துங்கள்

VpnService.Builder என்பது அறிவிப்புகளின் பட்டியல். establish() மெய்நிகர் இடைமுகத்திற்கு ParcelFileDescriptor திருப்பித் தருகிறது, addAddress மற்றும் addRoute இன் முன்னொட்டுகளுடன் பொருந்தும் போக்குவரத்தை மட்டுமே தளம் அந்த விவரிப்பானுக்கு அனுப்புகிறது; addDnsServer எந்த resolver-ஐக் கேட்க வேண்டும் என்பதை வாடிக்கையாளர்களுக்குச் சொல்கிறது. நீங்கள் சேர்த்த எல்லா முன்னொட்டுகளுக்கும் வெளியே உள்ள இலக்கு, இடைமுகம் என்ன வாக்குறுதி அளித்தாலும் உங்கள் ஆப்பை அடையாது. இந்த ஒரு உண்மையே குறியீட்டை மாற்றும் முன் பிளவு டன்னலிங் பழுதடைந்ததாக வரும் புகார்களில் பெரும்பாலானவற்றை விளக்குகிறது.

உங்கள் builder உருவாக்கிய முகவரி, வழி மற்றும் DNS பட்டியல்களைப் பதிவு செய்து, தோல்வியடையும் இலக்குகளுடன் ஒப்பிடுங்கள். நிர்வாக ஹோஸ்டிற்கான /32 ஒன்று இல்லாதது உடைந்த டன்னலை விட மிகவும் பொதுவானது. பட்டியல் சரியாக இருந்தால் தொடரவும்; தவறாக இருந்தால் மீதமுள்ள சரிபார்ப்புப் பட்டியல் வீண் முயற்சி.

excludeRoute API 33 முதல் மட்டுமே

இலக்கு அடிப்படையிலான விலக்கு என்பது அடிக்கடி ஆதரவு இழையாக மாறும் கோரிக்கை. builder.excludeRoute(IpPrefix) API 33 இல் வந்தது; அதற்கு முன் ஆதரிக்கப்படும் ஒரே தோராயம், விலக்கப்பட்ட முன்னொட்டைத் தவிர அனைத்திற்கும் வழிகளைச் சேர்ப்பது, அதாவது நிரப்பு முன்னொட்டுகளை நீங்களே கணக்கிட வேண்டும். இரண்டு அழைப்புகளும் கண்ணாடிப் பிம்பங்கள் அல்ல: ஒன்று இடைமுகத்தின் வழித் தொகுப்பிலிருந்து கழிக்கிறது, மற்றது தொகுப்பை பூஜ்ஜியத்திலிருந்து கட்டுகிறது, பழைய சாதனம் தெரியாத அழைப்பை வீசும் அல்லது அமைதியாகப் புறக்கணிக்கும். Build.VERSION.SDK_INT அடிப்படையில் கிளை பிரித்து இரு வழிகளையும் உண்மையான வன்பொருளில் சோதிக்கவும்.

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

ப்ராக்ஸி அங்கீகார விவரங்களை வெளிப்படுத்த முடியாது

setHttpProxy(ProxyInfo) இடைமுகத்தை HTTP அல்லது SOCKS ப்ராக்ஸிக்கு திருப்புகிறது, PAC URL ஒவ்வொரு இலக்கிற்கும் அவற்றுக்கிடையே தேர்ந்தெடுக்கலாம். ProxyInfo அல்லது PAC வடிவம் எதுவும் பயனர் பெயரையும் கடவுச்சொல்லையும் கொண்டு செல்லாது, எனவே அங்கீகாரம் தேவைப்படும் ப்ராக்ஸி தள API-க்கு வெளியே உள்ளது. அது தேவைப்படும் ஆப்கள் பொதுவாக userspace ஸ்டாக், tun2socks அல்லது அதுபோன்ற இயந்திரத்தை உள்ளடக்கி 407 சவாலுக்குத் தாங்களே பதிலளிக்கின்றன.

அந்தத் தேர்வுக்கு விளைவுகள் உண்டு. userspace ஸ்டாக் நீங்கள் அதை நோக்கி வழிமாற்றும் போக்குவரத்தை மட்டுமே பார்க்கிறது, எனவே அது அதே விவரிப்பான் எல்லைக்குள் வாழ வேண்டும், தனது சொந்த uplink சாக்கெட்டுக்கு அதே protect() தேவையைப் பெறுகிறது. protect()-ஐ விட்டுவிட்டால் டன்னல் தனது சொந்தப் போக்குவரத்தைப் பிடிக்கும், அது முதல் பாக்கெட்டுக்குப் பின் நிற்கும் கைகுலுக்கலாகத் தெரியும். அங்கீகார விவரங்களைக் கோரும் ப்ராக்ஸிக்கு எதிராகச் சோதிக்கவும், ஏனெனில் திறந்த ப்ராக்ஸி தளத்தின் வழியில் கடந்து எதையும் நிரூபிக்காது.

ஆப் வாரியான பட்டியல்களும் DNS-உம் அறிவிப்புகளே

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

DNS அதே முறையைப் பின்பற்றுகிறது. addDnsServer ஒரு resolver முகவரியை அறிவிக்கிறது; அது உங்கள் ஆப் கேள்விகளுக்குப் பதிலளிக்க அனுமதிக்காது. பெயர்களை நீங்களே தீர்க்க விரும்பினால் ஒரு resolver இயக்கி அதன் முகவரியை டன்னலுக்குள் வழிமாற்றுங்கள். நிலையான ஹோஸ்ட் பெயருக்கு DoT அல்லது DoH பயன்படுத்தும் ஆப்கள் நீங்கள் அறிவித்த முகவரியைத் தவிர்க்கலாம், எனவே கேள்வியின் பாதையையும் தடுத்துப் பிடிக்காத வரை பெயர் தீர்வை சிறந்த முயற்சியாகக் கருதுங்கள்.

Manifest, always-on மற்றும் நான்கு படி சோதனை

தகுதி manifest-இல் அறிவிக்கப்படுகிறது: BIND_VPN_SERVICE, android.net.VpnService intent வடிகட்டி, டன்னல் பின்னணியில் நீடிக்க வேண்டும் என்றால் foreground சேவை. Always-on VPN கூடுதலாகத் தூய்மையான onRevoke தேவைப்படுகிறது, ஏனெனில் பயனர் அமைப்புகளை மாற்றும்போது அல்லது வேறு ஆப் கட்டுப்பாட்டை எடுக்கும்போது கணினி அதை அழைக்கிறது.

சரிபார்ப்புகளை வரிசையாக இயக்கி முதல் தோல்வியில் நிறுத்துங்கள். முதலில், builder-க்கு வழங்கப்பட்ட முகவரி, வழி மற்றும் DNS பட்டியல்களை வெளியே எடுங்கள். இரண்டாவதாக, establish() ஒரு விவரிப்பானைத் திருப்பித் தந்ததையும் போக்குவரத்து சாக்கெட் பாதுகாக்கப்பட்டதையும் உறுதிப்படுத்துங்கள். மூன்றாவதாக, சேர்க்கப்பட்ட முன்னொட்டுக்குள் ஒரு இலக்கையும் விலக்கப்பட்ட முன்னொட்டுக்குள் ஒன்றையும் கோருங்கள். நான்காவதாக, உங்கள் resolver மட்டுமே தீர்க்கக்கூடிய ஹோஸ்ட் பெயரைக் கேட்டு எந்த resolver உண்மையில் பதிலளித்தது என்பதைச் சரிபார்க்கவும்.

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

VpnService.Builder குறிப்பு builder-இன் முழு மேற்பரப்பையும் பட்டியலிடுகிறது. அதற்கு அப்பால் தேவைப்படுவது வேறு API, வேறு ஆப் அல்லது உங்கள் சொந்த userspace ஸ்டாக், அது பிளவு-டன்னல் பிழை அல்ல, வடிவமைப்பு முடிவு.