iPhone પર VPN એપ કે બિલ્ટ-ઇન IKEv2: કેવી રીતે પસંદ કરવું
iPhone ની VPN એપ અને બિલ્ટ-ઇન IKEv2 ક્લાયન્ટ અલગ સમસ્યાઓ ઉકેલે છે. પહેલા પ્રોટોકોલ સપોર્ટ, પ્રમાણીકરણ, ઉપકરણ નિયંત્રણ અને પુનઃપ્રાપ્તિની સરખામણી કરો.
ગયા અઠવાડિયે એક સહકર્મીએ મને પોતાનો iPhone આપ્યો, સેટિંગ્સમાં બે VPN એન્ટ્રી હતી: એક પ્રદાતા એપે છોડેલી, બીજી સહાય પૃષ્ઠ પરથી પેસ્ટ કરેલી IKEv2 પ્રોફાઇલની. આ એક જ વસ્તુની સ્પર્ધક આવૃત્તિઓ નથી. પ્રદાતા એપ એક કન્ટેનર છે જે પોતાનો ટનલ કોડ સાથે લાવી શકે છે, જ્યારે Apple નો બિલ્ટ-ઇન ક્લાયન્ટ IKEv2 ક્લાયન્ટ છે, જે હાથે અથવા પ્રોફાઇલ દ્વારા ગોઠવાય છે. પ્રોટોકોલ, ક્રેડેન્શિયલની સંભાળ, ઉપકરણ નિયંત્રણ અને પુનઃપ્રાપ્તિ પસંદગી નક્કી કરે છે.
એપ અને મૂળ ક્લાયન્ટ જુદા સ્તરે છે
Apple નો બિલ્ટ-ઇન VPN ક્લાયન્ટ વ્યવહારમાં IKEv2 ક્લાયન્ટ છે. હાથે ભરવાનું ફોર્મ હજી પણ અપ્રચલિત IPsec પર L2TP અને Cisco IPsec વિકલ્પોની યાદી આપે છે, પણ પ્રદાતા ટ્રાન્સપોર્ટ માટે કોઈ ક્ષેત્ર અને OpenVPN કે WireGuard ગોઠવણી પેસ્ટ કરવાની જગ્યા નથી. તમે કાં તો સેટિંગ્સ > સામાન્ય > VPN & ઉપકરણ વ્યવસ્થાપનમાં ફોર્મ ભરો છો અથવા VPN પેલોડ સાથેની પ્રોફાઇલ આયાત કરો છો; સપાટી એક સર્વર સરનામું, બે ઓળખ, એક પ્રમાણીકરણ પદ્ધતિ અને વૈકલ્પિક ઑન-ડિમાન્ડ નિયમો છે.
પ્રદાતા એપ એક સ્તર ઉપર કામ કરે છે. તે Network Extension પેકેટ ટનલ પ્રદાતા આપે છે, તેથી પ્રોટોકોલ કોડ અને રૂટિંગ તર્ક એપમાં રહે છે અને iOS ફક્ત પેકેટ આગળ મોકલે છે. કેટલીક એપ WireGuard કે OpenVPN અમલમાં મૂકે છે, કેટલીક પોતાનું અસ્પષ્ટ ટ્રાન્સપોર્ટ, અને થોડી ફક્ત IKEv2 પ્રોફાઇલ સ્થાપિત કરી મૂળ ક્લાયન્ટને વધુ સુંદર સ્ક્રીન પાછળ ચલાવે છે. આ છેલ્લા જૂથને કારણે એપ કે પ્રોફાઇલની પસંદગી ક્યારેક ખોટી બને છે.
પરિણામ વ્યવહારુ છે: .ovpn કે WireGuard ફાઇલ એ ક્ષેત્રોની જગ્યા લેતી નથી, કારણ કે હેન્ડશેક બીજો પ્રોટોકોલ છે.
સુવિધાઓની સરખામણી પહેલા પેલોડ વાંચો
જ્યારે પ્રોફાઇલ IKEv2 હોય, પેલોડની કી કોઈપણ સુવિધા-સરખામણી કરતાં વધુ નિષ્ફળતાઓ સમજાવે છે. Apple ની IKEv2 સેટિંગ્સ સંદર્ભ દરેક કીનું દસ્તાવેજીકરણ કરે છે; ટૂંકાવેલો પેલોડ આવો દેખાય છે:
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>ત્રણ ક્ષેત્રો નિદાનનું મોટું ભાર ઉપાડે છે. RemoteIdentifier એ નામ છે જે ક્લાયન્ટ સર્વરથી અપેક્ષા રાખે છે, તેથી NAT પાછળનું ગેટવે અથવા જેનું પ્રમાણપત્ર સરનામાને બદલે પૂલનું નામ આપે છે તેવું લોડ બેલેન્સર સરનામું સાચું હોવા છતાં નિષ્ફળ જાય છે. LocalIdentifier એ ઓળખ છે જે સર્વર તમને માને છે, અને પ્રમાણપત્ર પ્રમાણીકરણમાં તેણે તમારા ખાતા સાથે જોડાયેલી ઓળખ સાથે મેળ ખાવો જોઈએ. ServerCertificateIssuerCommonName જારી કરનાર CA ને પિન કરે છે, તેથી પ્રમાણપત્ર ફરી જારી થવાના દિવસે પ્રોફાઇલ નિષ્ફળ થઈ શકે છે, અને કોઈ પણ ભૂલ સંદેશમાં પ્રમાણપત્રોનો ઉલ્લેખ હોતો નથી.
જો AuthenticationMethod SharedSecret બરાબર હોય, તો સર્વર EAP વપરાશકર્તા પ્રમાણીકરણ કરી રહ્યું છે અને તમને આપેલું રહસ્ય વાસ્તવમાં ખાતાનું ક્રેડેન્શિયલ છે. આ ત્યારે મહત્ત્વનું છે જ્યારે પ્રદાતા બે દસ્તાવેજ મોકલે, એક વપરાશકર્તાનામ અને પાસવર્ડ માટે અને એક પ્રમાણપત્ર માટે, અને ફક્ત એક જ તમે આયાત કરેલા સાથે મેળ ખાય.
એપ શું કરી શકે અને મૂળ ક્લાયન્ટ નહીં
પ્રોટોકોલની પસંદગી સ્પષ્ટ ફાયદો છે. જો તમારું સર્વર WireGuard કે OpenVPN બોલે, તો એપ જ એકમાત્ર iOS ક્લાયન્ટ છે જે તેનો ઉપયોગ કરી શકે, અને મૂળ ફોર્મમાં ફેરફાર તેના પર વાટાઘાટ કરશે નહીં. એપ લક્ષ્ય કે એપ મુજબ વિભાજિત ટનલ, પોતાની DNS સંભાળ, kill switch શૈલીની અટકાવ, સર્વર પસંદગી અને પોતાના નેટવર્ક સાથે સુમેળ કરેલું પુનઃકનેક્શન પણ અમલમાં મૂકી શકે છે.
કિંમત એ સોફ્ટવેર છે જેનું તમે ઑડિટ કર્યું નથી અને જે નેટવર્ક એક્સટેન્શનના અધિકારો સાથે ચાલે છે. ગુણવત્તા સ્ટોર કાર્ડના સંકેત કરતાં વધુ બદલાય છે: એક એપ સ્વચ્છ રીતે પુનઃ જોડાય છે જ્યારે બીજી નેટવર્ક બદલાયા પછી થોડી સેકન્ડ લીક કરે છે, અને એપની અંદરનું kill switch તે એપની સુવિધા છે, iOS ની નહીં. વ્યવસ્થાપિત ઉપકરણ પર પહેલા મંજૂર યાદી તપાસો.
બિલ્ટ-ઇન IKEv2 પ્રોફાઇલ શું સાચું કરે છે
ઓછા ચાલતા ભાગો એ જ આખી દલીલ છે. IKEv2 ક્લાયન્ટ અને તેનો IPsec સ્ટેક સિસ્ટમ સાથે આવે છે, તેથી ક્રેશ થઈ શકે તેવું એક્સટેન્શન નથી, દરેક એપ માટે જીવંત રાખવાની પ્રક્રિયા નથી, અને તમારા અને કાર્યરત ટનલ વચ્ચે તૃતીય પક્ષના અપડેટનું ચક્ર નથી. પ્રોફાઇલ લૉક પણ કરી શકાય છે: દેખરેખ હેઠળના ઉપકરણ પર વપરાશકર્તા વ્યવસ્થાપને સ્થાપિત કરેલું દૂર કરી શકતો નથી, અને વપરાશકર્તા સ્વિચ વિના કોઈપણ નેટવર્ક પર ફરી જોડાતું Always On VPN ફક્ત તે જ દેખરેખ હેઠળના, પ્રોફાઇલ-વ્યવસ્થાપિત સ્વરૂપમાં અસ્તિત્વ ધરાવે છે.
બિલ્ટ-ઇન માર્ગ જે આપતું નથી તે લવચીકતા છે. વ્યવસ્થાપિત એપ વિના પ્રતિ-એપ VPN નથી, વપરાશકર્તા માટે kill switch નથી, અને IPsec અવરોધતા નેટવર્ક પર HTTPS જેવું દેખાતું ટ્રાન્સપોર્ટ નથી. UDP 500 અને 4500 ફેંકી દેતા હોટેલ નેટવર્કમાં બિલ્ટ-ઇન IKEv2 પાસે કોઈ વૈકલ્પિક માર્ગ નથી.
મોટાભાગના કિસ્સા ઉકેલતું નિર્ણય કોષ્ટક
વ્યવહારમાં પ્રોટોકોલનો પ્રશ્ન સુવિધાઓ મહત્ત્વની થવાના પહેલાં જ મોટાભાગના કિસ્સા નક્કી કરે છે.
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
બે પંક્તિઓ બીજી નજરને લાયક છે. અંગત ફોન પર પ્રતિ-એપ જરૂરિયાત એ કિસ્સો છે જે લોકો ખોટો વાંચે છે: સેટિંગ iOS માં છે પણ વ્યવસ્થાપન તેને ચલાવે છે, તેથી બિન-વ્યવસ્થાપિત ઉપકરણ તેને આપશે નહીં. અવરોધિત નેટવર્ક IKEv2 પર અવિશ્વાસનું કારણ નથી; આ જ કારણ છે કે પ્રદાતાની એપ અસ્તિત્વ ધરાવે છે.
એક પરીક્ષણથી પસંદગી ચકાસો
નિષ્ફળતાની રીતો ચકાસો, કનેક્ટ બટન નહીં. એક વાર જોડાઓ, VPN સૂચક દેખાય છે તેની ખાતરી કરો, પછી તમારું જાહેર સરનામું પરત આપતું પૃષ્ઠ ખોલો અને પાછલા સાથે સરખાવો. VPN ને અડ્યા વિના Wi-Fi થી મોબાઇલ ડેટા પર જાઓ અને પુનઃકનેક્શન જુઓ, પછી ફોનને એરપ્લેન મોડમાંથી પસાર કરો. ફરી શરૂ કરો અને જુઓ ટનલ જાતે પાછી આવે છે કે નહીં: OnDemandEnabled વાળી પ્રોફાઇલ પાછી આવવી જોઈએ, જ્યારે ઘણી એપ પહેલા ખોલવી પડે છે.
જ્યારે તે પાછી ન આવે, નિષ્ફળતાને ટનલ છે કે નહીં તે આધારે વહેંચો. VPN સૂચક ન હોવું એટલે ટનલ ક્યારેય ઉપડી જ નહીં: કાં તો હેન્ડશેક RemoteIdentifier, પિન કરેલા CA કે ક્રેડેન્શિયલ પર નિષ્ફળ ગયો, અથવા કનેક્શનનો પ્રયાસ જ થયો નહીં કારણ કે ઑન-ડિમાન્ડ નિયમ મેળ ખાધો નહીં અને કોઈ એપે તેને શરૂ કરી નહીં. સૂચક હોય પણ ટ્રાફિક નિષ્ફળ હોય તો તે રૂટિંગ, DNS કે સર્વર-બાજુ નીતિ છે, અને ક્લાયન્ટ ફરી સ્થાપિત કરવું આમાંના કશાને સ્પર્શતું નથી.
ઉપકરણને આગલી વ્યક્તિ માટે સમજાવી શકાય તેવું રાખવા ટૂંકી યાદી:
- એક VPN એન્ટ્રી, બે નહીં;
- પ્રોફાઇલ કે એપ જે સર્વર સાથે જોડાય છે તેના નામે;
- ઓળખના મૂલ્યો જ્યાં તમને મળે ત્યાં લખેલા.
કોષ્ટકમાં પ્રોટોકોલની પંક્તિથી શરૂ કરો, અને જો તે પ્રશ્નનો જવાબ આપે તો ત્યાં જ અટકો.