Android ನ ಏಕ-VPN ನಿಯಮವು ಹೋಸ್ಟ್ ಮಾಡಿದ SSH ಸರ್ವರ್ ಅನ್ನು ತಡೆಯುವುದಿಲ್ಲ

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

ಏಕ-VPN ನಿಯಮ ನಿಜವಾಗಿ ಏನನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ

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

ಇದು ಕೇಳುವ ಸಾಕೆಟ್‌ಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. SSH ಸರ್ವರ್ VpnService ಅನ್ನು ಕರೆಯುವುದಿಲ್ಲ, ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತಡೆಯುವುದಿಲ್ಲ ಮತ್ತು ಆ ಸ್ಲಾಟ್‌ಗಾಗಿ ಸ್ಪರ್ಧಿಸುವುದಿಲ್ಲ. ಅದು ಪೋರ್ಟ್ ಬಂಧಿಸಿ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, VPN ಸ್ಥಾಪಿಸದಿದ್ದರೂ ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು. ಆದ್ದರಿಂದ ಈ ಪುರಾಣವು ಸುರಂಗ ಪೂರೈಕೆದಾರರ ಮಿತಿಯನ್ನು ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಗಳ ಮಿತಿಯೊಂದಿಗೆ ಗೊಂದಲ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡಕ್ಕೂ ಸಂಬಂಧವಿಲ್ಲ.

ಲಿಸನರ್ ಒಂದು ಗಮ್ಯಸ್ಥಾನ, ಸುರಂಗದ ಭಾಗವಲ್ಲ

ಸುರಂಗ ಇದ್ದಾಗ, ಫೋನ್‌ಗೆ ಅದರ ಮೇಲೆ ವಿಳಾಸವಿರುತ್ತದೆ ಮತ್ತು ಪೀರ್ ಸಾಧನಕ್ಕೆ ಆ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವಿರುತ್ತದೆ. ಏನಾದರೂ ಉತ್ತರಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಲಿಸನರ್ ನಿರ್ಧರಿಸುತ್ತದೆ. loopback ಗೆ ಬದ್ಧವಾದ ಡೀಮನ್ ಫೋನ್‌ನಿಂದ ಮಾತ್ರ ತಲುಪಬಹುದು; ಹಳೆಯ ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಡೀಮನ್ ಮರುಸಂಪರ್ಕದ ನಂತರ ತನ್ನ ಬಂಧನವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ಅದು ಬದ್ಧವಾದ ವಿಳಾಸ ಬದಲಾಗಿರುತ್ತದೆ.

ಬಂಧನ ನಿಯಮಗಳು ಸಾಮಾನ್ಯ SSH ಸಂರಚನೆ: ಕೇಳುವ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್, ಮತ್ತು ಯಾರು ದೃಢೀಕರಿಸಬಹುದು. Android ನಲ್ಲಿ ಆ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಸಂರಚನೆಯಲ್ಲಿವೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆಯ ಮಾಲೀಕರಿಗೆ ವಿಶೇಷ ಪೋರ್ಟ್‌ಗಳನ್ನು ಬಳಸಲು ಅನುಮತಿ ಇಲ್ಲದಿರಬಹುದು, ಆದ್ದರಿಂದ root ಆಗಿ ಪೋರ್ಟ್ 22 ಬಂಧಿಸುವ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಭ್ಯಾಸ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ವರ್ಗಾವಣೆಯಾಗುವುದಿಲ್ಲ.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

ನಂತರ ಮಾರ್ಗದ ಮೇಲೆಯೇ ಅನುಮತಿ ಇದೆ. ಹೊರಹೋಗುವ ವೆಬ್ ಸಂಚಾರವನ್ನು ಸಂತೋಷದಿಂದ ಸಾಗಿಸುವ ಗ್ರಾಹಕ VPN ತನ್ನ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಒಳಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ಅನುಮತಿಸಬೇಕಿಲ್ಲ; ಹಲವು ಅನುಮತಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಒಬ್ಬ ಗ್ರಾಹಕನನ್ನು ಇನ್ನೊಬ್ಬರ ಎದುರು ಬಯಲಿಗೆಳೆಯುತ್ತದೆ. ಪೀರ್ ಎಲ್ಲಿಂದಲೂ ಫೋನ್‌ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ತಲುಪದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಸೇವೆಯ ನೀತಿಯಲ್ಲಿದೆ, ಫೋನ್‌ನಲ್ಲಿಲ್ಲ.

ಪ್ರತ್ಯುತ್ತರ ಮಾರ್ಗವೇ ಸಾಮಾನ್ಯವಾಗಿ ಮುರಿಯುವ ಸ್ಥಳ

ಪೀರ್ ಫೋನ್‌ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ತಲುಪಿ SYN ಬರುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ. ಈಗ ಪ್ರತ್ಯುತ್ತರ ಅದೇ ಮಾರ್ಗದಿಂದ ಹೊರಹೋಗಬೇಕು, ಮತ್ತು ಅದು ಫೋನ್ ಒಳಗಿನ ಮಾರ್ಗನಿರ್ಣಯ. ಪ್ರತ್ಯುತ್ತರ ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ಆದ್ದರಿಂದ Wi-Fi ಮೂಲಕ ಹೊರಹೋದರೆ, ಪೀರ್ ಎಂದೂ ಪೂರ್ಣಗೊಳ್ಳದ ಸಂಪರ್ಕವನ್ನು ನೋಡುತ್ತದೆ, ಅದು ಫೈರ್‌ವಾಲ್‌ನಂತೆಯೇ ಕಾಣುತ್ತದೆ.

Android ಇದನ್ನು ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಿಂತ ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ನೆಟ್‌ವರ್ಕ್ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಆಯ್ಕೆಯಾಗುತ್ತದೆ ಮತ್ತು VPN ಅಪ್ಲಿಕೇಶನ್‌ನ ನೀತಿಯಿಂದ ಬದಲಾಗಬಹುದು. VPN ಕ್ಲೈಂಟ್ ಅನುಮತಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಮಾತ್ರ ಮಾರ್ಗನಿರ್ದೇಶಿಸಬಹುದು, ಆದ್ದರಿಂದ ಆ ಪಟ್ಟಿಯ ಹೊರಗಿನ ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಪ್ರತ್ಯುತ್ತರಗಳಿಗೆ ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್ ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದರೆ ಪೀರ್ ಅವುಗಳನ್ನು ಸುರಂಗದ ಮೂಲಕ ನಿರೀಕ್ಷಿಸುತ್ತದೆ.

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

VPN ಬೈಪಾಸ್ ಮಾಡುವುದು ಒಳಬರುವ ಸೇವೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ

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

ರೌಟರ್‌ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ತೆರೆಯುವುದಕ್ಕೂ ಇದು ಅನ್ವಯಿಸುತ್ತದೆ. ಅಗತ್ಯವು ಒಂದು ಅಧಿಕೃತ ಸಾಧನವು VPN ಮೂಲಕ ಫೋನ್ ತಲುಪುವುದಾದರೆ, SSH ಅನ್ನು ಇಂಟರ್ನೆಟ್‌ಗೆ ಒಡ್ಡುವುದು ಬೇರೆ ಬೆದರಿಕೆ ಮಾದರಿ, ದುರಸ್ತಿಯಲ್ಲ.

ಮೊದಲು ಸೇವೆಯ ವಿಳಾಸವನ್ನು ನಿರ್ಧರಿಸಿ: ಫೋನ್‌ನ LAN ವಿಳಾಸ, ಅದರ ಸುರಂಗ ವಿಳಾಸ, ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮುಂದುವರಿಸಿದ ಎಂಡ್‌ಪಾಯಿಂಟ್. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ತಲುಪುವಿಕೆ ಮತ್ತು ಒಡ್ಡುವಿಕೆಯ ಒಪ್ಪಂದವಿದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಬೆರೆಸುವುದೇ ಸಣ್ಣ ಪ್ರವೇಶ ಸಮಸ್ಯೆಯನ್ನು ಶಾಶ್ವತ ರಂಧ್ರವಾಗಿಸುವ ದಾರಿ.

ಒಮ್ಮೆಗೆ ಒಂದು ದಿಕ್ಕನ್ನು ನಿರ್ಣಯಿಸಿ

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

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

ದೋಷನಿವಾರಣೆ ಮಾಡುವಾಗ ಹೋಸ್ಟ್-ಕೀ ಪರಿಶೀಲನೆ ಮತ್ತು ಖಾತೆ ನಿರ್ಬಂಧಗಳನ್ನು ಅಸ್ಪೃಶ್ಯವಾಗಿರಿಸಿ. ಲಿಸನರ್ ಮತ್ತು ಅನುಮತಿಸಿದ ಬಳಕೆದಾರರನ್ನು ಮಿತಿಗೊಳಿಸುವುದೇ ತಲುಪಬಹುದಾದ ಸರ್ವರ್ ಅನ್ನು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿಸುತ್ತದೆ; ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡಲಿ ಎಂದು ಅವುಗಳನ್ನು ಸಡಿಲಗೊಳಿಸುವುದು ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಕೆಟ್ಟದರೊಂದಿಗೆ ಬದಲಿಸುತ್ತದೆ. OpenSSH ಸರ್ವರ್ ಉಲ್ಲೇಖ ಕೇಳುವ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಂತ್ರಣಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ನಿಮ್ಮ Android ಅನುಷ್ಠಾನ ಅದೇ ಸಂರಚನಾ ಹೆಸರುಗಳನ್ನು ಅನುಸರಿಸಿದರೆ.