બે iPhone એપ બંને સેટિંગ્સમાં VPN એન્ટ્રી મૂકી શકે છે, બંને પોતાને VPN ક્લાયન્ટ કહી શકે છે અને લગભગ કોઈ અમલીકરણ વહેંચતા નથી. Apple આમાંથી એક એકીકરણને વ્યક્તિગત VPN કહે છે, અને એ નામ જ મોટાભાગની ગૂંચવણ પેદા કરે છે. વ્યક્તિગત VPN એ બિલ્ટ-ઇન IPsec અથવા IKEv2 અમલીકરણ વાપરતી રૂપરેખાઓ બનાવવા અને સંચાલિત કરવા માટેનું API છે. પેકેટ-ટનલ પ્રદાતા બીજું મોડેલ છે: એપ પોતાના પ્રોટોકોલની ક્લાયન્ટ બાજુ અમલમાં મૂકતું એક્સ્ટેન્શન આપે છે. લોકો પછી આ લેબલમાંથી જે પણ અનુમાન કરે છે, સાઇફરથી લઈને માલિકી અને ફોન સંચાલિત હોવો જોઈએ કે નહીં સુધી, તે અનુમાન છે, નિવેદન નહીં.

ટનલ કોણ અમલમાં મૂકે છે

આ વિભાજન નક્કી કરે છે કે કંઈક બગડે ત્યારે કોણ જવાબદાર છે. બિલ્ટ-ઇન IPsec અથવા IKEv2 સાથે, iOS ટનલની સ્ટેટ મશીનનું માલિક છે અને એપ રૂપરેખા તથા બટનનું માલિક છે. પ્રદાતા સાથે, એપ બંનેનું માલિક છે, તેથી પ્રોટોકોલ બગ એપ અપડેટ બને છે, ઓપરેટિંગ સિસ્ટમ અપડેટને બદલે.

કોણ પ્રોટોકોલ અમલમાં મૂકે છે તે પૂછો તો સરખામણી ટૂંકી છે.

IntegrationApple interfaceProtocol implementation
Personal VPNNEVPNManager with a Personal VPN configurationThe system IPsec or IKEv2 client
Packet tunnelNETunnelProviderManager plus the provider extensionWhatever the extension implements

વ્યક્તિગત VPN દસ્તાવેજીકરણ એ પણ સ્પષ્ટ વપરાશકર્તા અધિકૃતિ પ્રોમ્પ્ટનો ઉલ્લેખ કરે છે જ્યારે એપ પ્રથમ વખત રૂપરેખા સાચવે છે, જે સામાન્ય રીતે VPN એપનું નહીં, તે મોડેલનું લક્ષણ છે.

લેબલ વિશેની બે દાવા જે છોડી દેવા યોગ્ય છે

પ્રથમ એ છે કે વ્યક્તિગત VPN સાઇફર પસંદ કરે છે. એ કરતું નથી; વાટાઘાટ કરેલો સેટ પ્રોટોકોલ અને તેની રૂપરેખામાંથી આવે છે, અને વ્યક્તિગત લેબલ તમને કયો મળશે તે વિશે કંઈ કહેતું નથી. બીજો એ છે કે વ્યક્તિગત VPN પ્રોક્સી કે મર્યાદિત ટનલ સૂચવે છે. તે બિલ્ટ-ઇન IPsec અથવા IKEv2 સૂચવે છે, જે રૂટ કહે ત્યારે પૂર્ણ ટનલ છે.

તેથી એપની હાજરી વાયર પ્રોટોકોલ વિશે કોઈ પુરાવો નથી. WireGuard કે OpenVPN બોલતો તૃતીય-પક્ષ ક્લાયન્ટ રચનાથી પ્રદાતા એપ છે, કારણ કે iOS એ પ્રોટોકોલને મૂળભૂત રીતે અમલમાં મૂકતું નથી.

એન્ટરપ્રાઇઝ શબ્દરચના કેમ ભ્રામક છે

Apple નું દસ્તાવેજીકરણ NETunnelProviderManager રૂપરેખાઓને નિયમિત એન્ટરપ્રાઇઝ VPN રૂપરેખા તરીકે વર્ગીકૃત કરે છે. એ શબ્દરચના API શ્રેણી છે, અને તે લોકોને બે વિરોધી ભૂલો તરફ ધકેલે છે: એ ધારવું કે ગ્રાહક એપ પ્રદાતા મોડેલ વાપરી શકતી નથી, અને એ ધારવું કે ફોન તેના માટે દેખરેખ હેઠળ હોવો જોઈએ. બંમાંથી કંઈ નથી નીકળતું. ગ્રાહક એપ નિયમિતપણે પ્રદાતા આપે છે, અને દેખરેખ એ અલગ પ્રશ્ન છે કે કોણ નીતિ લાગુ કરી શકે.

સંચાલન માલિકી એ ચોથો પ્રશ્ન છે, અને તે બંને મોડેલથી સ્વતંત્ર છે. સંસ્થા દ્વારા સ્થાપિત રૂપરેખા પોતાની ઓળખ, ટ્રાફિક વ્યાપ અને જીવનચક્ર નિયમો ધરાવે છે, અને તે પ્રોફાઇલ સાથે જાય છે, જે એપ સ્થાપિત હોય તેની સાથે નહીં. તેમને એકીકરણ મોડેલની સાથે વાંચો, કારણ કે સંચાલિત બિલ્ટ-ઇન પ્રોફાઇલ અને અસંચાલિત પ્રદાતા પ્રોફાઇલ એક જ ફોન પર એકસાથે હોઈ શકે છે.

સ્ક્રીનશોટને બદલે પુરાવો તપાસો

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

એપની જ વાત કરીએ તો, વપરાતો વર્ગ બીજી બાજુથી એ જ પ્રશ્નનો જવાબ આપે છે: વ્યક્તિગત VPN API ના રૂપરેખા ઑબ્જેક્ટ, અથવા પ્રદાતા મેનેજર અને તેનું એક્સ્ટેન્શન.

પછી ઓપરેટર ખરેખર શું પૂરું પાડે તેના આધારે પસંદ કરો. જ્યાં સુસંગત મૂળ પ્રોફાઇલ હોય ત્યાં બિલ્ટ-ઇન માર્ગમાં ઓછા ચલિત ભાગો હોય છે અને અપડેટ કરવા એક વસ્તુ ઓછી હોય છે. જ્યાં સેવાને iOS આપતું ન હોય એવું પ્રોટોકોલ જોઈએ ત્યાં પ્રદાતા એપ જ એકમાત્ર વિકલ્પ છે અને તેની પ્રકાશન ગતિ તમારા જોખમનો ભાગ બને છે.

રેકોર્ડને કનેક્શન સાથે રાખો

પ્રમાણીકરણ અને સંસાધન નીતિને એપ સાથે નહીં, કનેક્શન રેકોર્ડ સાથે જોડો, જેથી પુનઃસ્થાપન અધિકૃતિ મોડેલને સાથે ન લઈ જાય. એ રેકોર્ડ એ પણ છે જે સપોર્ટ એન્જિનિયરને જોઈએ જ્યારે ટનલ ઊઠે અને બીજું કંઈ કામ ન કરે.

અંતે પૂછવા લાયક પ્રશ્ન એ નથી કે કયું મોડેલ સારું છે. પ્રશ્ન એ છે કે તમારો ઓપરેટર કયું મોડેલ ટેકો આપે છે, અને તમે પાસે ખરેખર જે સાધનો છે તેનાથી રાત્રે બે વાગ્યે કયું ડિબગ કરી શકો છો.

સંબંધિત લેખો