તમારી iOS VPN એપ ટનલ ચાલુ હોવા છતાં ડિસ્કનેક્ટેડ કેમ દેખાય છે

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

મેનેજર ઑબ્જેક્ટ કેશ કરેલું દૃશ્ય છે, ટનલ નહીં

NETunnelProviderManager સિસ્ટમની માલિકીના પ્રાથમિકતા સ્ટોરમાંથી ભરાય છે, તેથી loadFromPreferences પૂર્ણ ન થાય ત્યાં સુધી તેના ગુણધર્મોનો કોઈ અર્થ નથી. તે પહેલા connection.status વાંચો તો તમને ડિફૉલ્ટ મૂલ્ય મળે છે, અને એટલે જ રીલૉન્ચ પછીનું પહેલું સ્થિતિ રિફ્રેશ ટનલ ચાલુ હોવા છતાં ડિસ્કનેક્ટેડ જણાવે છે. પહેલા લોડ કરો, પછી એ જ કમ્પ્લીશન હેન્ડલરમાંથી સ્થિતિ અને પ્રોટોકોલ રૂપરેખાંકન વાંચો. પોલિંગને બદલે પછીના ફેરફારો NEVPNStatusDidChange દ્વારા નિરીક્ષણ કરો, અને ધ્યાનમાં રાખો કે સૂચના On Demand દ્વારા શરૂ થયેલા કનેક્શન માટે પણ આવે છે, જ્યાં કંઈ પણ પરત કરવા માટે કોઈ એપ કૉલ જ હોતો નથી. પ્રોટોકોલ સેટિંગ્સ માટે પણ એ જ લાગુ પડે છે: તે લોડ કરેલા રૂપરેખાંકનમાંથી વંચાય છે, એપે મોકલેલા તેમાંથી નહીં.

ટનલ પોતે Network Extension પ્રદાતા પ્રોસેસમાં રહે છે, તેથી એપ કનેક્શન ગુમાવ્યા વિના પોતાની સ્થિતિ ગુમાવી શકે છે. ઇન્ટરફેસ જે બતાવે છે તે બધું મેનેજરમાંથી ફરી બનાવવું પડે, છેલ્લા સત્રમાંથી યાદ રાખવું નહીં.

શરૂઆતનો ક્રમ: સેવ કરો, લોડ કરો, પછી શરૂ કરો

પ્રદાતા-આધારિત કનેક્શનને ક્રમમાં ત્રણ પગલાં જોઈએ. પ્રદાતા રૂપરેખાંકન લખો અને saveToPreferences કૉલ કરો, મેનેજર લોડ કરો જેથી સાચવેલું રૂપરેખાંકન તમારી પાસે હોય તે જ હોય, પછી NETunnelProviderSession.startVPNTunnel() દ્વારા શરૂ કરો. સેવ છોડી દો તો શરૂઆત પાસે શરૂ કરવા જેવું કંઈ નથી; સેવ પહેલા લોડ કરો તો મેનેજર હજી જૂનું રૂપરેખાંકન જ દર્શાવે છે.

startVPNTunnel જે બુલિયન પરત કરે છે તે ફક્ત કહે છે કે વિનંતી સ્વીકારાઈ. પ્રદાતા-સ્તરની નિષ્ફળતાઓ પછી ડિસ્કનેક્ટેડ સ્થિતિમાં ફેરફાર તરીકે આવે છે, જે તમે NEVPNStatusDidChange સૂચના દ્વારા નિરીક્ષણ કરો છો, અને સૂચના હેન્ડલરે loadFromPreferences પછી connection.status ફરી વાંચવું પડે કારણ કે કેશ કરેલું મૂલ્ય હજી જૂનું હોઈ શકે. વિનંતી-સ્તરની નિષ્ફળતાઓ કૉલના ફેંકતા સ્વરૂપમાંથી તરત જ પાછી આવે છે, અથવા startVPNTunnelAndReturnError: ના ભૂલ આઉટ-પેરામીટર દ્વારા. જે કોડ પરત મૂલ્યને પરિણામ ગણે છે તે એવા કનેક્શનની જાણ કરે છે જે ક્યારેય સ્થપાયું નહીં. બીજી શાંત નિષ્ફળતા એ પ્રદાતા બંડલ આઇડેન્ટિફાયર છે જે સ્થાપિત એક્સ્ટેન્શન સાથે મેળ ખાતું નથી: વિનંતી નકારાય છે, અને સંદેશમાં કંઈ પણ આઇડેન્ટિફાયર તરફ ઇશારો કરતું નથી. આઇડેન્ટિફાયર ખોટું હોય તો વિનંતી સામાન્ય રીતે તરત જ નિષ્ફળ જાય છે, પ્રદાતાની કોઈ લોગ લાઇન આવે તે પહેલાં.

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

ટ્રસ્ટ સામગ્રી પ્રોફાઇલ દ્વારા આવે છે, ક્યારેય એપ કોડમાંથી નહીં

iOS ટ્રસ્ટ સ્ટોરમાં રૂટ સર્ટિફિકેટ ઉમેરવાની કોઈ સમર્થિત રીત એપ પાસે નથી, તેથી Personal VPN રૂપરેખાંકન ફક્ત એવી સામગ્રીનો સંદર્ભ લઈ શકે જેના પર ઉપકરણ પહેલેથી ભરોસો કરે છે: સ્થાપિત પ્રોફાઇલ, ઉપકરણ મેનેજમેન્ટ અથવા સિસ્ટમ અન્ય કારણોસર ભરોસો કરે તેવા CA દ્વારા સ્થપાયેલી શૃંખલા. જે એપ પહેલી વાર ચાલુ થાય ત્યારે પોતાનું CA બનાવે અને સિસ્ટમ તેને માનશે એવી અપેક્ષા રાખે, તે પ્રદાતાની અંદર માન્યતા ચકાસણીમાં નિષ્ફળ જશે, જ્યાં એપનું ઇન્ટરફેસ કારણ જોઈ શકતું નથી.

એ સીમાને જેવી છે તેવી ડિઝાઇન મર્યાદા ગણો અને નોંધણી પ્રોફાઇલ સાથે ટ્રસ્ટ એન્કર મોકલો. VPN પ્રમાણીકરણને ટ્રસ્ટ નિર્ણયથી અલગ રાખો, કારણ કે તે અલગ જગ્યાએ નિષ્ફળ જાય છે અને અલગ લોકો તેને ડિબગ કરે છે.

કાઉન્ટર ઇન્ટરફેસમાંથી આવે છે, VPN API માંથી નહીં

મેનેજર સ્થિતિ અને રૂપરેખાંકન આપે છે, અને દરેક ટનલના બાઇટ ગણે તેવું કંઈ નહીં. તમને વપરાશના આંકડા જોઈએ તો getifaddrs() કૉલ કરો અને સંબંધિત ઇન્ટરફેસ માટે if_data વાંચો: Wi-Fi માટે en0, સેલ્યુલર માટે pdp_ip ઇન્ટરફેસ, અને ટનલ માટે જ utun ઉપકરણ. utun કાઉન્ટર આંતરિક ટ્રાફિક વર્ણવે છે અને પ્રોટોકોલ ઓવરહેડ સમાવે છે.

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

સફાઈ stopVPNTunnel માં છે, સમાપ્તિમાં નહીં

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

એ આઇડેન્ટિફાયર તે જે પ્રોફાઇલનું છે તેની બાજુમાં સંગ્રહો, કારણ કે મેનેજર ઑબ્જેક્ટ વપરાશકર્તાએ કયું રૂપરેખાંકન પસંદ કર્યું તે નોંધતું નથી. અને યાદ રાખો કે On Demand જે કનેક્શન ઉભું કરે તેની પાછળ કોઈ એપ કૉલ જ હોતો નથી, તેથી સ્થિતિ સ્ક્રીનને કંઈ દોરવા પહેલાં હજી પ્રાથમિકતાઓ લોડ કરવી પડે છે.