ಹೊರಗಿಡಲಾದ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಆನ್‌ಲೈನ್? ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಮಾರ್ಗದ ನಿಯಮಗಳು ಬೇರೆ

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

ಹೊರಗಿಡುವಿಕೆ ಜಾಲವನ್ನು ತೆರೆದಿಡುವುದೇಕೆ

VpnService.Builder ಅನುಮತಿ ಪಟ್ಟಿ ಅಥವಾ ನಿಷೇಧ ಪಟ್ಟಿ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಎರಡನ್ನೂ ಎಂದಿಗೂ ಅಲ್ಲ. ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಪ್ಯಾಕೇಜ್‌ಗಳು ಮಾತ್ರ ಸುರಂಗದ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ನಿಷೇಧ ಪಟ್ಟಿ ಅದನ್ನು ತಿರುಗಿಸುತ್ತದೆ: ಪಟ್ಟಿ ಮಾಡಿದವುಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಪ್ರತಿ ಪ್ಯಾಕೇಜ್ ಸುರಂಗವನ್ನು ಬಳಸುತ್ತದೆ, ಮತ್ತು ಪಟ್ಟಿ ಮಾಡಿದವು ಭೌತಿಕ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡದ ಪ್ಯಾಕೇಜ್ ಸಹ ಸುರಂಗದ ಹೊರಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಮೋಡ್‌ನಲ್ಲಿ ಬಹುಪಾಲು ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಹೊರಗಿಡುವಿಕೆ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿ.

ಇದು ಸ್ಥಳೀಯ ನಿಷೇಧ ನಮೂದನ್ನು ಫೈರ್‌ವಾಲ್ ನಿಯಮವಲ್ಲ, ಮಾರ್ಗನಿರ್ದೇಶನ ನಿರ್ಣಯವನ್ನಾಗಿಸುತ್ತದೆ. ಅಗತ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಹೋಸ್ಟ್ ತಲುಪುವುದನ್ನು ತಡೆಯುವುದಾದರೆ, ಸುರಂಗವು ಅದನ್ನು ಆವರಿಸಬೇಕು ಮತ್ತು ಸರ್ವರ್ ಅಥವಾ ಸ್ಥಳೀಯ ನೀತಿ ಸಂಚಾರವನ್ನು ನಿರಾಕರಿಸಬೇಕು. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸುರಂಗದಿಂದ ತೆಗೆದರೆ ಅದರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಸಾಗಿಸುತ್ತದೆ ಎಂಬುದಷ್ಟೇ ಬದಲಾಗುತ್ತದೆ.

Play Store ಪ್ರಕರಣ ಸಾಮಾನ್ಯ ಉದ್ದೇಶಪೂರ್ವಕ ಉದಾಹರಣೆ. ಅಂಗಡಿ ಪ್ಯಾಕೇಜ್ ಹೊರಗಿಟ್ಟರೆ, VPN ನಿರ್ಗಮನವು ವರ್ಗಾವಣೆಗೆ ಅಡ್ಡಿಪಡಿಸಿದಾಗ ಡೌನ್‌ಲೋಡ್‌ಗಳು ಆಧಾರ ಸಂಪರ್ಕ ಬಳಸಬಹುದು, ಮತ್ತು ಹೊರಗಿಡುವಿಕೆ ಎಂದರೆ ನಿರ್ಬಂಧವಲ್ಲ, ಪಾರ್ಶ್ವದಾರಿ ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಒಂದು ಪ್ರೊಫೈಲ್, ಒಂದು ಪಟ್ಟಿ

ಎರಡೂ ಕರೆಗಳನ್ನು ಬಳಸಿದರೆ ನಿರ್ಮಾಪಕ ಅಪವಾದ ಎಸೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಮುಂದಿರುವ ಪ್ರೊಫೈಲ್ ಅನುಮತಿ ಪಟ್ಟಿ ಅಥವಾ ನಿಷೇಧ ಪಟ್ಟಿ. ಆ ಒಂದು ಸತ್ಯವೇ ನಂತರದ ಪ್ರತಿ ವೀಕ್ಷಣೆಯನ್ನು ಹೇಗೆ ಓದಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕಕ್ಕಿಂತ ಮೊದಲು ಕೋಡ್ ಅಥವಾ ನಿರ್ವಹಿತ ಸಂರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಪಟ್ಟಿಯೇ ಉಳಿದ ಔಟ್‌ಪುಟ್‌ನ ಅರ್ಥವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸಂಕರ ಪ್ರೊಫೈಲ್ ನೀವು ನೋಡಬಹುದಾದ ಸ್ಥಿತಿಯಲ್ಲ.

ಈ ವ್ಯತ್ಯಾಸ ಹೊಸದಾಗಿ ಸ್ಥಾಪಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನೂ ಊಹಿಸುತ್ತದೆ. ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿ ಯಾರಾದರೂ ಸೇರಿಸುವವರೆಗೆ ಅದು ಹೊರಗಿರುತ್ತದೆ, ನಿಷೇಧ ಪಟ್ಟಿಯಲ್ಲಿ ಡಿಫಾಲ್ಟ್ ಆಗಿ ಸುರಂಗ ಸೇರುತ್ತದೆ.

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

UID ನಿಯಮವನ್ನು ಸುರಂಗದ ಕೋಷ್ಟಕದವರೆಗೆ ಅನುಸರಿಸಿ

Android ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತನ್ನದೇ Linux ಬಳಕೆದಾರ ID ನೀಡುತ್ತದೆ, ಮತ್ತು VPN ಸೇವೆ UID ಶ್ರೇಣಿಗಳಿಗೆ ಹೊಂದುವ ನೀತಿ ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಹೊಂದುವ ಸಂಚಾರವನ್ನು ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವು tun ಸಾಧನದತ್ತ ತೋರಿಸುವ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಕೋಷ್ಟಕ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರತಿ VPN ದೃಷ್ಟಾಂತಕ್ಕೆ ಹಂಚಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಮರುಸಂಪರ್ಕ ಅಥವಾ ಎರಡನೇ VPN ಪ್ರೊಫೈಲ್ ರಚಿಸಿದ ನಂತರ ಅದು ಬದಲಾಗುತ್ತದೆ.

ನಿಯಮಗಳ ಔಟ್‌ಪುಟ್ ನಕ್ಷೆ. ಪ್ರತಿ ಸಾಲು ಒಂದು ಹುಡುಕಾಟ ಕೋಷ್ಟಕದ ಹೆಸರು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಆ ಕೋಷ್ಟಕವು ಹೊಂದುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸುರಂಗ ಪ್ರವೇಶಿಸುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹಿಡಿದಿಡುತ್ತದೆ.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

UID ಪಡೆಯಲು ಮೊದಲು ಮೂರನೇ ಆಜ್ಞೆ ಚಲಾಯಿಸಿ, ನಂತರ ಅದನ್ನು ಒಳಗೊಂಡ ಶ್ರೇಣಿಯ ನಿಯಮ ಹುಡುಕಿ. ಆ ನಿಯಮ ಕೋಷ್ಟಕ ಸಂಖ್ಯೆಯತ್ತ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ip route show table <n> ಆ ಸಂಖ್ಯೆಯೊಂದಿಗೆ tun ಸಾಧನದ ಮೂಲಕ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಕೋಷ್ಟಕದಲ್ಲಿ ಡಿಫಾಲ್ಟ್ ಇಲ್ಲದಿದ್ದರೆ ಅಪ್ಲಿಕೇಶನ್ ಆಯ್ಕೆಯಾಗಿದೆ ಆದರೆ ಮಾರ್ಗವಿಲ್ಲ, ಅದು ಬೇರೆ ವೈಫಲ್ಯ.

ಈ ಆಜ್ಞೆಗಳಿಗೆ ಡೀಬಗ್ ಮಾಡಬಹುದಾದ ಬಿಲ್ಡ್ ಅಥವಾ adb shell ಜಾಲ ಸ್ಥಿತಿ ಓದಬಲ್ಲ ಸಾಧನ ಬೇಕು. ಉತ್ಪಾದನಾ ಹ್ಯಾಂಡ್‌ಸೆಟ್‌ನಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕ ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ಮಾರ್ಗ ಪರಿಶೀಲನೆ ನಿರಾಕರಿಸಬಹುದು, ಆದ್ದರಿಂದ ಸಾಧ್ಯವಾದುದನ್ನು ದಾಖಲಿಸಿ ಉಳಿದದ್ದನ್ನು ಅಪರಿಶೀಲಿತ ಎಂದು ಪರಿಗಣಿಸಿ.

ಮಾರ್ಗವು ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲ, ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಕೋರುತ್ತದೆ

Builder.addRoute ಸುರಂಗಕ್ಕೆ ಗಮ್ಯ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಕೋರುತ್ತದೆ. ಕೇವಲ 10.0.0.0/8 ಸೇರಿಸುವ ಪ್ರೊಫೈಲ್ ಆ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಸುರಂಗದ ಮೂಲಕ ಕಳುಹಿಸಿ ಉಳಿದ ಪ್ರತಿ ಗಮ್ಯವನ್ನು ಭೌತಿಕ ಮಾರ್ಗದಲ್ಲಿ ಬಿಡುತ್ತದೆ. ಅದು ಸಾಮಾನ್ಯ ವಿಭಜಿತ ಸುರಂಗೀಕರಣ, ಮತ್ತು ನಿಯಮಗಳು ಯಾವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದವು ಎಂಬುದರಿಂದ ಸ್ವತಂತ್ರ.

ಸರ್ವರ್ ಕಳುಹಿಸಿದ ಸಂರಚನೆ ಅದೇ ಮಾದರಿಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ಮಾರ್ಗ ಕಳುಹಿಸುವಿಕೆಗಳು ಪೂರ್ವಪ್ರತ್ಯಯ ಸೇರಿಸುತ್ತವೆ, ಆದರೆ redirect-gateway ಸೂಚನೆ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸಿ ಸುರಂಗ ಆವರಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುತ್ತದೆ. ಆ ಸೂಚನೆ ತೆಗೆದರೆ ಸಾಧನದಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸುರಂಗ ಒಂದು ಉಪಜಾಲಕ್ಕೆ ಕುಗ್ಗಬಹುದು.

ಅಸಾಮಾನ್ಯ ಗೇಟ್‌ವೇ ಅಥವಾ ಮೆಟ್ರಿಕ್ ಅರ್ಹತೆ ಇರುವ ಕಳುಹಿಸಿದ ಮಾರ್ಗವೂ ಸ್ಥಾಪನೆಯಾಗದಿರಬಹುದು. ಸರಳ ಪೂರ್ವಪ್ರತ್ಯಯ ರೂಪವನ್ನು ಆರಿಸಿ ಮತ್ತು ಮುಂದುಗಡೆ ಹರಿಸುವಿಕೆ ಹಾಗೂ NAT ಅನ್ನು ಸರ್ವರ್ಗೆ ಬಿಡಿ.

ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ಛೇದನವನ್ನು ಓದಿ

ಸುರಂಗವು ಆವರಿಸಿದ ಪ್ರಕ್ರಿಯೆಗಳ ಮತ್ತು ಕೋರಿದ ಗಮ್ಯಗಳ ಛೇದನವನ್ನು ಸಾಗಿಸುತ್ತದೆ. ಆವರಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕಟಿತ ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಹೊರಗಿನ ವಿಳಾಸ ಕೇಳಿದರೆ ಭೌತಿಕ ಜಾಲದಿಂದ ಹೊರಡುತ್ತದೆ. ನಿಷಿದ್ಧ ಪ್ಯಾಕೇಜ್ ಆ ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಒಳಗಿನ ವಿಳಾಸ ಕೇಳಿದಾಗಲೂ ಹೊರಗಿರುತ್ತದೆ. ಎರಡೂ ದೋಷವಲ್ಲ; ಎರಡೂ ಆ ಎರಡು ನೀತಿಗಳು ತಮ್ಮ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ.

ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ VPN ಸಂಬಂಧಿತ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಂಪರ್ಕವಿಲ್ಲದೆ ಬಿಡಬಹುದು. on-demand ಆಫ್ ಆಗಿದ್ದು ಸುರಂಗ ಕೆಳಗಿದ್ದಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ VPN ಗೆ ಬದ್ಧವಾಗಿ ಉಳಿದು ಯಾವುದೇ ಪರ್ಯಾಯ ಮಾರ್ಗವಿಲ್ಲ, ಅದು ನೀತಿ ಸ್ಥಿತಿಯಲ್ಲ, ಮುರಿದ ಅಪ್ಲಿಕೇಶನ್‌ನಂತೆ ಕಾಣುತ್ತದೆ. on-demand ಆನ್ ಮಾಡುವುದು, ಅಥವಾ ನಿರ್ವಹಣೆಯ ಮೂಲಕ ಸಂಬಂಧ ತೆಗೆಯುವುದು ಅದನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಒಂದು ಬಾರಿಗೆ ಒಂದು ಅಕ್ಷವನ್ನು ನಿರ್ಣಯಿಸಿ. ಮೊದಲು ಅನುಮತಿ ಅಥವಾ ನಿಷೇಧ ದೃಢೀಕರಿಸಿ, ಎರಡನೆಯದಾಗಿ ಸ್ಥಾಪಿತ UID ನಿಯಮ ಮತ್ತು ಕೋಷ್ಟಕಗಳನ್ನು ಓದಿ, ಕೊನೆಯದಾಗಿ ಅದೇ ಗಮ್ಯದ ವಿರುದ್ಧ ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷಿಸಿ. ಎರಡನೇ ಅಪ್ಲಿಕೇಶನ್ ಒಂದೇ ವಿನಂತಿಯಲ್ಲಿ ಪ್ರಕ್ರಿಯೆ ಆಯ್ಕೆಯನ್ನು ಗಮ್ಯ ಆಯ್ಕೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.

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