Android પર chroot VPN: ટનલ કેમ કામ કરે છે અને એપ્સ કેમ તેને અવગણે છે
chroot પાથ રિઝોલ્યુશન બદલે છે, કર્નલ, નેટવર્ક નેમસ્પેસ કે Android ની VPN નોંધણી નહીં. તેમાંથી બે પરિણામ આવે છે અને બંને લોકોને આશ્ચર્યમાં મૂકે છે.
તમે ફોન પર chroot હેઠળ ચાલતું Linux વિતરણ મેળવો છો, તેમાં VPN ક્લાયન્ટ ઇન્સ્ટોલ કરો છો, અને શેલ જાહેર કરે છે કે ટનલ પૂર્ણ થઈ ગઈ છે. પછી તમે બ્રાઉઝર પર જાઓ છો અને ટ્રાફિક મોબાઇલ ડેટા દ્વારા બહાર જાય છે, જાણે કંઈ થયું જ ન હોય. અથવા ઊલટું: ફોનની દરેક એપ કનેક્ટિવિટી ગુમાવે છે કારણ કે ક્લાયન્ટે Android ખરેખર વાપરે છે તે નેમસ્પેસમાં ડિફોલ્ટ રૂટ ઉમેર્યો છે. આ બંને લક્ષણો એક જ ખૂટતા ભાગમાંથી આવે છે, અને બંનેમાંથી કોઈ VPN ક્લાયન્ટની ભૂલ નથી.
શેલ કહે છે જોડાયેલું, એપ્સ સહમત નથી
પહેલું પરિણામ સામાન્ય છે. chroot થી ખૂલેલી યુઝરસ્પેસ ટનલ તેનું હેન્ડશેક પૂર્ણ કરી શકે છે, આંકડા છાપી શકે છે અને એ જ શેલ જે ટ્રાફિક બનાવે છે તે વહન કરી શકે છે, જ્યારે Android ની એપ્સ ફોનનું ડિફોલ્ટ નેટવર્ક વાપરતી રહે છે. કંઈ તેમને રોકતું નથી, કારણ કે કંઈએ Android ને કહ્યું નથી કે VPN અસ્તિત્વમાં છે.
બીજું પરિણામ જોખમી છે. જો chroot Android નું નેટવર્ક નેમસ્પેસ વહેંચે છે, જે ડિફોલ્ટ રીતે થાય છે, તો પૂરતા અધિકારો ધરાવતી પ્રક્રિયા આખા ફોનને અસર કરતા રૂટ અને TUN ઇન્ટરફેસ ઉમેરી શકે છે. પછી ટનલ દરેક એપ માટે કામ કરે છે, જેને તમે રૂટ કરવા માંગતા ન હતા તે પણ સહિત, અને ફોનની કનેક્ટિવિટી હવે જીવનચક્ર વ્યવસ્થાપન, કનેક્શન સૂચક અને હંમેશા-ચાલુ નીતિ વગરના ડેમન પર આધારિત છે.
બેમાંથી કયું મળ્યું તે એક આદેશથી જાણી શકાય છે. chroot ની અંદર ip route ને બહારની Android શેલની એ જ આદેશ સાથે સરખાવો. સમાન આઉટપુટ એટલે chroot હોસ્ટ નેમસ્પેસમાં છે: તે જે પણ નેટવર્ક ફેરફાર કરે તે આખા ફોન માટે છે. અલગ આઉટપુટ એટલે લોન્ચરે તેના માટે નેમસ્પેસ બનાવ્યું છે, અને તેની ટનલ રચનાથી જ Android માટે અદ્રશ્ય છે.
chroot એ શું બદલ્યું અને શું નહીં
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
chroot સિસ્ટમ કૉલ એક કામ કરે છે: પાથ રિઝોલ્યુશન માટે વપરાતી ડિરેક્ટરી બદલે છે. man પૃષ્ઠ સ્પષ્ટ કહે છે કે તે સુરક્ષા સીમા નથી, અને ઇન્ટરફેસ, રૂટ કે VPN સ્થિતિ વિશે કંઈ કહેતું નથી. લોકો Linux કન્ટેનરથી જે અપેક્ષા રાખે છે — અલગ નેટવર્ક સ્ટેક, ફિલ્ટર કરેલી ફાઇલસિસ્ટમ, સ્રોત મર્યાદા — તે બીજી પદ્ધતિઓમાંથી આવે છે જે લોન્ચરે વાપરી હોય કે ન હોય.
તેથી chroot એ VPN ને અલગ પાડે છે એવા દાવા સામાન્ય રીતે ખોટા પ્રશ્નનો જવાબ આપે છે. સંબંધિત પ્રશ્ન એ છે કે પ્રક્રિયા કયા નેમસ્પેસમાં ચાલે છે અને કયા SELinux ડોમેનમાં મર્યાદિત છે, અને બંને તે કેવી રીતે શરૂ થયું તેની લાક્ષણિકતા છે, chroot શબ્દની નહીં.
TUN ને ત્રણ વસ્તુ જોઈએ, અને ડિવાઇસ નોડ તેમાંનું એક જ છે
પરંપરાગત યુઝરસ્પેસ ટનલને પોતે ખોલી શકે તેવું TUN ડિવાઇસ, તે ડિવાઇસ માટે કર્નલ સપોર્ટ અને ઇન્ટરફેસ તથા રૂટ ગોઠવવાની પરવાનગી જોઈએ. આ અલગ જરૂરિયાતો છે, અને /dev હેઠળ પાથ નામ બનાવવાથી પોતાની રીતે તેમાંની એક પણ પૂરી થતી નથી:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunAndroid માં કર્નલમાં TUN સપોર્ટ સામાન્ય રીતે કમ્પાઇલ થયેલો હોય છે, કારણ કે પ્લેટફોર્મની પોતાની VPN સેવા તેનો ઉપયોગ કરે છે, પરંતુ તેનો અર્થ એ નથી કે તમારી પ્રક્રિયાને તે વાપરવાની પરવાનગી છે. ઇન્ટરફેસ ગોઠવવા માટે નેટવર્ક વ્યવસ્થાપન ક્ષમતા જરૂરી છે, અને SELinux નક્કી કરે છે કે પ્રક્રિયા ડિવાઇસ નોડ સુધી પહોંચી શકે છે કે નહીં. અસ્વીકાર સ્પષ્ટ કારણ વગરની પરવાનગી ભૂલ જેવો લાગે છે, અને જવાબ ઓડિટ ટ્રેલમાં છે:
dmesg | grep avc
logcat -d | grep "avc: denied"root આને ઉકેલતું નથી. SELinux uid 0 હેઠળ ચાલતી પ્રક્રિયાઓને બીજા જેવી જ મર્યાદિત કરે છે, તેથી root શેલથી શરૂ થયેલું chroot પણ જે ડિવાઇસ જુએ છે તેના માટે નકાર મેળવી શકે છે. જૂનું ઇન્સ્ટોલર ચાલે તે માટે એન્ફોર્સમેન્ટ બંધ કરવું આખા ફોન માટેનો નિર્ણય છે જેની અસર ટનલથી ઘણી આગળ જાય છે, અને તે જૂની બાઇનરીનો ઉપાય નથી.
Android એપ્સ તમારી ટનલને કેમ અવગણે છે
Android નું સમર્થિત મોડેલ એ VPN એપ છે જે પ્લેટફોર્મની VPN સેવામાં નોંધણી કરે છે, વપરાશકર્તા પાસે એક વાર સંમતિ માંગે છે અને પોતાની ટનલ માટે ફાઇલ ડિસ્ક્રિપ્ટર મેળવે છે. પછી પ્લેટફોર્મ ટ્રાફિક તે ડિસ્ક્રિપ્ટરમાં મોકલે છે અને વપરાશકર્તા કે એડમિનિસ્ટ્રેટરે પસંદ કરેલો એપ વ્યાપ લાગુ કરે છે, તેથી એ જ પદ્ધતિ પ્રતિ-એપ, પ્રતિ-પ્રોફાઇલ અને હંમેશા-ચાલુ તથા VPN વગર બ્લોક સાથે જોડી શકાય છે. Android VPN ડેવલપમેન્ટ માર્ગદર્શિકા તે હેન્ડશેક વર્ણવે છે, અને મુખ્ય મુદ્દો એ છે કે તે નોંધણી છે, રૂટિંગ યુક્તિ નહીં.
chroot ની અંદરનો ડેમન ક્યારેય નોંધણી કરતો નથી. સંમતિ સંવાદ નથી, સ્ટેટસ બારમાં ચાવીનું ચિહ્ન નથી, પ્રતિ-એપ સમાવેશ કે બાકાત યાદી નથી, અને હંમેશા-ચાલુ નીતિમાં ભાગીદારી નથી. તેથી એપ્સ ડિફોલ્ટ નેટવર્ક વાપરતી રહે છે, અને ટનલ ફક્ત શેલ પોતે મોકલે તે વહન કરે છે.
વિરુદ્ધ દિશા પણ મદદ કરતી નથી. રૂટને હોસ્ટ નેમસ્પેસમાં ધકેલવાથી બધું પકડાય છે, પ્લેટફોર્મ સ્થાનિક રાખવા માંગતો ટ્રાફિક પણ, અને તે પ્રતિ-એપ નિયંત્રણ વગર, વપરાશકર્તા જોઈ કે રદ કરી શકે તેવી રીત વગર કરે છે. એવી કોઈ મધ્યમ સેટિંગ નથી જ્યાં chroot ડેમન ફક્ત એક એપ માટે ટ્રાફિક રૂટ કરે.
બાઇનરી સુસંગતતા અલગ દીવાલ છે
નેટવર્ક બાજુ રસપ્રદ હોય તો પણ, એક્ઝિક્યુટેબલની પોતાની જરૂરિયાતો છે: CPU આર્કિટેક્ચર, ડાયનેમિક લોડર, C લાઇબ્રેરી અને જે કર્નલ ક્ષમતાઓની તે અપેક્ષા રાખે છે. Android glibc ને બદલે bionic વાપરે છે, અને ડેસ્કટોપ વિતરણ માટે બનેલી જૂની બાઇનરીને એવી લાઇબ્રેરીની જરૂર પડી શકે જે ડિવાઇસ પર હવે નથી.
લાઇબ્રેરી ફાઇલનું નામ નવા સંસ્કરણ સાથે જોડવાથી ABI સુસંગતતા બનતી નથી, અને દસ વર્ષ જૂના પેકેજમાંથી સંગ્રહિત ક્રિપ્ટોગ્રાફી લાઇબ્રેરી સંભાળાયેલો ઘટક નથી. જો યોજના તેના પર આધારિત હોય, તો યોજના ફોન પર નેટવર્ક વિશેષાધિકાર સાથે અણસંભાળ્યો કોડ ચલાવવાની છે.
Android સંદર્ભમાં સાબિત કરો અને પછી સાફ કરો
તમને ખરેખર જે મહત્વનું છે તે મહત્વની બાજુથી ચકાસો: ચોક્કસ એપ ખોલો, ચોક્કસ ખાનગી ગંતવ્ય સુધી પહોંચો, કયા રિઝોલ્વરે જવાબ આપ્યો તે નિશ્ચિત કરો, પછી ટનલ ડિસ્કનેક્ટ કરો અને દસ્તાવેજીકૃત વર્તન નિશ્ચિત કરો. chroot ની અંદરની ટર્મિનલનું પરિણામ ફક્ત તે ટર્મિનલના અમલ સંદર્ભનો પુરાવો છે, તેનાથી વધુ નહીં.
જો પ્રયોગ દરમિયાન હોસ્ટ રૂટ બદલ્યા હોય તો તે પાછા ફેરવો અને શું બદલ્યું તે નોંધો. પછી જુઓ કે ફોનમાં હંમેશા-ચાલુ VPN ગોઠવાયેલી છે કે નહીં, કારણ કે નિયમ છોડી ગયેલો જૂનો પ્રયોગ મહિનાઓ પછી પ્લેટફોર્મની ખામી જેવો લાગી શકે છે.
ખરેખર દૂરસ્થ પ્રવેશની જરૂર માટે સેવાનો સમર્થિત ક્લાયન્ટ કે મંજૂર ગેટવે ડિઝાઇન વાપરો. પૂછવા લાયક પ્રશ્ન એ નથી કે root ઇન્સ્ટોલર ચાલે તેમ કરી શકાય છે કે નહીં, પણ એ કે સમર્થિત અમલીકરણ તમને જરૂરી એપ્સને તમે ધારેલી સીમા પાર લઈ જાય છે કે નહીં, ડિવાઇસ પર માલિક વગરના વિશેષાધિકાર ફેરફારો મૂક્યા વગર.