Android VpnService ಬಗ್ಗೆ ನಾಲ್ಕು ಊಹೆಗಳು ಒಮ್ಮೆ ನನ್ನ ವಾರದ ಬಹುಪಾಲು ಸಮಯವನ್ನು ತಿಂದವು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೂ ನೆಟ್ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ ಬಗ್ಗೆ ಆಗಿರಲಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದಿತು, ಕೀ ಚಿಹ್ನೆ ಸ್ಟೇಟಸ್ ಬಾರ್ನಲ್ಲಿ ಕುಳಿತಿತ್ತು, ಮತ್ತು ಟ್ರಾಫಿಕ್ ಇನ್ನೂ ಸಾಮಾನ್ಯ ಮಾರ್ಗದಿಂದಲೇ ಹೊರಹೋಗುತ್ತಿತ್ತು. ಸುರಂಗ ನಾನು ನಿಲ್ಲಿಸುವವರೆಗೆ ನನ್ನದೇ ಎಂದು, ನಾನು ಸೇರಿಸಿದ ಮಾರ್ಗಗಳೇ ನನಗೆ ಸಿಗುವ ಮಾರ್ಗಗಳು ಎಂದು, ಮತ್ತು stopSelf ಕರೆದರೆ ಇಂಟರ್ಫೇಸ್ ಕೂಡ ಜೊತೆಗೆ ಇಳಿಯುತ್ತದೆ ಎಂದು ನಾನು ಊಹಿಸುತ್ತಲೇ ಇದ್ದೆ. ಸೇವೆ ಸಾಕ್ಷ್ಯೀಕರಿಸಿದಂತೆಯೇ ವರ್ತಿಸುತ್ತಿತ್ತು. ಒಡೆದ ಭಾಗ ನನ್ನ ಮಾನಸಿಕ ಮಾದರಿ.

ಮಿಥ್ 1: ನೀವು ಅದನ್ನು ನಿಲ್ಲಿಸುವವರೆಗೆ ಸುರಂಗ ನಿಂತಿರುತ್ತದೆ

Android ಒಂದೇ ಸಮಯಕ್ಕೆ ಒಂದು VPN ಇಂಟರ್ಫೇಸ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಎರಡನೆಯದನ್ನು ಸ್ಥಾಪಿಸಿ ಮತ್ತು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಅದನ್ನು ಸರದಿಯಲ್ಲಿ ಇಡುವುದಿಲ್ಲ, ಬದಲಿಗೆ ನಿಮ್ಮದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ನಿಮ್ಮ ಸೇವೆಯಲ್ಲಿ onRevoke() ಕರೆಯುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಕೇವಲ ಬಟನ್ ಒತ್ತಿದಾಗ ಮಾತ್ರ ಎಲ್ಲವನ್ನೂ ಒಡೆಯುವುದಾದರೆ, ವಶಪಡಿಸಿಕೊಳ್ಳುವಿಕೆ ಹಿಂದೆ ಒಂದು ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮತ್ತು ಒಂದು ರೀಡರ್ ಥ್ರೆಡ್ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಆರಂಭ ಎರಡನ್ನೂ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ.

VpnService ಉಲ್ಲೇಖ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ಗೆ ಈಗಾಗಲೇ ಒಪ್ಪಿಗೆ ಇದ್ದರೆ prepare() null ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರ ಇನ್ನೂ ಅನುಮೋದಿಸಬೇಕಿದ್ದರೆ Intent ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಆ ಒಪ್ಪಿಗೆ ನೀವು ಉದ್ದೇಶವನ್ನು startActivityForResult() ಮೂಲಕ ತಲುಪಿಸಿದರೆ ಮಾತ್ರ ಬರುತ್ತದೆ. ಈ ಹಸ್ತಾಂತರವನ್ನು ಬಿಟ್ಟರೆ establish() null ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅದನ್ನು ಅನುಮತಿ ಸಮಸ್ಯೆ ಎಂದಲ್ಲ, ಮೌನ ವೈಫಲ್ಯ ಎಂದು ಓದಲಾಗುತ್ತದೆ.

Always-on VPN ನೀವು ನಿಯಂತ್ರಿಸದ ಮಾಲೀಕನನ್ನು ಸೇರಿಸುತ್ತದೆ. ಬೂಟ್ ನಂತರ ಅಥವಾ ಕ್ರ್ಯಾಶ್ ನಂತರ ಸಿಸ್ಟಂ ಸುರಂಗವನ್ನು ಮರಳಿ ತರಬಹುದು, ಮತ್ತು ಬಳಕೆದಾರರು ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ VPN ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅದು ಹಿಂದಕ್ಕೆ ತಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಸ್ಥಗಿತದಷ್ಟೇ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮುಚ್ಚುವಂತೆ onRevoke() ನಿರ್ಮಿಸಿ, ಮತ್ತು ಅದನ್ನು ಮೂಲೆ ಪ್ರಕರಣವಲ್ಲ, ಪ್ರಮುಖ ನಿಲ್ಲಿಸುವ ಮಾರ್ಗ ಎಂದು ಪರಿಗಣಿಸಿ. ಬಳಕೆದಾರರು VPN ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಬದಲಿಸುತ್ತಾರೆ; ನಿಮ್ಮ ಕೋಡ್ ಅದನ್ನು ತಾಳಿಕೊಳ್ಳಬೇಕು.

ಮಿಥ್ 2: addRoute ನೀವು ಪಟ್ಟಿ ಮಾಡಿದ್ದನ್ನೇ ಸೆರೆಹಿಡಿಯುತ್ತದೆ

ಯಾವ ಪ್ಯಾಕೆಟ್ಗಳು ನಿಮ್ಮ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ತಲುಪುತ್ತವೆ ಎಂಬುದನ್ನು ಮಾರ್ಗಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ವ್ಯಾಪ್ತಿಯ ದೋಷವು ಕೆಲವು ಟ್ರಾಫಿಕ್ ಸುರಂಗದ ಮೂಲಕ ಹೋಗಿ ಕೆಲವು ಹೋಗದ ಕಿರಿಕಿರಿಯ ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. addRoute("0.0.0.0", 0) ಎಲ್ಲಾ IPv4 ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಅಂದರೆ ಈಗ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ನಿಮ್ಮ ಬಳಿಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಮುಂದೆ ಕಳುಹಿಸಬೇಕು ಅಥವಾ ಬಿಡಬೇಕು. ಒಂದೇ ಹೋಸ್ಟ್ಗೆ /32 ಬಹುತೇಕ ಏನನ್ನೂ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ನಿಮ್ಮ VPN ಎಂದೂ ಸ್ಥಾಪನೆಯಾಗದಂತೆ ವರ್ತಿಸುತ್ತದೆ.

ಕುಟುಂಬಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಎಣಿಸಲಾಗುತ್ತದೆ. IPv4 ಮಾತ್ರವಿರುವ ಮಾರ್ಗವು IPv6 ಅನ್ನು ಆಧಾರ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ದ್ವಿ-ಸ್ಟ್ಯಾಕ್ ಹೋಸ್ಟ್ ಸುರಂಗದ ಒಳಗೆ ಸಂಪೂರ್ಣ ಸಂಪರ್ಕಿತವಾಗಿ ಕಾಣುತ್ತಿದ್ದರೂ ಹೊರಗೆ ಹೆಸರು ಪರಿಹರಿಸಿ ಸಂಪರ್ಕಿಸಬಲ್ಲದು.

DNS ಅದೇ ತರ್ಕವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. addDnsServer() ಜೊತೆಗೆ ಸೇರಿಸಿದ ಸರ್ವರ್ಗಳು ಸುರಂಗದ ರಿಜಾಲ್ವರ್ ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಹೋಗುತ್ತವೆ, ಆದರೆ ತನ್ನದೇ ಎನ್ಕ್ರಿಪ್ಟ್ ಆದ DNS ಎಂಡ್ಪಾಯಿಂಟ್ ಅಥವಾ ಹೋಸ್ಟ್ನಾಮ್ಗೆ ಸೆಟ್ ಮಾಡಿದ Private DNS ಇರುವ ಅಪ್ಲಿಕೇಶನ್ ಅವನ್ನು ಸಂಪೂರ್ಣ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಹೆಸರುಗಳು ಒಂದು ಅಪ್ಲಿಕೇಶನ್ಗೆ ವಿಫಲವಾಗಿ ಇನ್ನೊಂದಕ್ಕೆ ಕೆಲಸ ಮಾಡಿದಾಗ, ಒಂದೇ ಮಾರ್ಗಕ್ಕೂ ಮುಟ್ಟುವ ಮೊದಲು ರಿಜಾಲ್ವರ್ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಮಿಥ್ 3: ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕಾರದ ನಿಯಮಗಳು ಎರಡೂ ಕಡೆಗೆ ತಿರುಗಿಸಬಹುದಾದ ಸ್ವಿಚ್

addDisallowedApplication() ಮತ್ತು addAllowedApplication() ಎರಡು ಫಿಲ್ಟರ್ಗಳಲ್ಲ, ಎರಡು ಮೋಡ್ಗಳು. ಬಿಲ್ಡರ್ ಪ್ರತಿ ಸುರಂಗಕ್ಕೆ ಒಂದು ಮಾದರಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂರು ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ಬಿಟ್ಟು ಎಲ್ಲವನ್ನೂ ಬಯಸುವ ಅಪ್ಲಿಕೇಶನ್ ನಿಷೇಧಿತ ಪಟ್ಟಿಯನ್ನು ಬಳಸಿ ಅನುಮತಿಸಿದ ಪಟ್ಟಿಯನ್ನು ಖಾಲಿ ಬಿಡುತ್ತದೆ. ಎರಡೂ ಪರಸ್ಪರ ಪ್ರತ್ಯೇಕ, ಮತ್ತು ಸೆಟ್ಟಿಂಗ್ಸ್ ಸ್ಕ್ರೀನ್ ಈಗಾಗಲೇ ಎರಡೂ ಟಾಗಲ್ಗಳನ್ನು ನೀಡಿದ ನಂತರ ಜನರು ಇದನ್ನು ರನ್ಟೈಮ್ನಲ್ಲಿ ತಿಳಿಯುತ್ತಾರೆ.

ಪ್ಯಾಕೇಜ್ ಗೋಚರತೆಯೂ ಕಚ್ಚುತ್ತದೆ. Android 11 ಮತ್ತು ನಂತರ ನೀವು ನೋಡುವ ಪ್ಯಾಕೇಜ್ಗಳಿಗೆ ಮಾತ್ರ ಹೆಸರು ಹೇಳಬಹುದು, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಚಲಾಯಿಸಲು ಅನುಮತಿ ಇಲ್ಲದ ಪ್ರಶ್ನೆಯಿಂದ ನಿರ್ಮಿಸಿದ ಹೊರಗಿಡುವ ಪಟ್ಟಿ ಮೌನವಾಗಿ ನಮೂದುಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಪಟ್ಟಿಯನ್ನು ನಂಬುವ ಮೊದಲು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ನಿಜವಾಗಿ ಏನನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದರೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಕೆಲಸದ ಪ್ರೊಫೈಲ್ಗಳು ಪ್ರೇಕ್ಷಕರನ್ನು ಮತ್ತೆ ವಿಭಜಿಸುತ್ತವೆ. ಪ್ರೊಫೈಲ್ನ ಒಳಗೆ ಪ್ರಾರಂಭವಾದ ಸುರಂಗ ಆ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಅದರ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಆವರಿಸುತ್ತದೆ, ಆದರೆ ವೈಯಕ್ತಿಕ ಬದಿ ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅದು ಒಮ್ಮೆ ತೆಗೆದುಕೊಳ್ಳುವ ವ್ಯಾಪ್ತಿಯ ನಿರ್ಧಾರ, ಮತ್ತು ಅದರ ಸ್ಥಾನ ಬೆಂಬಲ ಟಿಕೆಟ್ನಲ್ಲಲ್ಲ, ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿದೆ.

ಮಿಥ್ 4: stopSelf ಸುರಂಗವನ್ನು ಮುಗಿಸುತ್ತದೆ

ಇಲ್ಲ. ಇಂಟರ್ಫೇಸ್ establish() ಹಿಂತಿರುಗಿಸುವ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ನಲ್ಲಿ ಜೀವಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ತೆರೆದಿರುವಾಗ ಸೇವಾ ವಸ್ತು ಸಾಯಬಹುದು. ಮೊದಲು ParcelFileDescriptor ಮುಚ್ಚಿ, ಉಲ್ಲೇಖವನ್ನು ಬಿಡಿ, ರೀಡರ್ ಮತ್ತು ರೈಟರ್ ಥ್ರೆಡ್ಗಳನ್ನು ಸೇರಿಸಿ ಅಥವಾ ಅಡ್ಡಿಪಡಿಸಿ, ನಂತರ stopForeground(true) ಮತ್ತು stopSelf() ಅನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಕರೆಯಿರಿ.

ಮರೆತುಹೋದ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಸೇವೆಯು ತನ್ನದೇ ನಿಲ್ಲಿಸುವ ವಿನಂತಿಯಿಂದ ಬದುಕುಳಿದಂತೆ ಕಾಣುವ ಸಾಮಾನ್ಯ ಕಾರಣ, ಮತ್ತು ಅದನ್ನು ಸೇರಿಸಿದ ಅಪ್ಲಿಕೇಶನಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುವ ಹಳೆಯ ಮಾರ್ಗವನ್ನು ಅದು ವಿವರಿಸುತ್ತದೆ.

ತಿರುಗು ಮುರುಗು ತಪ್ಪು ಕೂಡ ಅಷ್ಟೇ ಸಾಮಾನ್ಯ: ರೀಡರ್ ಥ್ರೆಡ್ ಓದುವ ಮಧ್ಯದಲ್ಲಿರುವಾಗ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮುಚ್ಚುವುದು, ನಂತರ ಆ ಥ್ರೆಡ್ಗೆ ಯಾರೂ ಕೋಡ್ ಬರೆಯದ ವಿನಾಯಿತಿಯನ್ನು ನಿಭಾಯಿಸಲು ಬಿಡುವುದು. ಸ್ಥಗಿತದ ಕ್ರಮವನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ, ಬಳಕೆದಾರರ ಕ್ರಿಯೆ ಮತ್ತು onRevoke() ಎರಡೂ ಅದಕ್ಕೆ ಕರೆ ಮಾಡಲಿ.

ಸುರಂಗ ಸತ್ತಂತೆ ಕಂಡಾಗ ಏನನ್ನು ಪರಿಶೀಲಿಸಬೇಕು

ಸುರಂಗ ಏಳುವ ಮೊದಲು ದೀರ್ಘಾಯುಷ್ಯದ ಸಾಕೆಟ್ಗಳನ್ನು protect() ನಿಂದ ರಕ್ಷಿಸಿ. ಅದಿಲ್ಲದೆ ಸುರಂಗದ ಸ್ವಂತ ಸಾಗಣೆ ಮತ್ತೆ ಸುರಂಗದೊಳಗೆ ಮಾರ್ಗೀಕರಣಗೊಂಡು ಸಂಪರ್ಕವು ಸರ್ವರ್ ದೋಷದಂತೆಯೇ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ. ದೂರದ ನೆಟ್ವರ್ಕ್ನ ಹಿಂದೆ ಮಾತ್ರ ಇರುವ ವಿಳಾಸದ ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸಿ, ಕ್ಯಾಶ್ನಿಂದ ಅಥವಾ ಆಧಾರ ಮಾರ್ಗದಿಂದ ಉತ್ತರಿಸುವ ಸಾರ್ವಜನಿಕ ಸೈಟ್ನ ವಿರುದ್ಧವಲ್ಲ.

establish() ನ ಫಲಿತಾಂಶ, ಮಾರ್ಗಗಳು, ಹೊರಗಿಟ್ಟ ಪ್ಯಾಕೇಜ್ಗಳು ಮತ್ತು ಸ್ಥಗಿತದ ಕಾರಣವನ್ನು ದಾಖಲಿಸಿ. ಆ ನಾಲ್ಕು ಸಾಲುಗಳು ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯದೆ ಒಪ್ಪಿಗೆ ಸಮಸ್ಯೆಯನ್ನು ವ್ಯಾಪ್ತಿ ಸಮಸ್ಯೆಯಿಂದ ಮತ್ತು ಜೀವನಚಕ್ರ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು