Android VPN ಸರ್ವರ್: root ಫೋನ್ ಅನ್ನು ತಲುಪಲಾಗುವಂತೆ ಮಾಡುವುದಿಲ್ಲ
ಫೋನ್ VPN ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಸೇವೆ ನೀಡಬಹುದೇ ಎಂಬುದನ್ನು ಮೂರು ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ: ಒಳಬರುವ ಮಾರ್ಗ, ಸವಲತ್ತು ಮಾದರಿ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್. root ಮಧ್ಯದ ಒಂದನ್ನು ಮಾತ್ರ ಮುಟ್ಟುತ್ತದೆ.
root ಪ್ರಕ್ರಿಯೆಯು ಯಾವ ನೆಟ್ವರ್ಕಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಅದು ಫೋನ್ಗೆ ಸಾರ್ವಜನಿಕವಾಗಿ ತಲುಪಬಹುದಾದ ವಿಳಾಸವನ್ನು ನೀಡುವುದಿಲ್ಲ, ಆಪರೇಟರ್ ಬಳಿ ಒಳಬರುವ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಕಾಯ್ದಿರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ರೀಬೂಟ್ ನಂತರ ಡೀಮನ್ ಅನ್ನು ಜೀವಂತವಾಗಿ ಇಡುವುದಿಲ್ಲ. Android ಫೋನ್ VPN ಸರ್ವರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಿದ್ದರೆ, ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ: ಉದ್ದೇಶಿತ ಕ್ಲೈಂಟ್ ಲಿಸನರ್ಗೆ ತಲುಪಲು ಸಾಧ್ಯವೇ, ಸರ್ವರ್ ಅನುಷ್ಠಾನಕ್ಕೆ ಯಾವ ಸವಲತ್ತು ಮಾದರಿ ಬೇಕು, ಮತ್ತು ಸುರಂಗ ಏರಿದ ನಂತರ ಏನನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು.
ಯಾರು ಮತ್ತು ಎಲ್ಲಿಂದ ಫೋನ್ ತಲುಪಬೇಕು
ಅದೇ ಅನುಮತಿಸಲಾದ LAN ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಮತ್ತು ಮೊಬೈಲ್ ಡೇಟಾದಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ಎರಡು ವಿಭಿನ್ನ ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ. ಮೊದಲು ಉದ್ದೇಶಿತವನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಉತ್ತರಗಳು ಒಂದರಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ವರ್ಗಾವಣೆಯಾಗುವುದಿಲ್ಲ. Wi-Fi ನಲ್ಲಿ ಕೇಳದ ಒಳಬರುವ ಸಂಚಾರಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಮೇಲ್ಮಟ್ಟದ ರೌಟರ್ನಲ್ಲಿ ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ಅದರ ಆಚೆ ಬಳಸಬಹುದಾದ ಸಾರ್ವಜನಿಕ ಮಾರ್ಗ ಬೇಕು. ಸೆಲ್ಯುಲಾರ್ನಲ್ಲಿ ಆಪರೇಟರ್ ಮಟ್ಟದ NAT ಎಂದರೆ ಒಳಬರುವ IPv4 ಸಾಮಾನ್ಯವಾಗಿ ಲಭ್ಯವಿಲ್ಲ, ಫೋನ್ ಏನು ಅನುಮತಿಸಿದರೂ.
ಆ ಕೊನೆಯ ಅಂಶವನ್ನೇ root ಮುಟ್ಟಲಾರದು. ಫೋನ್ನ ಸ್ಥಳೀಯ ಫೈರ್ವಾಲ್ ಮತ್ತು ಆಪರೇಟರ್ನ NAT ಬೇರೆ ಬೇರೆ ವ್ಯವಸ್ಥೆಗಳು, ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ಬದಲಿಸುವುದು ಎರಡನೆಯದಕ್ಕೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಖಾಸಗಿ ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸ, ಮೊಬೈಲ್-ಡೇಟಾ ಐಕಾನ್ ಅಥವಾ ಆಲಿಸುತ್ತಿರುವ ಸಾಕೆಟ್ ತಲುಪುವಿಕೆಯ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಆಪರೇಟರ್ ಮಾರ್ಗವು ಜಾಗತಿಕವಾಗಿ ರೌಟ್ ಮಾಡಬಹುದಾದ IPv6 ನೀಡಿದರೂ, ಅದಕ್ಕೆ ಉದ್ದೇಶಪೂರ್ವಕ ಲಿಸನರ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿ ಬೇಕು; ವಿಳಾಸ ಹೊಂದಿರುವುದು ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಕ್ಕೆ ಸಮವಲ್ಲ.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
ಸೇವೆ ನೀಡುವುದು ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದು ಎರಡು ವಿಭಿನ್ನ ಯಶಸ್ಸುಗಳು
ಪೂರ್ಣಗೊಂಡ VPN ಹ್ಯಾಂಡ್ಶೇಕ್ ಸುರಂಗ ಇದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಫೋನ್ನ ಹಿಂದಿನ LAN ತಲುಪಬಹುದು ಎಂದಾಗಲೀ, ಫೋನ್ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು ಎಂದಾಗಲೀ ಅದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅವು ಪ್ರತ್ಯೇಕ ಸಂರಚನೆಗಳು; ಒಳಗಿನ ವಿಳಾಸ ಯೋಜನೆ, ಮಾರ್ಗಗಳು, ಹಿಂತಿರುಗುವ ವರ್ತನೆ ಮತ್ತು ನೀವು ನಿಜವಾಗಿ ಬಯಸುವ ಕಾರ್ಯಕ್ಕಾಗಿ ಸಂಕುಚಿತ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿಯ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗುತ್ತವೆ.
ವೈಫಲ್ಯದ ಮಾದರಿ ಊಹಿಸಬಹುದಾದದ್ದು: ಹ್ಯಾಂಡ್ಶೇಕ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಂತೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಏನೂ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಎರಡು ಪಾತ್ರಗಳಲ್ಲಿ ಯಾವುದನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ. ಫೋನ್ನ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಸಾಧನಕ್ಕೆ ದೂರದ ಪ್ರವೇಶ ಮತ್ತು ಪೂರ್ಣ-ಸುರಂಗ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನಕ್ಕೆ ಬೇರೆ ಬೇರೆ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮಗಳು ಬೇಕು, ಮತ್ತು ಒಂದನ್ನು ಬಯಸಿದಾಗ ಎರಡನ್ನೂ ನೀಡುವುದು ನೀವು ಕೇಳಿದ ಸಾಮರ್ಥ್ಯ ಸೇರಿಸದೆ ಒಡ್ಡುವಿಕೆಯನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ.
ಸವಲತ್ತು ಮಾದರಿ ಒಂದು ಆಯ್ಕೆ, root ಅಥವಾ ಏನೂ ಇಲ್ಲ ಎಂಬುದಲ್ಲ
ಕರ್ನಲ್ TUN ಸಾಧನ ಬಳಸುವ ಸಾಂಪ್ರದಾಯಿಕ OpenVPN ಡೀಮನ್ಗೆ ಸಂಬಂಧಿತ ಸಾಮರ್ಥ್ಯಗಳು, ಸಾಧನ ನೋಡ್ಗೆ ಪ್ರವೇಶ ಮತ್ತು Android ನ ಭದ್ರತಾ ನೀತಿಯ ಸಹಕಾರ ಬೇಕು. root ಎಂಬುದು SELinux ನಿಂದ ಸರ್ವವ್ಯಾಪಿ ವಿನಾಯಿತಿ ಅಲ್ಲ; ಸವಲತ್ತು ಪಡೆದ ಪ್ರಕ್ರಿಯೆಯೂ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ನೀತಿಯಿಂದ ಸೀಮಿತವಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ Linux ಸರ್ವರ್ನಲ್ಲಿ ಸುಲಭವಾಗಿ ಚಲಿಸುವ ಬೈನರಿ ಫೋನ್ನಲ್ಲಿ ಅನುಮತಿಗಳ ಬಗ್ಗೆ ಸ್ಪಷ್ಟ ದೋಷವಿಲ್ಲದೆ ವಿಫಲವಾಗಬಹುದು.
ಬಳಕೆದಾರ ಸ್ಥಳಾವಕಾಶದ ಗೇಟ್ವೇ ಅನುಷ್ಠಾನಕ್ಕೆ ಸಂಪೂರ್ಣ ಬೇರೆ ಸವಲತ್ತು ಮಾದರಿ ಇರಬಹುದು, ಹಾಗಾಗಿ Android ನಲ್ಲಿ ಪ್ರತಿ VPN ಸರ್ವರ್ಗೂ root ಬೇಕು ಎಂಬ ಸಾಮಾನ್ಯ ಹೇಳಿಕೆ ತುಂಬಾ ವಿಶಾಲವಾಗಿದೆ. root ನಿಮಗೆ ಹೆಚ್ಚು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸುವ ಸಾಮರ್ಥ್ಯ ಕೊಡುತ್ತದೆ, ಅವು ಅನುಮತಿಸಲ್ಪಡುತ್ತವೆ ಅಥವಾ ಫಲಿತಾಂಶ ತಲುಪಬಹುದಾದದ್ದು ಎಂಬ ಭರವಸೆ ಅಲ್ಲ.
Android ನ ಸ್ವಂತ VPN ಸೇವಾ ನೋಂದಣಿ ಮತ್ತೊಂದು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಿಧಾನ. ಅದು ಅಪ್ಲಿಕೇಶನ್ಗೆ ನಿರ್ದಿಷ್ಟ ಜೀವನಚಕ್ರವಿರುವ ನಿರ್ವಹಿತ ಕ್ಲೈಂಟ್ ಇಂಟರ್ಫೇಸ್ ನೀಡುತ್ತದೆ; ಅದು ಸಾಮಾನ್ಯ ಸರ್ವರ್ ಇನ್ಸ್ಟಾಲರ್ ಅಲ್ಲ, ಮತ್ತು ಟರ್ಮಿನಲ್ನಿಂದ ಡೀಮನ್ ಪ್ರಾರಂಭಿಸುವುದು ಅದಕ್ಕೆ ನಿರಂತರ ನಿರ್ವಹಣೆ, ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ನೀತಿ ಅಥವಾ ಸ್ವಂತ ಮರುಪ್ರಾಪ್ತಿ ಮಾರ್ಗ ನೀಡುವುದಿಲ್ಲ.
ನಿಮಗೆ ನಿರ್ಗಮನ ಬಿಂದು ಬೇಕಾದರೆ, ವಾಸ್ತುಶಿಲ್ಪ ಬದಲಿಸಿ
ಗುರಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ OpenVPN ಪ್ರೊಫೈಲ್ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆ ಅಲ್ಲ, ಬದಲಿಗೆ ಫೋನ್ ಮೂಲಕ ದೂರದ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾದರೆ, ಒವರ್ಲೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಬೆಂಬಲಿತ ನಿರ್ಗಮನ ನೋಡ್ ಹೆಚ್ಚು ಸೂಕ್ತ ವಿನ್ಯಾಸ. Tailscale ತನ್ನ ನೋಂದಣಿ, ಅಧಿಕಾರ ಮತ್ತು ಕ್ಲೈಂಟ್-ಆಯ್ಕೆ ಹಂತಗಳೊಂದಿಗೆ Android ನಿರ್ಗಮನ-ನೋಡ್ ಪಾತ್ರವನ್ನು ದಾಖಲಿಸುತ್ತದೆ.
ಈ ವಿನಿಮಯ ನಿಜವಾದದ್ದು ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವ ಯೋಗ್ಯ: ನೀವು ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್, ಬೇರೆ ವಿಶ್ವಾಸ ಮಾದರಿ ಮತ್ತು ಆ ಖಾತೆ ಹಾಗೂ ಸಮನ್ವಯ ಸೇವೆಯ ಮೇಲಿನ ಅವಲಂಬನೆಯನ್ನು ಒಪ್ಪುತ್ತೀರಿ. ಅದು ಬದಲಾಗದ OpenVPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಒವರ್ಲೇಗೆ ಸೇರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ವಿಳಾಸದಲ್ಲಿ OpenVPN ಲಿಸನರ್ ನೀಡುವುದಿಲ್ಲ.
ನಿಯೋಜನೆಗೆ ಇನ್ನೂ ಏನು ಬೇಕು
ನೀವು ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಂಡರೂ, ಕಾರ್ಯಾಚರಣೆಯ ಮೂಲಭೂತ ಅಂಶಗಳು ಒಂದು ವಾರ ಉಳಿಯುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಸರ್ವರ್ ರುಜುವಾತುಗಳನ್ನು ಖಾಸಗಿಯಾಗಿ ಇರಿಸಿ, ಪ್ರತ್ಯೇಕ ಕ್ಲೈಂಟ್ ಗುರುತುಗಳನ್ನು ನೀಡಿ, ಮತ್ತು ಅಗತ್ಯವಾಗುವ ಮೊದಲೇ ರದ್ದತಿಯನ್ನು ಯೋಜಿಸಿ. ನವೀಕರಣಗಳು ಹೇಗೆ ಬರುತ್ತವೆ, ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಸೇವೆಯನ್ನು ಯಾವುದು ಚಾಲನೆಯಲ್ಲಿಡುತ್ತದೆ ಮತ್ತು ರೀಬೂಟ್ ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆಯ ನಂತರ ಅದು ಹೇಗೆ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ಅನುಕೂಲಕರವೆಂದು ತೋರುವ ಶಾರ್ಟ್ಕಟ್ಗಳನ್ನು ತಪ್ಪಿಸಿ: ಹಳೆಯ ಸ್ಥಿರ ಬೈನರಿ, ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಿದ ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು, ಮತ್ತು ಇರುವ ಫೈರ್ವಾಲ್ ನೀತಿಯನ್ನು ಅಳಿಸುವ ಆರಂಭ ಸ್ಕ್ರಿಪ್ಟ್. ನಂತರ ಫಲಿತಾಂಶವನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಯ ಮೇಲೆಯೇ ಸ್ವೀಕರಿಸಿ: ಅಧಿಕೃತ ದೂರದ ಕ್ಲೈಂಟ್ ಉದ್ದೇಶಿತ ಸಂಪನ್ಮೂಲವನ್ನು ತಲುಪುತ್ತದೆ, ನಿಷೇಧಿತ ಗಮ್ಯಸ್ಥಾನಗಳು ಲಭ್ಯವಿಲ್ಲದೆ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಬೆಂಬಲಿತ ಜೀವನಚಕ್ರ ಘಟನೆಯ ನಂತರ ಸಾಧನ ತಾನಾಗಿಯೇ ಮರಳುತ್ತದೆ. root ಪ್ರವೇಶವು ಆ ಫಲಿತಾಂಶದ ಒಂದು ಸಂಭಾವ್ಯ ಘಟಕ, ಮತ್ತು ಅಪರೂಪಕ್ಕೆ ನಿರ್ಣಾಯಕ.