Android 12 மற்றும் IKEv1 VPN: தொடக்க பதிப்பு, IKEv2, மூன்றாம் தரப்பு பயன்பாடுகள்

இரண்டு தொலைபேசிகளும் அமைப்புகளில் Android 12 ஐக் காட்டுகின்றன, அவற்றில் ஒன்று மட்டுமே உங்கள் நுழைவாயில் வழங்கும் பழைய IPsec XAuth சுயவிவரத்தை இன்னும் தொடங்குகிறது. வேறுபாடு பயனர் அடையக்கூடிய அமைப்பு அல்ல: உள்ளூர் பாரம்பரிய IKEv1 பாதையைத் தடுக்கும் பாதுகாப்பு, சாதனம் வழங்கப்பட்ட SDK நிலையைப் பார்க்கிறது, அது இப்போது இயக்கும் வெளியீட்டை மட்டுமல்ல. அந்த ஒரு விவரம் குழு ஒப்பீடு அர்த்தமுள்ளதா என்பதைத் தீர்மானிக்கிறது, மேலும் மூன்று இடம்பெயர்வு பாதைகளில் உங்களுக்கு உண்மையில் எது தேவை என்பதையும் அதுவே தீர்மானிக்கிறது.

இரண்டு Android 12 தொலைபேசிகள் ஒரே சோதனை நிலை அல்ல

புதிய சாதனங்கள் பாரம்பரிய IKEv1 சுயவிவரங்களைத் தொடங்குவதை நிறுத்திய AOSP மாற்றம் DEVICE_INITIAL_SDK_INT ஐ Android S உடன் ஒப்பிடுகிறது, அதாவது API 31. உள்ளூர் பாரம்பரிய தொடக்கப் பாதையில், தகுதியான சுயவிவரம் பயனுள்ள இணைப்பு ஏற்படுவதற்கு முன்பே ஆதரவில்லாத செயல்பாடு தோல்வியை எழுப்புகிறது. Android 11 உடன் வந்து பின்னர் புதுப்பிக்கப்பட்ட தொலைபேசி அந்தப் பாதுகாப்பை இன்னும் கடக்கிறது; Android 12 உடன் அறிமுகமான மாதிரி கடக்காது.

பிழைத்திருத்தம் இயக்கப்பட்ட சாதனத்தில் அந்த இரண்டு எண்களையும் படிக்கலாம்:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

பாதை ஒன்று: உள்ளூர் பாரம்பரிய அடுக்கை இன்னும் இயங்கும் இடத்தில் வைத்திருங்கள்

பாரம்பரிய அடுக்கு என்பது கணினி VPN திரையிலிருந்து IPsec XAuth PSK, IPsec Hybrid RSA மற்றும் L2TP/IPsec PSK சுயவிவரங்களைப் படிப்பதாகும். API 31 க்குக் கீழே வழங்கப்பட்ட சாதனத்தில் புதுப்பிப்புக்குப் பின்னும் அது சாத்தியமான பாதையாகவே உள்ளது, அதனால்தான் பழைய தொலைபேசியில் செய்யும் சோதனை வெற்றிபெறலாம், புதிய தொலைபேசி அதே சுயவிவரத்தை நிராகரிக்கிறது.

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

பாதை இரண்டு: தள IKEv2 சுயவிவரங்கள்

IKEv2 க்கான Android இன் பொது வழங்கல் மாதிரி வேறு ஒரு பொருள், பெயர் மாற்றப்பட்ட IKEv1 சுயவிவரம் அல்ல. IKEv2 சுயவிவரங்களுக்கான தள API API 30 உடன் வந்தது, நுழைவாயில் வழங்கும் அங்கீகார முறையுடன் IKEv2 ஐ எதிர்பார்க்கிறது, பொதுவாக சான்றிதழ் அடிப்படையிலானது அல்லது EAP. IKEv1 XAuth அல்லது Hybrid இலிருந்து IKEv2 க்கு கம்பி-இணக்கமான மேம்படுத்தல் இல்லை: நுழைவாயில் புதிய நெறிமுறைக்கு கட்டமைக்கப்பட வேண்டும், சுயவிவரம் பொருந்தும் அடையாளத்தைக் கொண்டிருக்க வேண்டும்.

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

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

பாதை மூன்று: மூன்றாம் தரப்பு வாடிக்கையாளர் பயன்பாடு

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

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

நுழைவாயில் என்ன வழங்க முடியும் என்பதன் அடிப்படையில் தேர்ந்தெடுக்கவும்

இரண்டு விஷயங்களை அறிந்தால் முடிவு குறுகுகிறது: எந்த சாதனங்கள் API 31 அல்லது அதற்குப் பிறகு அறிமுகமாயின, மேலும் அதே பதிவு மாதிரியுடன் IKEv2 சேவையை நுழைவாயில் வழங்க முடியுமா. முடிந்தால், இடம்பெயர்ந்து பாரம்பரிய சுயவிவரத்தில் முதலீட்டை நிறுத்துங்கள். இன்னும் முடியாவிட்டால், அதை இன்னும் தொடங்கும் சாதனங்களுக்கு IKEv1 வைத்திருங்கள், புதிய சாதனங்களுக்கு மூன்றாம் தரப்பு வாடிக்கையாளரை ஆவணப்படுத்தப்பட்ட, காலவரையறை கொண்ட விதிவிலக்காக வழங்குங்கள், சொல்லப்படாத தீர்வாக அல்ல.

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