உங்கள் Android VpnService சுரங்கப்பாதை டிராஃபிக்கை ரூட்டு செய்வதை ஏன் நிறுத்துகிறது

Android VpnService பற்றிய நான்கு ஊகங்கள் ஒருமுறை என் வாரத்தின் பெரும்பகுதியை எடுத்துக்கொண்டன, அவற்றில் ஒன்றும் வலைப்பின்னல் நெறிமுறையைப் பற்றியதல்ல. செயலி இணைந்துள்ளது என்றது, சாவி சின்னம் நிலைப்பட்டியில் அமர்ந்திருந்தது, டிராஃபிக் இன்னும் சாதாரண பாதை வழியாகவே வெளியேறியது. சுரங்கப்பாதையை நான் நிறுத்தும் வரை அது என்னுடையது என்றும், நான் சேர்த்த பாதைகளே எனக்குக் கிடைக்கும் பாதைகள் என்றும், stopSelf அழைத்தால் இடைமுகமும் அதனுடன் கீழே இறங்கும் என்றும் நான் தொடர்ந்து ஊகித்தேன். சேவை ஆவணப்படுத்தப்பட்டபடியே நடந்துகொண்டது. உடைந்த பகுதி என் மன மாதிரி.

கட்டுக்கதை 1: நீங்கள் அதை நிறுத்தும் வரை சுரங்கப்பாதை நின்றுகொண்டிருக்கும்

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

VpnService குறிப்பு தெளிவாகக் கூறுகிறது, செயலிக்கு ஏற்கனவே ஒப்புதல் இருந்தால் prepare() null திருப்பித் தரும், பயனர் இன்னும் அனுமதிக்க வேண்டியிருந்தால் Intent தரும். அந்த ஒப்புதல் நீங்கள் நோக்கத்தை startActivityForResult() வழியாக வழங்கினால் மட்டுமே வரும். இந்த கையளிப்பைத் தவிர்த்தால் establish() null தரும், இது அனுமதிச் சிக்கலாக அல்லாமல் அமைதியான தோல்வியாகவே படிக்கப்படுகிறது.

Always-on VPN நீங்கள் கட்டுப்படுத்தாத ஒரு உரிமையாளரைச் சேர்க்கிறது. கணினி துவக்கத்திற்குப் பிறகு அல்லது செயலிழப்பிற்குப் பிறகு சுரங்கப்பாதையைத் திரும்பக் கொண்டுவர முடியும், மேலும் பயனர் கையால் தொடங்கிய VPN செயலியை அது முந்திச் செல்கிறது. onRevoke() உங்கள் சாதாரண மூடுதலின் அதே வளங்களை மூடும்படி கட்டமைக்கவும், அதை மூலை வழக்காக அல்லாமல் முதன்மை நிறுத்தும் பாதையாகக் கருதவும். பயனர்கள் VPN செயலிகளை மாற்றுகிறார்கள்; உங்கள் குறியீடு அதைத் தாங்க வேண்டும்.

கட்டுக்கதை 2: addRoute நீங்கள் பட்டியலிட்டதைச் சரியாகப் பிடிக்கிறது

எந்தப் பொதிகள் உங்கள் விவரிப்பானை அடைகின்றன என்பதைப் பாதைகள் தீர்மானிக்கின்றன, எல்லைப் பிழை சில டிராஃபிக் சுரங்கப்பாதை வழியாகவும் சில அதன் வழியாகவும் செல்லாத எரிச்சலூட்டும் நிலையை உருவாக்குகிறது. addRoute("0.0.0.0", 0) முழு IPv4 ஐயும் எடுக்கிறது, அதாவது இப்போது ஒவ்வொரு பொதியும் உங்களிடம் வருகிறது, அதை முன்னோக்கி அனுப்ப வேண்டும் அல்லது நீக்க வேண்டும். ஒரு ஹோஸ்ட்டிற்கான /32 கிட்டத்தட்ட எதையும் எடுப்பதில்லை, மற்ற அனைத்தும் உங்கள் VPN ஒருபோதும் நிறுவப்படாதது போலவே நடந்துகொள்கின்றன.

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

DNS அதே தர்க்கத்தைப் பின்பற்றுகிறது. addDnsServer() உடன் சேர்க்கப்பட்ட சேவையகங்கள் சுரங்கப்பாதையின் தீர்வியைப் பயன்படுத்தும் செயலிகளுக்குச் செல்கின்றன, அதேசமயம் சொந்த குறியாக்கப்பட்ட DNS முனைப்புள்ளி அல்லது ஹோஸ்ட்பெயரில் அமைக்கப்பட்ட Private DNS உள்ள செயலி அவற்றை முற்றிலும் புறக்கணிக்கிறது. பெயர்கள் ஒரு செயலிக்குத் தோல்வியடைந்து மற்றொன்றுக்கு வேலை செய்யும்போது, ஒரு பாதையைத் தொடுவதற்கு முன்பே தீர்வியின் பாதையைச் சரிபார்க்கவும்.

கட்டுக்கதை 3: ஒவ்வொரு செயலிக்குமான விதிகள் இரு பக்கமும் திருப்பக்கூடிய ஒரு சுவிட்சு

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

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

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

கட்டுக்கதை 4: stopSelf சுரங்கப்பாதையை முடிக்கிறது

இல்லை. இடைமுகம் establish() திருப்பித் தரும் விவரிப்பானில் வாழ்கிறது, அந்த விவரிப்பான் திறந்திருக்கும்போது சேவைப் பொருள் இறக்கலாம். முதலில் ParcelFileDescriptor ஐ மூடுங்கள், குறிப்பை விடுங்கள், படிப்பு மற்றும் எழுத்து இழைகளை இணைக்கவும் அல்லது குறுக்கிடவும், பிறகு stopForeground(true) மற்றும் stopSelf() ஐ அந்த வரிசையில் அழைக்கவும்.

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

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

சுரங்கப்பாதை இறந்தது போலத் தெரியும்போது என்ன சரிபார்க்க வேண்டும்

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

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