Android VPN એટ્રિબ્યુશન: getConnectionOwnerUid વિરુદ્ધ /proc/net
Android 10 એપ્સથી /proc/net છુપાવે છે. VPN હજી પણ પેકેટ મેળવે છે, પરંતુ એટ્રિબ્યુશન પોતાના tuple અને પરવાનગી નિયમો સાથે getConnectionOwnerUid તરફ જાય છે.
Android 10 અને તે પછીના વર્ઝનમાં, /proc/net/tcp ખોલતી એપને socket ટેબલને બદલે ઍક્સેસ નકાર મળે છે. VPN ઇન્ટરફેસને તેની પરવા નથી: પેકેટ હજી પણ આવે છે, કારણ કે ટનલ રૂટિંગ નિર્ણય છે, ફાઇલ પરવાનગી નહીં. જે બદલાયું તે વધુ સાંકડા પ્રશ્નનો જવાબ છે: “કઈ એપ આ કનેક્શન ધરાવે છે?” વિકલ્પ છે ConnectivityManager.getConnectionOwnerUid, કનેક્શન દીઠ સમર્થિત ક્વેરી, અને જૂની ટેવ અને નવી API વચ્ચેની પસંદગી એના પર આધાર રાખે છે કે તમારી પાસે ખરેખર ત્રણ કામોમાંથી કયું છે: પેકેટ મેળવવા, ફ્લો એટ્રિબ્યુટ કરવો કે વપરાશનો સરવાળો કરવો.
માલિકના પ્રશ્નના બે જવાબ
API 29 પહેલાં, એક વિશેષાધિકારપ્રાપ્ત અથવા root પ્રોસેસ કર્નલના socket ટેબલ વાંચી શકતી, ચાર-ટ્યુપલ મેળવી શકતી અને માલિક UID જાણી શકતી. તે એક ફાઇલમાં આખા ઉપકરણની યાદી આપતું. API 29 થી ફાઇલસિસ્ટમ દૃશ્ય મર્યાદિત છે, અને સમર્થિત માર્ગ પ્રોટોકોલ, સ્થાનિક સરનામું અને દૂરના સરનામા સાથે કનેક્શન દીઠ ક્વેરી છે.
| Question | Legacy socket tables | getConnectionOwnerUid |
|---|---|---|
| Who owns this flow? | Scan and match the tuple | Ask once per tuple |
| Device-wide inventory? | Yes, when readable | No, one flow at a time |
| Historical usage? | No | No; that is NetworkStatsManager |
| Works without root? | No on modern releases | Yes, for authorized callers |
તુલના “જૂનું વિરુદ્ધ નવું” નથી. આ ત્રણ અલગ કામ છે જે પહેલાં એક વાંચી શકાય તેવી ફાઇલ પૂરી કરતી હતી અને હવે ત્રણ અલગ ઇન્ટરફેસ ત્રણ અલગ કરાર સાથે પૂરી કરે છે.
સ્થાનિક સરનામું એ એપનો છેડો છે
મેથડ સિગ્નેચર પ્રોટોકોલ, સ્થાનિક socket સરનામું અને દૂરનું socket સરનામું લે છે. “સ્થાનિક” એટલે કનેક્શનમાં એપની બાજુ, તપાસની ક્ષણે જે છેડો પેકેટનો સ્રોત બની જાય તે નહીં. દૂરના સર્વરથી એપ તરફ પાછા જતા પેકેટનો સ્રોત અને લક્ષ્ય તે વ્યાખ્યાની તુલનામાં ઉલટાયેલા હોય છે.
ConnectivityManager cm = getSystemService(ConnectivityManager.class);
int uid = cm.getConnectionOwnerUid(
OsConstants.IPPROTO_TCP, appLocalAddress, appRemoteAddress);આ દિશા ભૂલ એ સૌથી સામાન્ય કારણ છે કે કાર્યક્ષમ ક્વેરી ખોટો જવાબ આપે, અથવા કોઈ જ નહીં. કૉલ પહેલાં બંને છેડા લોગ કરો અને એપે ખરેખર ખોલેલા કનેક્શન સામે જોડીની ખાતરી કરો. સરનામા કુટુંબ પણ મહત્વનું છે: IPv4-મેપ કરેલું સરનામું અને મૂળ IPv6 સરનામું અલગ tuple છે, અને તે જ પોર્ટ પર TCP અને UDP ફ્લો પણ.
અધિકૃતિ અને અજ્ઞાત પરિણામો કરારનો ભાગ છે
ક્વેરી અધિકૃત કૉલર સુધી મર્યાદિત છે, જેમાં સંબંધિત વપરાશકર્તા માટેની સક્રિય VPN એપનો સમાવેશ થાય છે. અસંબંધિત મોનિટરિંગ એપ ધારી શકતી નથી કે તે બીજી પ્રોફાઇલના કનેક્શનની ગણતરી કરી શકે, અને અનધિકૃત કૉલ મૈત્રીપૂર્ણ ભૂલને બદલે સુરક્ષા અપવાદ ફેંકી શકે છે. બંને પરિણામોને સ્પષ્ટ રીતે સંભાળો.
ગેરહાજર માલિક પેકેજ નામ નથી. પેકેટ અને ક્વેરી વચ્ચે ફ્લો બંધ થઈ ગયો હોઈ શકે, tuple અપૂર્ણ હોઈ શકે, અથવા કૉલરને જાણવાની પરવાનગી જ ન હોઈ શકે. પ્રથમ સફળ જવાબ કેશ કરીને પછીથી ફરી વાપરવાથી નવું કનેક્શન જૂની એપને આરોપાય છે, જે અજ્ઞાત જાહેર કરવા કરતાં ખરાબ છે.
જ્યારે એટ્રિબ્યુશન નિષ્ફળ જાય, ત્યારે ટ્રાફિકને હજી પણ નિર્ણયની જરૂર છે: નીતિ જ્યાં માંગે ત્યાં તેને બ્લોક કરો, ફક્ત તમે સમજો તેવો વ્યાપ મંજૂર કરો, અથવા ગેપ દર્શાવો. તે ફોલબેક ડિઝાઇનનો ભાગ છે, ટિપ્પણીનો નહીં.
હિસાબ એ બીજો પ્રશ્ન છે
NetworkStatsManager પોતાના ઍક્સેસ નિયમો હેઠળ વપરાશનો અહેવાલ આપે છે. તે કહી શકે કે એક UID એ એક સમયગાળામાં કેટલું સ્થાનાંતરિત કર્યું; તે મનસ્વી જીવંત પેકેટનો માલિક કહી શકતું નથી. નેટવર્ક ક્ષમતાઓ નેટવર્કના ગુણધર્મો વર્ણવે છે, socket ની ડિરેક્ટરી નહીં. ત્રણેય ભેળવવાથી એવા ડેશબોર્ડ બને છે જે સુસંગત દેખાય છે અને હોય નહીં.
કઈ એપ ટનલ વાપરે છે તે નક્કી કરવાના સરળ કિસ્સા માટે, Androidની સમર્થિત મંજૂર અને પ્રતિબંધિત એપ્લિકેશન યાદીઓ કોઈ સ્ક્રેપિંગ વિના જ નીતિ વ્યક્ત કરે છે. ફ્લો દીઠ એટ્રિબ્યુશન એવા કેસો માટે રાખો જેને ખરેખર તેની જરૂર છે, અને દિશા, પરવાનગીઓ અને અજ્ઞાત સ્થિતિઓ સાથે મળીને સંભાળતા જાળવણીક્ષમ અમલ માટે બજેટ રાખો.
કામ પ્રમાણે સાધન પસંદ કરો, પછી કિનારા ચકાસો
જો જરૂરિયાત ટનલ પસંદગી હોય, તો પ્લેટફોર્મ યાદી વાપરો. જો તે જીવંત એટ્રિબ્યુશન હોય, તો માલિક ક્વેરી વાપરો અને દરેક જવાબ ન મળતા tupleને અજ્ઞાત ગણો. જો તે ઐતિહાસિક સરવાળા હોય, તો stats API વાપરો. પછી એ ત્રણ કિનારા ચકાસો જે ભોળા અમલને તોડે છે: વિરુદ્ધ દિશાનું પેકેટ, ક્વેરી પહેલાં બંધ થતો ફ્લો, અને એવો કૉલર જે સક્રિય VPN નથી.
આમાંથી કંઈપણ SELinux બંધ કરવા, ફોન root કરવા કે કર્નલ ટેબલ વૈશ્વિક રીતે વાંચી શકાય તેવા બનાવવા માંગતું નથી. મર્યાદા એ જ મુદ્દો છે: પ્લેટફોર્મે એટ્રિબ્યુશનને કરાર પાછળ ખસેડ્યું જેથી જવાબ તે ઘટકને ઉપલબ્ધ થાય જેને તેની કાયદેસર જરૂર છે, અને બીજા કોઈને નહીં.