બાકાત કરેલી એપ હજી ઓનલાઇન? એપ અને રૂટના નિયમો અલગ છે
Android એપને VPN માંથી બાકાત કરવાથી તે બ્લોક થતી નથી. પરવાનગી યાદીઓ, UID નીતિના નિયમો અને મોકલેલા રૂટ પાથના જુદા જુદા ભાગ નક્કી કરે છે.
પેકેજ બાકાત કરવું એ બ્લોક નહીં, રૂટિંગ સૂચના છે, તેથી VPN જોડાયા પછી લોડ થતાં પૃષ્ઠો અપેક્ષિત છે, નિષ્ફળતાનો પુરાવો નહીં. બાકાત કરવું એપને બ્લોક કરવાને બદલે ટનલમાંથી દૂર કરે છે, અને સામાન્ય નેટવર્ક તેનો ટ્રાફિક વહન કરે છે. અહીં બે અલગ નીતિઓ મળે છે: એક પ્રક્રિયાઓ પસંદ કરે છે, બીજી ગંતવ્યો પસંદ કરે છે. તેમને એ ક્રમમાં વાંચવાથી સમજાય છે કે જોડાયેલ આઇકોન અને કામ કરતી એપ વિરોધાભાસ કેમ નથી.
બાકાત નેટવર્કને ખુલ્લું કેમ રાખે છે
VpnService.Builder કાં તો પરવાનગી યાદી કાં તો પ્રતિબંધ યાદી સ્વીકારે છે, બંને ક્યારેય નહીં. પરવાનગી યાદીના પેકેજ જ ટનલમાંથી પસાર થાય છે. પ્રતિબંધ યાદી તેને ઉલટાવે છે: સૂચિબદ્ધ સિવાયનું દરેક પેકેજ ટનલ વાપરે છે, અને સૂચિબદ્ધ ભૌતિક પાથ રાખે છે. પરવાનગી યાદી હેઠળ ન સૂચિબદ્ધ પેકેજ પણ ટનલની બહાર હોય છે, તેથી તે મોડમાં મોટા ભાગની એપ માટે બાકાત એ સામાન્ય સ્થિતિ છે.
એથી સ્થાનિક પ્રતિબંધ એન્ટ્રી ફાયરવોલ નિયમ નહીં, રૂટિંગ નિર્ણય બને છે. જો જરૂરિયાત એપને યજમાન સુધી પહોંચતી રોકવાની હોય, તો ટનલે તેને આવરી લેવું પડે અને સર્વર કે સ્થાનિક નીતિએ ટ્રાફિક નકારવો પડે. એપને ટનલમાંથી દૂર કરવાથી ફક્ત એ બદલાય છે કે તેના પેકેટ કયું ઇન્ટરફેસ વહન કરે છે.
Play Store નો કિસ્સો સામાન્ય જાણી જોઈને લીધેલો ઉદાહરણ છે. સ્ટોર પેકેજ બાકાત કરવાથી ડાઉનલોડ્સ પાયાનું જોડાણ વાપરી શકે છે જ્યારે VPN એક્ઝિટ ટ્રાન્સફરમાં દખલ કરે, અને તે દર્શાવે છે કે બાકાત એટલે બ્લોક નહીં, બાજુ ચઢાવ.
એક પ્રોફાઇલ, એક યાદી
બંને કૉલ વપરાય તો નિર્માતા અપવાદ ફેંકે છે, તેથી તમારી સામેની પ્રોફાઇલ કાં પરવાનગી યાદી છે કાં પ્રતિબંધ યાદી. એ એક હકીકત જ નક્કી કરે છે કે પછીનું દરેક અવલોકન કેવી રીતે વાંચવું. રૂટિંગ કોષ્ટક પહેલાં કોડ કે સંચાલિત રૂપરેખાંકન તપાસો, કારણ કે યાદી જ બાકીના આઉટપુટનો અર્થ નક્કી કરે છે. સંકર પ્રોફાઇલ એવી સ્થિતિ નથી જે તમે જોઈ શકો.
આ ભેદ એ પણ અનુમાન કરે છે કે નવી સ્થાપિત એપ શું કરશે. પરવાનગી યાદી હેઠળ કોઈ તેને ઉમેરે ત્યાં સુધી તે બહાર રહે છે, જ્યારે પ્રતિબંધ યાદી હેઠળ તે ડિફૉલ્ટ રૂપે ટનલમાં જોડાય છે.
સંચાલિત રૂપરેખાંકનો એ જ પસંદગી જુદા કી નામો હેઠળ આપે છે, અને કેટલાક કન્સોલ તેને યાદીને બદલે પ્રતિ-એપ VPN મોડ તરીકે વર્ણવે છે. વર્તન તોપણ એ બે કૉલ સુધી જ આવે છે, તેથી લેબલ પર ભરોસો મૂકવાને બદલે સેટિંગને પેકેજ યાદી સુધી પાછું ટ્રેસ કરો. લેબલ અને યાદી ન મળે તો યાદી જીતે છે.
UID નિયમને અનુસરીને ટનલ કોષ્ટક સુધી જાઓ
Android દરેક એપને તેનું પોતાનું Linux વપરાશકર્તા ID આપે છે, અને VPN સેવા UID શ્રેણીઓ સાથે મેળ ખાતા નીતિ નિયમો સ્થાપિત કરે છે. મેળ ખાતો ટ્રાફિક એવા રૂટિંગ કોષ્ટકમાં મોકલાય છે જેનો ડિફૉલ્ટ રૂટ tun ઉપકરણ તરફ નિર્દેશ કરે છે. કોષ્ટક નંબર દરેક VPN ઇન્સ્ટન્સ માટે ફાળવાય છે, તેથી ફરી જોડાવા પછી કે બીજી VPN પ્રોફાઇલ બનાવ્યા પછી તે બદલાય છે.
નિયમોનું આઉટપુટ જ નકશો છે. દરેક લીટી એક લુકઅપ કોષ્ટકનું નામ આપે છે, અને તે કોષ્ટક એ ડિફૉલ્ટ રૂટ રાખે છે જે નક્કી કરે છે કે મેળ ખાતા પેકેટ ટનલમાં પ્રવેશે છે કે નહીં.
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>UID મેળવવા પહેલાં ત્રીજો આદેશ ચલાવો, પછી એ નિયમ શોધો જેની શ્રેણીમાં તે આવે છે. તે નિયમ કોષ્ટક નંબર તરફ નિર્દેશ કરે છે, અને ip route show table <n> તે નંબર સાથે tun ઉપકરણ દ્વારા ડિફૉલ્ટ રૂટ છે કે નહીં તે દર્શાવે છે. કોષ્ટકમાં ડિફૉલ્ટ ન હોય તો એપ પસંદ થયેલી છે પણ તેને પાથ નથી, જે બીજી નિષ્ફળતા છે.
આ આદેશોને ડિબગ કરી શકાય એવા બિલ્ડ કે એવા ઉપકરણની જરૂર છે જ્યાં adb shell નેટવર્ક સ્થિતિ વાંચી શકે. ઉત્પાદન હેન્ડસેટ પર પેકેજ મેનેજર હજી જવાબ આપે છે, પણ રૂટિંગ તપાસ નકારાઈ શકે છે, તેથી જે કરી શકો તે નોંધો અને બાકીનું અણચકાસાયેલું ગણો.
રૂટ પ્રીફિક્સ માંગે છે, એપ નહીં
Builder.addRoute ટનલ માટે ગંતવ્ય પ્રીફિક્સ માંગે છે. જે પ્રોફાઇલ ફક્ત 10.0.0.0/8 ઉમેરે છે તે એ પ્રીફિક્સ ટનલમાંથી મોકલે છે અને બાકીનું દરેક ગંતવ્ય ભૌતિક પાથ પર રાખે છે. તે સામાન્ય વિભાજિત ટનલિંગ છે, અને નિયમોએ કઈ એપ પસંદ કરી તેનાથી સ્વતંત્ર છે.
સર્વર-મોકલેલું રૂપરેખાંકન એ જ મોડેલ પ્રતિબિંબિત કરે છે. વ્યક્તિગત રૂટ પુશ પ્રીફિક્સ ઉમેરે છે, જ્યારે redirect-gateway નિર્દેશ ડિફૉલ્ટ રૂટ બદલી નાખે છે અને ટનલ જે એપ આવરે છે તેમના માટે બધું પકડી લે છે. તે નિર્દેશ દૂર કરવાથી ઉપકરણ પર કોઈ પણ ફેરફાર વિના ચાલતી ટનલ એક સબનેટ સુધી સંકોચાઈ શકે છે.
અસામાન્ય ગેટવે કે મેટ્રિક ક્વૉલિફાયર સાથેનો મોકલેલો રૂટ પણ સ્થાપિત ન થઈ શકે. સાદું પ્રીફિક્સ સ્વરૂપ પસંદ કરો અને ફોરવર્ડિંગ તથા NAT સર્વરને સોંપો.
સેટિંગ બદલતા પહેલાં છેદ વાંચો
ટનલ આવરેલી પ્રક્રિયાઓ અને માંગેલા ગંતવ્યોનું છેદ વહન કરે છે. આવરેલી એપ પ્રકાશિત પ્રીફિક્સની બહારનું સરનામું માંગે તો ભૌતિક નેટવર્કથી નીકળે છે. પ્રતિબંધિત પેકેજ એ પ્રીફિક્સની અંદરનું સરનામું માંગે તોપણ બહાર જ રહે છે. બંનેમાંથી કોઈ ખામી નથી; બંને એ બે નીતિઓ પોતાનું કામ કરે છે.
પ્રતિ-એપ VPN સંકળાયેલી એપને જોડાણ વગર પણ મૂકી શકે છે. જ્યારે on-demand બંધ હોય અને ટનલ નીચે હોય, ત્યારે એપ પ્રતિ-એપ VPN સાથે બંધાયેલી રહે છે અને તેની પાસે કોઈ વૈકલ્પિક માર્ગ નથી, જે નીતિની સ્થિતિને બદલે તૂટેલી એપ જેવું લાગે છે. on-demand ચાલુ કરવાથી, અથવા સંચાલન દ્વારા સંકળાણ દૂર કરવાથી, તે બદલાય છે.
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
એક વખતે એક અક્ષનું નિદાન કરો. પહેલાં પરવાનગી કે પ્રતિબંધ નક્કી કરો, બીજે સ્થાપિત UID નિયમો અને કોષ્ટકો વાંચો, અને અંતે એ જ ગંતવ્ય સામે બીજી એપ ચકાસો. બીજી એપ એક જ વિનંતીમાં પ્રક્રિયા પસંદગીને ગંતવ્ય પસંદગીથી અલગ કરે છે.
પરિણામ એપ, ગંતવ્ય અને કોષ્ટક નંબર તરીકે લખો. એ જ ત્રિપુટી છે જે આગળના ફેરફારે જાળવવી પડે.