ના, VpnService એપ ફોનનું VPN ચાલુ કરી શકતી નથી

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

દરેક જીવનચક્ર સંક્રમણને કિનારી કિસ્સો નહીં, ડિઝાઇનનો ભાગ ગણો.

ભ્રમ: એપ ફોનનું VPN ચાલુ કરે છે

VpnService.prepare() થી પ્રવાહ શરૂ થાય છે, જે એક Intent પાછું આપે છે જે વપરાશકર્તાએ સ્વીકારવું પડે, અને establish() સાથે આગળ વધે છે, જે પછી પણ એપ નિયંત્રિત ન કરતાં કારણોસર નિષ્ફળ થઈ શકે છે. બીજી ટનલ સ્થાપિત કરવાથી પ્રથમ ઇન્ટરફેસ નિષ્ક્રિય થાય છે અને સિસ્ટમ સૂચના બદલાય છે. તે ક્રમમાં ક્યાંય પણ એપ આખા ઉપકરણનો સ્વિચ ધરાવતી નથી; તેને આપવામાં આવેલ ડિસ્ક્રિપ્ટર અને તેના પર આવતાં પેકેટ તેની પાસે છે. સ્થાયી સૂચના પણ એપની ડિઝાઇનની નહીં, સિસ્ટમની છે.

ઇન્ટરફેસ ઝૂંટવીને નહીં પણ આપવામાં આવે છે, તેથી બીજો ક્લાયન્ટ કોઈપણ સમયે જગ્યા લઈ શકે છે. એપ તે કોલબેક દ્વારા જાણે છે, રિટર્ન વેલ્યુ દ્વારા નહીં.

એપને જબરદસ્તી બંધ કરવાનું સૂચના પેનલમાં દેખાય છે તે જ કારણસર: સિસ્ટમ જણાવે છે તેણે શું આપ્યું, એપે શું બતાવવાનું પસંદ કર્યું તે નહીં.

ભ્રમ: સંમતિ એક જ વાર આપવામાં આવે છે

જ્યારે સિસ્ટમ ટનલ બીજા ક્લાયન્ટને સોંપે છે, ત્યારે તે binder પર રદ કરવાનો વ્યવહાર મોકલે છે જે બેઝ ક્લાસ onBind() થી પાછો આપે છે. જે એપ તે binder ને પોતાના સાથે બદલે છે તેણે રદ વ્યવહાર જાતે આગળ મોકલવો પડે, નહીં તો VpnService.onRevoke() ક્યારેય ચાલુ થતું નથી અને સેવા એવા ડિસ્ક્રિપ્ટરમાં લખવાનું ચાલુ રાખે છે જે હવે અસ્તિત્વમાં નથી. વપરાશકર્તા પણ મંજૂરી પાછી ખેંચી શકે છે, અને સિસ્ટમ રીસ્ટાર્ટ કે હંમેશા-ચાલુ ફરી જોડાણ દરમિયાન સેવા બંધ કરી શકે છે.

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

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

ભ્રમ: ઇન્ટરફેસ તમારા વતી ટ્રાફિક ફિલ્ટર કરે છે

જે આવે છે તે કાચું IP છે. પકડવું કે ફિલ્ટર કરવું એટલે IP, TCP, UDP અને IPv6 હેડર પાર્સ કરવા, પ્રવાહ ટ્રેક કરવા અને જવાબો ડિસ્ક્રિપ્ટરમાં પાછા લખવા, જે કેપ્ચર એપને સિસ્ટમ સુવિધા નહીં પણ નાનું નેટવર્ક સ્ટેક બનાવે છે. protect() એટલા માટે છે કે એપનું પોતાનું ટ્રાન્સપોર્ટ સોકેટ પોતાને પકડવાને બદલે પોતાની ટનલ ટાળે, અને તે બુલિયન પાછું આપે છે જે ટનલ ચાલુ થયા પછી બનતા દરેક સોકેટ પર ચકાસવા લાયક છે.

બિલ્ડરની મંજૂર અને પ્રતિબંધિત એપ્લિકેશન યાદીઓ નક્કી કરે છે કોનો ટ્રાફિક ઇન્ટરફેસમાં પ્રવેશે. તેઓ ઇન્ટરફેસ જે IP પેકેટ લઈ જાય તેની બહાર પેલોડ સુધી પ્રવેશ આપતી નથી, અને કોઈ API બીજા ક્લાયન્ટની ટનલ જાહેર કરતું નથી કે સિસ્ટમની VPN પ્રોફાઇલની યાદી બનાવે છે. નેટવર્ક ક્ષમતાઓ કહી શકે કે નેટવર્ક VPN ટ્રાન્સપોર્ટ છે, પણ ટનલ કોની છે તે નહીં.

તેથી જ બીજી એપ્સ વિશેની સ્થિતિની પ્રશ્નોને વિરોધાભાસી જવાબો મળે છે: માહિતી ફક્ત તમારી પ્રોસેસને જાહેર થતી નથી.

જીવનચક્ર ખરેખર શું માગે છે

તમે નિયંત્રિત કરો છો તે સ્થિતિઓ ટ્રેક કરો: તૈયાર, સ્થાપિત, રદ, બંધ. ફરી જોડાણ એ તોડી પાડવું અને પછી સ્થાપિત કરવું જોઈએ, ડિસ્ક્રિપ્ટર અને ટ્રાન્સપોર્ટ સોકેટ માટે એક જ માલિક સાથે, કારણ કે સ્થાપિત કરવા માટે હરીફાઈ કરતા બે ઘટકો એકમાત્ર ઉપલબ્ધ જગ્યા માટે લડશે. આધુનિક Android પર બેકગ્રાઉન્ડ શરૂઆત મર્યાદિત છે, તેથી બૂટ બ્રોડકાસ્ટ કોઈ ગેરંટી નથી; API સ્તર પરવાનગી આપે ત્યાં તેની સૂચના સાથે ફોરગ્રાઉન્ડ સેવા વાપરો.

ફક્ત અંતિમ સ્થિતિ નહીં, સંક્રમણ લોગ કરો, અને દરેક માર્ગ ચકાસી શકાય તેટલી નાની સ્થિતિ મશીન રાખો. જે સ્થિતિ સુધી તમે પરીક્ષણમાં પહોંચી શકતા નથી તે સ્થિતિ લોગ વગર ક્ષેત્રમાં મળશે.

ઉપકરણ પર જીવનચક્ર ચકાસો

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

adb shell dumpsys connectivity | grep -i -A3 vpn
adb shell dumpsys activity services | grep -i -A2 vpnservice
adb logcat -s VpnService:V AndroidRuntime:E
adb shell am force-stop com.example.vpnapp

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

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