Android VPN ആട്രിബ്യൂഷൻ: getConnectionOwnerUid vs /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 |
താരതമ്യം “പഴയത് vs പുതിയത്” അല്ല. ഒരു വായിക്കാവുന്ന ഫയൽ മുമ്പ് നിറവേറ്റിയിരുന്ന മൂന്ന് വ്യത്യസ്ത ജോലികളാണ് ഇപ്പോൾ മൂന്ന് വ്യത്യസ്ത കരാറുകളുള്ള മൂന്ന് വ്യത്യസ്ത ഇന്റർഫേസുകൾ നിറവേറ്റുന്നത്.
ലോക്കൽ വിലാസമാണ് ആപ്പിന്റെ അറ്റം
മെത്തേഡ് സിഗ്നേച്ചർ ഒരു പ്രോട്ടോക്കോൾ, ലോക്കൽ 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 ചെയ്യുന്നതോ, കേർണൽ പട്ടികകൾ ആഗോളമായി വായിക്കാവുന്നതാക്കുന്നതോ ആവശ്യപ്പെടുന്നില്ല. പരിമിതിയാണ് കാര്യം: പ്ലാറ്റ്ഫോം ആട്രിബ്യൂഷനെ ഒരു കരാറിന് പിന്നിലേക്ക് മാറ്റി, അതുവഴി ന്യായമായി ആവശ്യമുള്ള ഘടകത്തിന് മാത്രം ഉത്തരം ലഭ്യമാകും, മറ്റാർക്കും അല്ല.