ಹಾಟ್‌ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸ್ಪ್ಲಿಟ್ ಟನೆಲಿಂಗ್ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಹೊರಗಿಡುವಿಕೆ ಅಲ್ಲ
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು VPN ನಿಂದ ಹೊರಗಿಡುವುದು ಫೋನ್ ಅನ್ನು ಮಾತ್ರ ಬದಲಿಸುತ್ತದೆ. ಟೆಥರ್ ಆದ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ತನ್ನದೇ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮ ಬೇಕು, ಅದು ಮೂಲ, ಗಮ್ಯ ಮತ್ತು NAT ಮೇಲೆ ಹೊಂದಿಸಲಾಗುತ್ತದೆ.
ಒಂದೇ ರೀತಿ ಕೇಳಿಸುವ ಎರಡು ಅಗತ್ಯಗಳು ಒಂದೇ ಅಲ್ಲ: «ಈ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು VPN ನಿಂದ ಹೊರಗಿಡು» ಮತ್ತು «ಈ ಒಂದು ಗಮ್ಯವನ್ನು ನನ್ನ ಹಾಟ್‌ಸ್ಪಾಟ್‌ನಲ್ಲಿರುವ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಾಗಿ VPN ನ ಹೊರಗೆ ಕಳುಹಿಸು». ಮೊದಲನೆಯದು ಫೋನ್‌ನಲ್ಲಿನ ಸಾಕೆಟ್ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಫೋನ್ ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ ನಂತರ ಇನ್ನೊಂದು ಸಾಧನದಿಂದ ಬಂದ ಪ್ಯಾಕೆಟ್‌ಗಾಗಿ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಧಾರವನ್ನು ಬದಲಿಸಬೇಕು. ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಹಾಟ್‌ಸ್ಪಾಟ್ ಕ್ಲೈಂಟ್ ಯಾವಾಗಲೂ ಫೋನ್‌ನ ಸ್ವಂತ ಬ್ರೌಸರ್‌ಗೆ ಮಾತ್ರ ಅನ್ವಯವಾಗಿದ್ದ ವಿನಾಯಿತಿಯೊಂದಿಗೆ ಉಳಿಯುವಂತೆ ಮಾಡುತ್ತದೆ.
ಎರಡು ಪ್ರಶ್ನೆಗಳ ಮಾಲೀಕರು ಎರಡು ಬೇರೆ ಉಪವ್ಯವಸ್ಥೆಗಳು
Android ಅಪ್ಲಿಕೇಶನ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಮತ್ತು ಟೆಥರಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಾಕೆಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕ ಸ್ಟ್ಯಾಕ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ನಿಯೋಜಿಸುತ್ತದೆ, ಮತ್ತು VPN ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಸ್ವಂತ ಸಾಕೆಟ್‌ಗಳಲ್ಲಿ ಯಾವುವು ಟನೆಲ್ ಪ್ರವೇಶಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಟೆಥರ್ ಆದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಟೆಥರಿಂಗ್ ಉಪವ್ಯವಸ್ಥೆ ನಿರ್ವಹಿಸುತ್ತದೆ, ಅದು netd ನಿಂದ ಮಾರ್ಗಗಳು, ನೀತಿ ನಿಯಮಗಳು ಮತ್ತು ಕೆಳಮುಖ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಅನುವಾದವನ್ನು ಕೇಳುತ್ತದೆ.
ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಹೊರಗಿಡುವಿಕೆಯನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಸಾಕೆಟ್ ತೆರೆದಾಗ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ. ಫಾರ್ವರ್ಡ್ ಆದ ಪ್ಯಾಕೆಟ್ ಆ ಪರಿಶೀಲನೆಗೆ ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಈ ಸಾಧನದ ಅಪ್ಲಿಕೇಶನ್ ಸಾಕೆಟ್‌ನಿಂದ ಹುಟ್ಟಿಲ್ಲ. ಎರಡು ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಒಂದಕ್ಕೊಂದು ಬದಲಾಗಲು ಸಾಧ್ಯವಿಲ್ಲದ ಸಂಪೂರ್ಣ ಕಾರಣ ಇದೇ, ಮತ್ತು ಇದು ಎರಡರಲ್ಲೂ ದೋಷವಲ್ಲ.
ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಹೊರಗಿಡುವಿಕೆ ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ
VpnService ನ ಬಿಲ್ಡರ್ addDisallowedApplication ನೊಂದಿಗೆ ಟನೆಲ್‌ನ ಹೊರಗೆ ಉಳಿಯುವ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಹೆಸರಿಸಬಹುದು, ಅಥವಾ addAllowedApplication ನೊಂದಿಗೆ ಒಳಗೆ ಅನುಮತಿಸಲಾದ ಏಕೈಕ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಹೆಸರಿಸಬಹುದು. ಆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ನಂತರ ಆಧಾರ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸಾಕೆಟ್‌ಗಳನ್ನು ತೆರೆಯುತ್ತವೆ, ಆದರೆ VPN ಉಳಿದ ಎಲ್ಲದಕ್ಕೂ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ವ್ಯಾಪ್ತಿ ನಿಖರವಾಗಿದೆ: ಪ್ಯಾಕೇಜ್‌ನ ಸ್ವಂತ ಸಾಕೆಟ್‌ಗಳು, ಈ ಸಾಧನದಲ್ಲಿ, ಟನೆಲ್ ಮೇಲಿರುವವರೆಗೆ. ಇದು ಫಾರ್ವರ್ಡ್ ಆದ ಸಂಚಾರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಎರಡನೇ ಸಾಧನದ ಬಗ್ಗೆ ಏನೂ ಇಲ್ಲ, ಮತ್ತು ಸಿಸ್ಟಂ ಟೆಥರಿಂಗ್ ಪರವಾಗಿ ಕಳುಹಿಸುವ ಪ್ಯಾಕೆಟ್‌ಗಳ ಬಗ್ಗೆ ಏನೂ ಇಲ್ಲ.
ಇದು ಗಮ್ಯ ನಿಯಂತ್ರಣವೂ ಅಲ್ಲ. ಬ್ರೌಸರ್ ಅನ್ನು ಹೊರಗಿಡುವುದು ಆ ಬ್ರೌಸರ್ ತಲುಪುವ ಪ್ರತಿಯೊಂದು ವಿಳಾಸವನ್ನೂ ಹೊರಗಿಡುತ್ತದೆ, ನೀವು ಟನೆಲ್ ಒಳಗೆ ಇಡಲು ಬಯಸಿದ್ದನ್ನು ಸಹ. ಅಗತ್ಯವು ಅಪ್ಲಿಕೇಶನ್ ಬದಲು ಗಮ್ಯವನ್ನು ಹೆಸರಿಸಿದಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಆಯ್ಕೆದಾರನೇ ರಚನೆಯಿಂದ ತಪ್ಪು ಸಾಧನ.
ಫೋನ್‌ಗೆ ಟೆಥರ್ ಆದ ಪ್ಯಾಕೆಟ್ ಹೇಗೆ ಕಾಣುತ್ತದೆ
ಕ್ಲೈಂಟ್‌ನ ಪ್ಯಾಕೆಟ್ ಹಾಟ್‌ಸ್ಪಾಟ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಫೋನ್ ನೀಡಿದ ಖಾಸಗಿ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ, ಹೇಳಿಕೆ 192.168.43.20, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಗಮ್ಯದೊಂದಿಗೆ ಬರುತ್ತದೆ. ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಫೋನ್‌ಗೆ ಮೇಲ್ಮುಖ ಕೊಂಡಿಗೆ ಮಾರ್ಗ ಮತ್ತು ಅನುವಾದ ನಿಯಮ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಉತ್ತರಗಳು ಹಿಂತಿರುಗುವ ದಾರಿ ಕಂಡುಕೊಳ್ಳಲಾರವು, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್‌ನ ಖಾಸಗಿ ವಿಳಾಸ ಸೆಲ್ಯುಲರ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅರ್ಥಹೀನ.
Android ಇದನ್ನು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ನೀತಿ ನಿಯಮಗಳಿಂದ ವ್ಯಕ್ತಪಡಿಸುತ್ತದೆ, ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಹಾಗೂ VPN ಬದಲಾದಾಗ netd ಸಂಬಂಧಿತ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ನಿಯಮಗಳನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತದೆ. ಫೋರಂ ಪೋಸ್ಟ್‌ನಿಂದ ಅಥವಾ ಅದೇ ಮಾದರಿಯ ಹಳೆಯ ಬಿಡುಗಡೆಯಿಂದ ನಕಲಿಸಿದ ಕೋಷ್ಟಕ ಸಂಖ್ಯೆ, ನಿಯಮ ಆದ್ಯತೆ ಅಥವಾ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರು ಶಾಶ್ವತ ಮಾಲೀಕತ್ವವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ. ಈ ಮರುನಿರ್ಮಾಣವೇ ಕೈಯಿಂದ ಬರೆದ ನಿಯಮ ಒಂದು ಗಂಟೆ ಕೆಲಸ ಮಾಡಿ ಮುಂದಿನ ಮರುಸಂಪರ್ಕದ ನಂತರ ನಿಲ್ಲಬಹುದಾದ ಕಾರಣ.
ಹಾಟ್‌ಸ್ಪಾಟ್ ವಿನಾಯಿತಿಗೆ ನಿಜವಾಗಿ ಯಾವ ನೀತಿ ಬೇಕು
ಯಾವುದೇ ನಿಯಮವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ನಿರ್ಧಾರವನ್ನು ಮೂಲ, ಗಮ್ಯ ಮತ್ತು ಉದ್ದೇಶಿತ ಮಾರ್ಗವಾಗಿ ಬರೆಯಿರಿ. ಒಂದು ಅನುಮೋದಿತ ಗಮ್ಯಕ್ಕೆ ಕನಿಷ್ಠ ರೂಪ ಹೀಗಿದೆ:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
ಎರಡೂ ದಿಕ್ಕುಗಳು ಪೂರ್ಣವಾಗಿರಬೇಕು. ನೇರ ಶಾಖೆಗೆ ಪ್ರಸ್ತುತ ಇರುವ ಸೆಲ್ಯುಲರ್ ಮೇಲ್ಮುಖ ಕೊಂಡಿಯ ಮೂಲಕ ಬಳಸಬಹುದಾದ ಮಾರ್ಗ ಬೇಕು; VPN ಶಾಖೆಗೆ ಟನೆಲ್ ಮಾರ್ಗ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಅನುಮತಿ ಬೇಕು. ಯಾವುದೇ ಮೂಲ ಅನುವಾದ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ನಿರ್ಗಮನಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಏಕೆಂದರೆ ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಅನ್ವಯಿಸಿದ NAT ಟನೆಲ್‌ನ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ, ಸೆಲ್ಯುಲರ್‌ನದನ್ನಲ್ಲ, ಮತ್ತು ಆಗ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಹೋಗುವ ಮಾರ್ಗಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಉತ್ತರಗಳು ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ ಸ್ಥಿತಿ ಅಥವಾ ಸ್ಪಷ್ಟ ಮಾರ್ಗದ ಮೂಲಕ ಅದೇ ಕೆಳಮುಖ ಕ್ಲೈಂಟ್ ತಲುಪಬೇಕು, ಮತ್ತು ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ ಅದರಲ್ಲಿ ಯಾವುದನ್ನೂ ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ. VPN ನ ಸ್ವಂತ ಹೊರ ಸಾಗಣೆಯನ್ನೂ ವಿನಾಯಿತಿಯ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ ಇಡಿ, ಇಲ್ಲದಿದ್ದರೆ ಟನೆಲ್‌ನ ವಾಹಕ ಪ್ಯಾಕೆಟ್‌ಗಳು ಕ್ಲೈಂಟ್‌ನ ವೆಬ್ ವಿನಂತಿಗಾಗಿ ಬರೆದ ನೀತಿಯನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತವೆ.
ಸೆರೆಹಿಡಿದ ಒಂದು ವಿಳಾಸ ಗಮ್ಯವಲ್ಲ
ಬ್ರೌಸರ್‌ನಿಂದ ಓದಿದ ಒಂದೇ IPv4 ವಿಳಾಸ ಒಂದು ಕ್ಷಣದ ಚಿತ್ರ. ದೊಡ್ಡ ಸೇವೆಗಳು anycast ನಿಂದ ಅಥವಾ ತಿರುಗುವ ಅಂಚಿನ ವಿಳಾಸಗಳ ಗುಂಪಿನಿಂದ ಉತ್ತರಿಸುತ್ತವೆ, ಅನೇಕವು ದ್ವಿ-ಸ್ಟ್ಯಾಕ್, ಮತ್ತು ಲಾಗಿನ್ ಹರಿವು ಪುಟ ಎಂದಿಗೂ ತೋರಿಸದ ದೃಢೀಕರಣ ಮತ್ತು ಟೆಲಿಮೆಟ್ರಿ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಮುಟ್ಟಬಹುದು. ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ನೋಡಿದ ವಿಳಾಸದ ಸುತ್ತ ಕಟ್ಟಿದ ವಿನಾಯಿತಿ ಮುಂದಿನ ಸಲ ಸೇವೆ ಲೋಡ್ ಮರುಸಮತೋಲನ ಮಾಡಿದಾಗ ಮುರಿಯುತ್ತದೆ.
ಸೇವೆಯ ಮಾಲೀಕರ ದಾಖಲಿತ ವಿಳಾಸಗಳನ್ನು, ಅಥವಾ ಅವರು ಪ್ರಕಟಿಸುವ ಶ್ರೇಣಿಯನ್ನು ಬಳಸಿ, ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ. ಅಗತ್ಯವನ್ನು ಸ್ಥಿರ ಗುಂಪಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅದು ಬಹುಶಃ ಸೇವೆಗೆ ನೀತಿ ಪ್ರಶ್ನೆಯೇ ಹೊರತು ಫೋನ್‌ನಲ್ಲಿ ರೂಟಿಂಗ್ ಉಪಾಯವಲ್ಲ.
ಕೆಳಮುಖ ಬದಿಯಿಂದ ಪರಿಶೀಲಿಸಿ
ಮೂರು ಪರಿಶೀಲನೆಗಳು, ಈ ಕ್ರಮದಲ್ಲಿ: ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಆಯ್ಕೆ ಮಾಡಿದ ಸೇವೆ, VPN ಒಳಗೆ ಉಳಿಯಬೇಕಾದ ಸಾಮಾನ್ಯ ಗಮ್ಯ, ಮತ್ತು ಬಾಧಿತವಾಗದೇ ಇರಬೇಕಾದ ಫೋನ್ ಅಪ್ಲಿಕೇಶನ್. ನಂತರ ಮರುಸಂಪರ್ಕದ ನಂತರ ಮತ್ತು ಮೇಲ್ಮುಖ ಕೊಂಡಿ ಬದಲಾದ ನಂತರ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಆಗಲೇ ನೀತಿ ಕೋಷ್ಟಕಗಳು ಮರುನಿರ್ಮಾಣವಾಗುವುದು.
ಫೋನ್‌ನ ಹಂಚಿಕೆ ಅನುಷ್ಠಾನವು ಮರುಸಂಪರ್ಕದ ಉದ್ದಕ್ಕೂ ಆ ಒಪ್ಪಂದವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಹ್ಯಾಂಡ್‌ಸೆಟ್‌ನಲ್ಲಿ root ನಿಯಮಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಬದಲು ಆಯ್ದ ನೀತಿಯನ್ನು ಬೆಂಬಲಿತ ಕೆಳಮುಖ ರೂಟರ್‌ಗೆ ಸರಿಸಿ. ರೂಟರ್ ಸ್ಥಿರ ಮಾಲೀಕರೊಂದಿಗೆ ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಹೊಂದಾಣಿಕೆಯನ್ನು ವ್ಯಕ್ತಪಡಿಸಬಲ್ಲದು, ಮತ್ತು ಟೆಥರಿಂಗ್ ಮಾಡ್ಯೂಲ್‌ನ ದಾಖಲೆ ಫೋನ್ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸರಿಯಾದ ಉಲ್ಲೇಖ.