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 મોડ લાગુ કરે છે, ગેટવે માંગતા પ્રમાણીકરણ અને સાઇફર સેટ સાથે.

એપનું પોતાનું સપોર્ટ મેટ્રિક્સ સત્તા તરીકે લો, સ્ટોરનું વર્ણન નહીં, અને ભલામણ કરતા પહેલાં એક વાસ્તવિક ઉપકરણ વાસ્તવિક ગેટવે સામે પરીક્ષણ કરો. દૂર કરાયેલ પ્લેટફોર્મ માર્ગ પુનઃસ્થાપિત કરવા ફોન રૂટ કરવો પણ જાળવાયેલ ઉકેલ નથી; તે સમસ્યાને અસમર્થિત રૂપરેખામાં ખસેડે છે જે આગલું સિસ્ટમ અપડેટ શાંતિથી તોડી શકે છે.

ગેટવે શું આપી શકે તેના આધારે પસંદ કરો

જ્યારે તમે બે વસ્તુઓ જાણો છો ત્યારે નિર્ણય સાંકડો થાય છે: કયા ઉપકરણો API 31 અથવા પછી શરૂ થયા, અને શું ગેટવે એ જ નોંધણી મોડેલ સાથે IKEv2 સેવા આપી શકે છે. જો આપી શકે, તો માઇગ્રેટ કરો અને જૂની પ્રોફાઇલમાં રોકાણ બંધ કરો. જો હજી ન આપી શકે, તો હજી શરૂ કરતા ઉપકરણો માટે IKEv1 રાખો, અને નવા ઉપકરણોને તૃતીય-પક્ષ ક્લાયન્ટ દસ્તાવેજીકૃત અને સમય-મર્યાદિત અપવાદ તરીકે આપો, બિનકથિત ઉપાય તરીકે નહીં.

બે મુદ્દા યોજનાને સમર્થનીય બનાવે છે. પ્રથમ, દરેક અપવાદનું કારણ મોડેલ અને લોન્ચ સ્તર સાથે નોંધો, જેથી ઓડિટર જોઈ શકે કે સીમા પ્લેટફોર્મ ગાર્ડ છે, અસ્પષ્ટ પસંદગી નહીં. બીજું, માઇગ્રેશનને આયોજિત કામ તરીકે ગણો: IKEv1 ધોરણ માર્ગમાં અપ્રચલિત છે (RFC 9395), એટલે કે બાકીના ઉપકરણો ઘટતા રહેશે અને અપવાદો તેમની સાથે સમાપ્ત થવા જોઈએ.