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), అంటే మిగిలిన పరికరాలు తగ్గుతూనే ఉంటాయి మరియు మినహాయింపులు వాటితో పాటు ముగియాలి.