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 |
ಹೋಲಿಕೆ “ಹಳೆಯದು ವಿರುದ್ಧ ಹೊಸದು” ಅಲ್ಲ. ಇವು ಮೂರು ವಿಭಿನ್ನ ಕೆಲಸಗಳು, ಹಿಂದೆ ಒಂದು ಓದಬಹುದಾದ ಫೈಲ್ ಪೂರೈಸುತ್ತಿದ್ದವು, ಈಗ ಮೂರು ವಿಭಿನ್ನ ಒಪ್ಪಂದಗಳೊಂದಿಗೆ ಮೂರು ವಿಭಿನ್ನ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಪೂರೈಸುತ್ತವೆ.
ಸ್ಥಳೀಯ ವಿಳಾಸವೇ ಆ್ಯಪ್‌ನ ತುದಿ
ವಿಧಾನದ ಸಹಿ ಪ್ರೋಟೋಕಾಲ್, ಸ್ಥಳೀಯ 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 ಮಾಡುವುದು ಅಥವಾ ಕರ್ನಲ್ ಕೋಷ್ಟಕಗಳನ್ನು ಜಾಗತಿಕವಾಗಿ ಓದಬಹುದಾಗಿಸುವುದು ಅಗತ್ಯವಿಲ್ಲ. ಮಿತಿಯೇ ಮುಖ್ಯ: ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಹೊಂದಾಣಿಕೆಯನ್ನು ಒಪ್ಪಂದದ ಹಿಂದೆ ಸರಿಸಿತು, ಇದರಿಂದ ಉತ್ತರವು ಕಾನೂನುಬದ್ಧವಾಗಿ ಅಗತ್ಯವಿರುವ ಘಟಕಕ್ಕೆ ಮಾತ್ರ ಲಭ್ಯವಾಗುತ್ತದೆ, ಬೇರೆ ಯಾರಿಗೂ ಅಲ್ಲ.