VPN ಆನ್ ಆಗಿರುವಾಗ Android ಫೈರ್ವಾಲ್ ನಿಯಮ ಎಲ್ಲಿ ಇರಬೇಕು
ಒಂದೇ VpnService ಸಕ್ರಿಯವಾಗಿರಬಹುದು, ಆದ್ದರಿಂದ ಫೈರ್ವಾಲ್ ಆ್ಯಪ್ ಮತ್ತು VPN ಆ್ಯಪ್ ಒಂದರ ಮೇಲೊಂದು ಜೋಡಣೆಯಾಗುವುದಿಲ್ಲ. ಒಂದು ಕೆಲಸದ ವಿನಂತಿಯನ್ನು ಅನುಸರಿಸಿ ಪ್ರತಿ ನಿಯಮವನ್ನು ಅದರ ಸಂಚಾರ ನಿಜವಾಗಿ ಹಾದುಹೋಗುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ.
ನಿಮ್ಮ ಬಳಿ ಒಂದು ವಾಕ್ಯದ ನೀತಿ ಇದೆ: ಈ ಆ್ಯಪ್ ಕೆಲಸದ ಸೇವೆಯನ್ನು ತಲುಪಬಹುದು, ಬೇರೆ ಯಾವುದನ್ನೂ ಅಲ್ಲ. ಮುಂದಿನ ಪ್ರಶ್ನೆ ಉತ್ಪನ್ನದ ಆಯ್ಕೆಯಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ಸ್ಥಳದ ಪ್ರಶ್ನೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಸಂಭಾವ್ಯ ಜಾರಿ ಬಿಂದುವು ಫೋನ್ನ ಸಂಚಾರದ ಬೇರೆ ಭಾಗವನ್ನು ನೋಡುತ್ತದೆ. ಗೇಟ್ವೇ ಸುರಂಗಕ್ಕೆ ಪ್ರವೇಶಿಸುವುದನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಫೋನ್ ಬದಿಯ ಫಿಲ್ಟರ್ ತನಗೆ ನೋಡಲು ಅನುಮತಿ ಇರುವುದನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಒಂದು ವಿನಂತಿಯನ್ನು ಎರಡರ ಮೂಲಕ ಹಾಯಿಸಿದರೆ ಉತ್ತರ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
ಉತ್ಪನ್ನದಿಂದ ಅಲ್ಲ, ವಾಕ್ಯದಿಂದ ಆರಂಭಿಸಿ
ಏನನ್ನೂ ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಅಗತ್ಯವನ್ನು ವಿಸ್ತರಿಸಿ. ಅಂದರೆ ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಅದು ಚಲಿಸುವ ಪ್ರೊಫೈಲ್, ಏಕೆಂದರೆ ಕೆಲಸದ ಪ್ರೊಫೈಲ್ನ ಆ್ಯಪ್ ವೈಯಕ್ತಿಕ ಪ್ರೊಫೈಲ್ನ ಅದೇ ಆ್ಯಪ್ಗಿಂತ ಬೇರೆ ಬಳಕೆದಾರ. ಅಂದರೆ ಗಮ್ಯಸ್ಥಾನ: ಹೋಸ್ಟ್, ಪೋರ್ಟ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್, ಸೇವೆಯ ಹೆಸರಲ್ಲ. ಅಂದರೆ ಆ ಹೆಸರನ್ನು ಪರಿಹರಿಸುವ DNS ಮಾರ್ಗ, ಮತ್ತು ಸುರಂಗ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಏನಾಗಬೇಕು ಎಂಬುದೂ ಸೇರಿದೆ.
ಬರೆದರೆ, ಉದಾಹರಣೆಯ ನೀತಿ ನಾಲ್ಕು ಸಾಲುಗಳು: ಕೆಲಸದ ಆ್ಯಪ್ ಕೆಲಸದ ಸೇವೆಯನ್ನು ತಲುಪಬಹುದು; ಅದು ಬೇರೆ ಎಲ್ಲಿಗೂ ತಲುಪುವಂತಿಲ್ಲ; ಇತರ ಆ್ಯಪ್ಗಳು ಬದಲಾಗದೆ ಇರುತ್ತವೆ; ಸುರಂಗ ಇಲ್ಲದಿದ್ದರೆ ಕೆಲಸದ ಆ್ಯಪ್ ನೇರ ಮಾರ್ಗಕ್ಕೆ ಬೀಳುವ ಬದಲು ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿ ಸಾಲಿಗೂ ಮಾಲೀಕರಿದ್ದಾರೆ, ಮತ್ತು ಎಲ್ಲರೂ ಒಬ್ಬರೇ ಅಲ್ಲ.
ಹಂತ 1: ಫೋನ್ ಸ್ವತಃ ಏನನ್ನು ಜಾರಿಗೊಳಿಸಬಲ್ಲದು
ರೂಟ್ ಇಲ್ಲದ Android ಫೈರ್ವಾಲ್ ಒಂದು VpnService, ಅದು ಸಂಚಾರವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಹಿಡಿಯುತ್ತದೆ, ಹಿಂದೆ ದೂರದ ಸುರಂಗ ಇಲ್ಲದಿದ್ದರೂ. Android ಪ್ರತಿ ಬಳಕೆದಾರ ಪ್ರೊಫೈಲ್ಗೆ ಒಂದೇ ಸಕ್ರಿಯ VPN ಸೇವೆಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡನೇ ಫೈರ್ವಾಲ್ ಆ್ಯಪ್ ಮೊದಲನೆಯ ಹಿಂದೆ ಸರಪಣಿಯಾಗುವುದಿಲ್ಲ. ಅದು ಅದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಆ್ಯಪ್ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತಿದ್ದ ಇಂಟರ್ಫೇಸ್ ಮಾಯವಾಗುತ್ತದೆ.
ಅದಕ್ಕಾಗಿಯೇ VPN ಕ್ಲೈಂಟ್ ಪಕ್ಕದಲ್ಲಿ ಫೈರ್ವಾಲ್ ಸ್ಥಾಪಿಸಿದರೆ ಜನರು ನಿರೀಕ್ಷಿಸುವ ಸಂಯೋಜನೆ ಅಪರೂಪಕ್ಕೆ ಸಿಗುತ್ತದೆ. ಫೈರ್ವಾಲ್ ಪ್ರಾರಂಭವಾಗಿ VPN ಕಡಿತಗೊಂಡರೆ ಏನೂ ಸಂಯೋಜನೆಯಾಗಿಲ್ಲ; ಎರಡೂ ಸ್ಥಳ ಬದಲಿಸಿಕೊಂಡಿವೆ. ಇಂಟರ್ಫೇಸ್ ಬದಲಾವಣೆ ಸಹಕಾರವಲ್ಲ, ಮತ್ತು ಲಕ್ಷಣ ಎಂದರೆ ಇನ್ನೊಂದು ಆ್ಯಪ್ ತೆರೆದಾಗಲೆಲ್ಲ ಸುರಂಗ ಪದೇ ಪದೇ ಬೀಳುವುದು.
ಬೆಂಬಲಿತ ವ್ಯವಸ್ಥೆಗಳಿವೆ: ನೀವು ಈಗಾಗಲೇ ಚಲಾಯಿಸುವ VPN ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅಂತರ್ಗತ ಫಿಲ್ಟರಿಂಗ್, ಸಾಧನ ನೀತಿ ನಿಯಂತ್ರಕ ಅಥವಾ ಕೆಲಸದ ಪ್ರೊಫೈಲ್ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ನಿಯಂತ್ರಣಗಳು, ಅಥವಾ ತಯಾರಕರು ದಾಖಲಿಸುವ ಆರ್ಕಿಟೆಕ್ಚರ್. ಉಳಿದದ್ದೆಲ್ಲ ಪ್ರತಿ ಆ್ಯಪ್ ನವೀಕರಣದ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಬೇಕಾದ ಪ್ರಯೋಗ.
ಹಂತ 2: ಗೇಟ್ವೇ ಏನನ್ನು ಜಾರಿಗೊಳಿಸಬಲ್ಲದು
ದೂರದ ತುದಿಯಲ್ಲಿ ಸಂಚಾರ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ನಂತರ, ಗೇಟ್ವೇ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುವ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಅನುಮೋದಿತ ವಿಳಾಸಗಳು, ಸೇವೆಗಳು ಅಥವಾ ದೃಢೀಕೃತ VPN ಗುರುತುಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಬಹುದು. ಅಲ್ಲಿಂದ ಹೊರಹೋಗುವ ಎಲ್ಲದಕ್ಕೂ ಅದು ನಿಜವಾದ ಜಾರಿ, ಮತ್ತು ಖಾಸಗಿ ಉಪಜಾಲಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಮಿತಿಗೊಳಿಸಲು ಸರಿಯಾದ ಸ್ಥಳ ಅದು.
ಅದು ಪಡೆಯದಿರುವುದು ಪ್ರತಿ ಸಾಮಾನ್ಯ IP ಪ್ಯಾಕೆಟ್ಗೆ ಜೋಡಿಸಲಾದ ಫೋನ್ನ ಆ್ಯಪ್ ಗುರುತು. ಒಂದೇ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಹಲವು ಆ್ಯಪ್ಗಳು ಗೇಟ್ವೇಗೆ ಒಂದೇ ವಿಷಯ, ವಿನ್ಯಾಸ ಅವುಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ವಿಳಾಸಗಳು ಅಥವಾ ಪ್ರತ್ಯೇಕ ದೃಢೀಕೃತ ಗುರುತುಗಳನ್ನು ನೀಡದಿದ್ದರೆ. ಆದ್ದರಿಂದ ಗೇಟ್ವೇಯಲ್ಲಿ ಬಳಕೆದಾರ ಮಟ್ಟದ ನಿಯಮ ಫೋನ್ನಲ್ಲಿ ಆ್ಯಪ್ ಮಟ್ಟದ ನಿಯಮವಲ್ಲ, ನಿರ್ವಹಣಾ ಕನ್ಸೋಲ್ ಅದನ್ನು ಏನೇ ಕರೆದರೂ.
ಹಂತ 3: ಎಂದೂ ತಲುಪದ್ದನ್ನು ಪಟ್ಟಿ ಮಾಡಿ
VPN ನಿಂದ ಹೊರಗಿಡಲಾದ ಆ್ಯಪ್ ಹತ್ತಿರದ ಸಾಧನವನ್ನು ಸಂಪರ್ಕಿಸಿದರೆ ಗೇಟ್ವೇಗೆ ಎಂದೂ ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೊರಹೋಗುವ ಫೈರ್ವಾಲ್ ತನಗೆ ಎಂದೂ ಸಿಗದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿರಾಕರಿಸಲಾರದು. ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಉದ್ದೇಶವಿಲ್ಲದ ನೇರ ಮಾರ್ಗ ಮತ್ತು ಸ್ಥಳೀಯ ಪ್ರವೇಶ ಜಾಲದಲ್ಲಿ ಒಳಬರುವ ಒಡ್ಡುವಿಕೆಗೂ ಇದೇ ಅನ್ವಯ.
ವಿರುದ್ಧವೂ ನಿಜ: ಸಂಪರ್ಕಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಸ್ಥಳೀಯ ನಿಯಮ ಗೇಟ್ವೇಯ ಖಾಸಗಿ ಜಾಲದ ACL ಮೂಲಕ ಪ್ರವೇಶ ನೀಡುವುದಿಲ್ಲ. ಒಂದು ವಿನಂತಿ ಎರಡೂ ಗಡಿಗಳಿಗೆ ಒಳಪಟ್ಟಿರಬಹುದು, ಮತ್ತು ಒಂದನ್ನು ಪೂರೈಸಿದರೆ ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.
ಹಂತ 4: ಪ್ರತಿ ನಿಯಮವನ್ನು ಒಂದು ಮಾರ್ಗಕ್ಕೆ ನಿಗದಿಪಡಿಸಿ
ಏನನ್ನಾದರೂ ಸಂರಚಿಸುವ ಮೊದಲು ನಿರ್ಧಾರವನ್ನು ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಖಾಲಿ ಕೋಶಗಳೇ ವಿನ್ಯಾಸ ವಿಫಲವಾಗುವ ಸ್ಥಳ.
| ಮಾರ್ಗ | ಯಾರು ಜಾರಿಗೊಳಿಸಬಹುದು | ಕುರುಡು ಬಿಂದು |
|---|---|---|
| ಕೆಲಸದ ಆ್ಯಪ್ನಿಂದ ಕೆಲಸದ ಸೇವೆಗೆ, ಸುರಂಗ ತೆರೆದಿದೆ | ವಿಳಾಸ ಮತ್ತು ಸೇವೆಯ ಮೇಲೆ ಗೇಟ್ವೇ ACL, ಜೊತೆಗೆ ಇತರ ಮಾರ್ಗಗಳಲ್ಲಿ ಸ್ಥಳೀಯ ತಡೆ | ಗೇಟ್ವೇ ಯಾವ ಆ್ಯಪ್ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿತು ಎಂದು ನೋಡಲಾರದು |
| ಕೆಲಸದ ಆ್ಯಪ್ನಿಂದ ಇತರ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ, ಸುರಂಗ ತೆರೆದಿದೆ | ಆ್ಯಪ್ ಅರಿವಿರುವ ಸ್ಥಳೀಯ ಫಿಲ್ಟರ್, ಅಥವಾ ಆ ಗಮ್ಯಸ್ಥಾನಗಳು ಅಲ್ಲಿ ವಿಳಾಸಗೊಂಡಿದ್ದರೆ ಗೇಟ್ವೇ | ಸ್ಥಳೀಯ ಫಿಲ್ಟರ್ ಸಕ್ರಿಯ VpnService ಆಗಿರಬೇಕು |
| ಸುರಂಗ ಇಲ್ಲದ ಕೆಲಸದ ಆ್ಯಪ್ | ಸ್ಥಳೀಯ ನಿರಾಕರಣೆ, ಆ್ಯಪ್ ನೇರ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳದಂತೆ | ಸುರಂಗ ಹೋದ ಮೇಲೂ ಫಿಲ್ಟರ್ ಉಳಿಯಬೇಕು |
| ಹತ್ತಿರದ LAN ಸಾಧನ | ಸ್ಥಳೀಯ ನೀತಿ ಮಾತ್ರ | ಗೇಟ್ವೇ ಅದನ್ನು ಎಂದೂ ನೋಡುವುದಿಲ್ಲ |
ಕೆಲಸ ಮಾಡುವ ಆಕಾರ ಎರಡು ಕೆಲಸಗಳಿರುವ ಎರಡು ಗಡಿಗಳು. ಆ್ಯಪ್ ಅರಿವಿರುವ ಸ್ಥಳೀಯ ಗಡಿ ಫೋನ್ನ ವರ್ತನೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ನೇರ ಬೀಳುವಿಕೆ ಸೇರಿದಂತೆ, ಮತ್ತು ಗೇಟ್ವೇ ಗಡಿ ದೂರದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಗೇಟ್ವೇ ಬದಿ ಕೆಲಸದ ಸೇವೆಗೆ ಅನುಮತಿ ನೀಡಿ ಉಳಿದ ಪ್ರತಿ ಖಾಸಗಿ ಉಪಜಾಲವನ್ನು ನಿರಾಕರಿಸಬಹುದು, ಫೋನ್ ಬದಿಯ ನೀತಿ ಆ್ಯಪ್ ಇಲ್ಲದಿದ್ದರೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ನೇರ ಮಾರ್ಗದ ಬಗ್ಗೆ ತಾನೇ ನಿರ್ಧರಿಸುತ್ತದೆ.
ಹಂತ 5: ಸಾರಿಗೆಯನ್ನು ಜೀವಂತವಾಗಿಡಿ, ನಂತರ ಪರಿಶೀಲಿಸಿ
ನೀವು ಯಾವ ಸ್ಥಳೀಯ ನೀತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೂ, ಅದು VPN ಅನ್ನು ಸ್ಥಾಪಿಸುವ ಮತ್ತು ಉಳಿಸಿಕೊಳ್ಳುವ ಸಾರಿಗೆಗೆ ಅನುಮತಿ ನೀಡಬೇಕು. ಆ ಸಾರಿಗೆಯನ್ನು ತಡೆದರೆ ಫೋನ್ ಸುರಂಗವಿಲ್ಲದೆ ಮತ್ತು ನೀತಿಯಿಲ್ಲದೆ ಉಳಿಯುತ್ತದೆ, ಅದು ಏನನ್ನೂ ಸುಸಂಗತವಾಗಿ ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ನಿರ್ಣಯಿಸಲು ಕಷ್ಟ, ಏಕೆಂದರೆ ಆ್ಯಪ್ಗೆ ಜಾಲವೇ ಇಲ್ಲ.
ನಂತರ ಒಟ್ಟಾರೆ ಅನಿಸಿಕೆ ಬದಲು ಮೂಲ ವಾಕ್ಯದ ಪ್ರತಿ ಸಾಲನ್ನು ಪರಿಶೀಲಿಸಿ: ಕೆಲಸದ ಆ್ಯಪ್ ಕೆಲಸದ ಸೇವೆಯನ್ನು ತಲುಪುತ್ತದೆ, ಅದೇ ಆ್ಯಪ್ ಇನ್ನೊಂದು ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ, ಕೆಲಸವಲ್ಲದ ಆ್ಯಪ್ ಮೊದಲಿನಂತೆ ವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ನಿಲ್ಲಿಸಿದಾಗ ಕೆಲಸದ ಆ್ಯಪ್ ನೇರ ಸಂಪರ್ಕಕ್ಕೆ ಬೀಳುವುದಿಲ್ಲ. DNS ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಖಾಸಗಿ DNS ಅಥವಾ ಎನ್ಕ್ರಿಪ್ಟ್ ಆದ ಪರಿಹಾರಕವು ಕೇವಲ ವಿಳಾಸಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಫಿಲ್ಟರ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು.
ಈ ಹಂತಗಳಲ್ಲಿ ಒಂದನ್ನು ಫೋನ್ನಲ್ಲಿ ಪೂರೈಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಅಗತ್ಯವು ಆರ್ಕಿಟೆಕ್ಚರ್ ಪ್ರಶ್ನೆ, ಫೈರ್ವಾಲ್ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. ನೀತಿಯನ್ನು ನೀವು ನಿಯಂತ್ರಿಸುವ ಸಾಧನ ಮತ್ತು ನೀವು ನಿಯಂತ್ರಿಸುವ ಗೇಟ್ವೇ ನಡುವೆ ಹಂಚುವುದೇ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಾಮಾಣಿಕ ಉತ್ತರ, ಮತ್ತು Android VPN ಸಂಪರ್ಕ ದಾಖಲೆಗಳು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಒಂದು ಸೇವೆಗೆ ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುವ ಸ್ಥಳ.