રૂટ વગર Android VPN: સંમતિ, રૂટ અને બ્લોકિંગ કોની માલિકી હેઠળ
સંમતિ, TUN ઇન્ટરફેસ અને સિસ્ટમની બ્લોકિંગ નીતિ ત્રણ અલગ પરવાનગીઓ છે. Android VPN એપની સમીક્ષા કરતા પહેલાં દરેક કયા ઘટકની માલિકી હેઠળ છે તે શોધો.
Android VPN એપને ટ્રાફિક વહન કરવા, લીક બ્લોક કરવા કે રીબૂટ પછી ટકી રહેવા દે તે રૂટ નથી. લોકો આ બધું „એપ પાસે VPN પરવાનગી છે“ તરીકે સારાંશે છે, જે ત્રણ અલગ મિકેનિઝમ છુપાવે છે: વપરાશકર્તાની સંમતિ, સિસ્ટમ બનાવે છે તે પેકેટ ઇન્ટરફેસ, અને પ્લેટફોર્મની બ્લોકિંગ નીતિ જે નક્કી કરવાનું એપનું કામ નથી. Android VPN ડિઝાઇનની સમીક્ષા એટલે પૂછવું કે કોઈ દાવો ખરેખર આ ત્રણમાંથી કયા પર રહેલો છે, કારણ કે દરેકનો માલિક અને નિષ્ફળતાની રીત અલગ છે.
સંમતિ સિસ્ટમ પ્રવૃત્તિ દ્વારા આવે છે
VpnService.prepare() કંઈ આપતું નથી. સંમતિ ન હોય ત્યારે તે સિસ્ટમ સંમતિ પ્રવૃત્તિને intent પરત આપે છે, અને એપ તે સંવાદ ખોલે છે જેથી વપરાશકર્તા સેવા મંજૂર કરી શકે. એપની પોતાની પ્રક્રિયા શરૂ કરવી, મેનિફેસ્ટમાં પરવાનગી ઉમેરવી, અથવા કસ્ટમ „VPN સક્ષમ કરો“ સ્ક્રીન બતાવવી એ મંજૂરી બનાવતું નથી.
મંજૂરી અવકાશમાં પણ મર્યાદિત છે. તે વપરાશકર્તા પ્રોફાઇલમાંના પેકેજની છે, તેથી અંગત નકલ અને કાર્ય નકલ અલગ નિર્ણયો છે, અને ઉપકરણ માલિક મેનેજ્ડ પ્રોફાઇલને અંગત પ્રોફાઇલથી અલગ રીતે તૈયાર કરી શકે છે. જો સંવાદ ક્યારેય ન દેખાય અને prepare() null પરત આપે, તો તે પ્રોફાઇલમાં તે પેકેજ માટે સંમતિ પહેલેથી જ છે; તે એપ વિશ્વસનીય હોવાનો પુરાવો નથી, ફક્ત મંજૂરી અસ્તિત્વમાં છે તેમ બતાવે છે.
ઇન્ટરફેસ એ વિનંતી છે જે સિસ્ટમ પૂરી કરે છે
સંમતિ પછી એપ VpnService.Builder વડે જણાવે છે કે શું જોઈએ છે: સરનામાં, રૂટ, DNS સર્વર, MTU અને જ્યાં સમર્થિત હોય ત્યાં સમાવિષ્ટ કે બાકાત રાખવાની એપ્સ. establish() સિસ્ટમને ટનલ ઇન્ટરફેસ બનાવવા અને અનુરૂપ ટ્રાફિક તેમાં મોકલવા વિનંતી કરે છે. રાઉટિંગ નિર્ણય સિસ્ટમનો છે; એપ ફાઇલ ડિસ્ક્રિપ્ટર મેળવે છે અને પછી પેકેટો સાથે કંઈક ઉપયોગી કરવું પડે છે.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
આ કોષ્ટક એક જગ્યાએ આર્કિટેક્ચર છે. એપ પેકેટ હેન્ડલિંગમાં ભાગ લે છે; ઇન્ટરફેસ, રાઉટિંગ કોષ્ટક કે ચાલી શકતી સેવાઓની સંખ્યા તેની નથી.
ટનલ સોકેટે પોતાની ટનલમાંથી બહાર નીકળવું પડે છે
એન્ક્રિપ્ટેડ ટ્રાફિક વહન કરતું જોડાણ પોતે એક સોકેટ છે. જો તે એપે હમણાં બનાવેલા ઇન્ટરફેસમાં પાછું રાઉટ થાય, તો ટનલ ટનલ પર આધારિત થઈ જાય છે અને અટકી જાય છે. VpnService.protect() તે સોકેટને અંતર્ગત નેટવર્ક સાથે બાંધે છે જેથી તે કેપ્ચર ટાળે, અને એટલે જ સાચો ક્લાયન્ટ પ્રથમ હેન્ડશેક પહેલાં પોતાનું બહારનું સોકેટ સુરક્ષિત કરે છે.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownઆ આદેશો ઇન્સ્ટોલ થયેલું VPN નેટવર્ક, ઑલવેઝ-ઑન પેકેજ અને લૉકડાઉન સેટ છે કે નહીં તે બતાવે છે. તે ફક્ત વાંચવા માટેના અવલોકનો છે: જો મૂલ્યો ડિઝાઇનના દાવા સાથે મેળ ખાતા ન હોય, તો દાવો સિસ્ટમની સ્થિતિ વિશે નહીં, એપની UI વિશે છે.
બ્લોકિંગ પ્લેટફોર્મનું હોઈ શકે
Android એ નીતિનું દસ્તાવેજીકરણ કરે છે જે VPN વાપરતા ન હોય તેવા જોડાણોને બ્લોક કરે છે. તે અમલ પ્લેટફોર્મનો કરાર છે, એપ લૂપમાં જોડાણ ફરી પ્રયત્ન કરે તે નહીં. સ્વિચ ઉપકરણની VPN સેટિંગ્સમાં „VPN વગર જોડાણો બ્લોક કરો“ તરીકે છે, અને મેનેજ્ડ ઉપકરણ પર માલિક તેને આખા પ્રોફાઇલ માટે ચાલુ કરી શકે છે. માર્કેટિંગ દાવાનું મૂલ્યાંકન કરતી વખતે આ ભેદ મહત્ત્વનો છે: ક્લાયન્ટ તાળું આઇકન બતાવીને આક્રમક રીતે ફરી જોડાઈ શકે છે જ્યારે સીધો ટ્રાફિક હજી શક્ય હોય, અથવા આવરી લીધેલી એપ્સ ઑફલાઇન રહી શકે છે કારણ કે સિસ્ટમ લૉકડાઉન લાગુ કરે છે.
તાળાનું આઇકન એપ દોરે છે, તેથી તે ફક્ત સાબિત કરે છે કે એપ માને છે તે જોડાયેલી છે. બીજી એપ નેટવર્ક એક્સેસ ગુમાવશે કે નહીં તે પ્લેટફોર્મ નક્કી કરે છે, તેથી ઉપયોગી તપાસ એ છે કે ટનલ ચાલુ હોય ત્યારે તે એપ નિષ્ફળ થતી જોવી.
એપ સ્ટોરનું „ઑલવેઝ ઑન“ લેબલ પણ તે કરારને બદલતું નથી. ઑલવેઝ-ઑન અને લૉકડાઉન ઉપકરણ સેટિંગ્સ છે, ઘણી વાર ઉપકરણ માલિક લાગુ કરે છે, અને બાકાત રાખેલી એપ્સ માટે તેમનું વર્તન પ્લેટફોર્મ નક્કી કરે છે. બેજ નહીં, સેટિંગ વાંચો.
ડિઝાઇન સમીક્ષા માટે ચાર પ્રશ્નો
પ્રથમ, કોણે સંમતિ આપી: કયું પેકેજ, કયું પ્રોફાઇલ, અને તે વપરાશકર્તા હતો કે મેનેજ્ડ-ઉપકરણ નીતિ? બીજું, એપે શું માંગ્યું: કયા રૂટ, કયા સરનામા કુટુંબો, કઈ એપ્સ સમાવિષ્ટ કે બાકાત? ત્રીજું, ટનલ ઉપલબ્ધ ન હોય ત્યારે શું થાય: સિસ્ટમ બ્લોક કરે છે કે ટ્રાફિક અંતર્ગત નેટવર્ક પર પાછો જાય છે? ચોથું, એપને મળતા પેકેટો સાથે એ શું કરે છે?
ચોથો પ્રશ્ન એ છે જેનો જવાબ પરવાનગી મોડેલ આપી શકતું નથી. સંમતિ અને TUN ઇન્ટરફેસ સાબિત કરે છે કે એપ ટ્રાફિક મેળવી શકે છે, પણ એ નહીં કે તે એન્ક્રિપ્ટ કરે છે, સામેના પક્ષને પ્રમાણિત કરે છે કે સ્વચ્છ રીતે પુનઃપ્રાપ્ત થાય છે. આ અમલીકરણના ગુણધર્મો છે, અને પ્રામાણિક સમીક્ષા ત્યાં જ સમય ગાળે છે.
બિનજરૂરી રૂટ વિનંતીને પરિણામને કિલ સ્વિચ કહેવાથી કાયદેસર નથી બનતી, અને સંમતિ સંવાદ સુરક્ષા ઓડિટ નથી. ત્રણ પરવાનગીઓ અલગ રાખો અને દરેક દાવો ચકાસપાત્ર બને છે.