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 செயல்முறை kernel இன் 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 இன் ஆதரிக்கப்படும் அனுமதிக்கப்பட்ட மற்றும் தடைசெய்யப்பட்ட பயன்பாட்டுப் பட்டியல்கள் எந்த scraping இல்லாமலேயே கொள்கையை வெளிப்படுத்துகின்றன. உண்மையில் தேவைப்படும் வழக்குகளுக்கு ஓட்டத்திற்கான பண்புக்கூறை ஒதுக்கி வையுங்கள், திசை, அனுமதிகள் மற்றும் அறியாத நிலைகளை ஒன்றாகக் கையாளும் பராமரிக்கப்பட்ட செயலாக்கத்திற்கு பட்ஜெட் வைக்கவும்.
வேலைக்கேற்ப கருவியைத் தேர்ந்தெடுத்து, பின்னர் விளிம்புகளைச் சோதியுங்கள்
தேவை சுரங்கப்பாதைத் தேர்வு என்றால், தளப் பட்டியலைப் பயன்படுத்துங்கள். நேரடி பண்புக்கூறு என்றால், உரிமையாளர் வினவலைப் பயன்படுத்தி பதிலளிக்க முடியாத ஒவ்வொரு tuple ஐயும் அறியாதது எனக் கருதுங்கள். வரலாற்று மொத்தங்கள் என்றால், stats API ஐப் பயன்படுத்துங்கள். பின்னர் எளிய செயலாக்கங்களை உடைக்கும் மூன்று விளிம்புகளைச் சோதியுங்கள்: எதிர்த் திசைப் பாக்கெட், வினவலுக்கு முன் மூடப்படும் ஓட்டம், செயலில் உள்ள VPN அல்லாத அழைப்பாளர்.
இவற்றில் எதுவும் SELinux ஐ முடக்கவோ, தொலைபேசியை root செய்யவோ, kernel அட்டவணைகளை உலகளவில் படிக்கக்கூடியதாக்கவோ தேவையில்லை. கட்டுப்பாடே முக்கியம்: தளம் பண்புக்கூற்றை ஒரு ஒப்பந்தத்தின் பின்னால் நகர்த்தியது, அதனால் பதில் சட்டப்பூர்வமாகத் தேவைப்படும் கூறுக்கு மட்டுமே கிடைக்கும், வேறு யாருக்கும் அல்ல.