ರೋಮಿಂಗ್ VPN ಕ್ಲೈಂಟ್ ಕಚೇರಿಗೆ ಸೇವೆಯನ್ನು ಹೋಸ್ಟ್ ಮಾಡಬಹುದೇ?

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

ಡಯಲ್-ಇನ್ ದಿಕ್ಕು ಸೇವೆಯ ದಿಕ್ಕಿನ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ

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

ರೋಮಿಂಗ್ ಲ್ಯಾಪ್ಟಾಪ್‌ಗಳಲ್ಲಿನ ಏಜೆಂಟ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುವ ದಾಸ್ತಾನು ವ್ಯವಸ್ಥೆಯನ್ನು ಅಥವಾ ಮನೆಯಲ್ಲಿನ ಕಾರ್ಯಸ್ಥಳದಿಂದ ಪರೀಕ್ಷಾ API ಬೇಕಾದ ಡೆವಲಪರ್ ಅನ್ನು ಊಹಿಸಿ. ಇಬ್ಬರೂ ಕಚೇರಿಯ ಬದಿಯು ಸಂಭಾಷಣೆ ಪ್ರಾರಂಭಿಸಬೇಕೆಂದು ಬಯಸುತ್ತಾರೆ, ಇದು ಸಾಮಾನ್ಯ ಕ್ಲೈಂಟ್-ಮತ್ತು-ಸರ್ವರ್ ಮಾದರಿಯ ವಿರುದ್ಧವಾಗಿದೆ.

ಹೋಸ್ಟ್ ಮಾಡಿದ ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ಉತ್ಪನ್ನಗಳು ಇಲ್ಲಿ ಭಿನ್ನವಾಗುತ್ತವೆ, ಮತ್ತು ಈ ಭಿನ್ನತೆ ದೋಷವಲ್ಲ. ಕೆಲವು ನಿರ್ವಹಿತ ಸೇವಾ VPNಗಳು ಸಂಪರ್ಕಗೊಂಡ ಕ್ಲೈಂಟ್‌ಗಳ ಕಡೆಗೆ ಕೇಳದ ಸಂಪರ್ಕಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಬಂಧಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಅವುಗಳ ಮಾದರಿ ಕ್ಲೈಂಟ್‌ನಿಂದ-ಸಂಪನ್ಮೂಲಕ್ಕೆ, ಸಂಪನ್ಮೂಲದಿಂದ-ಕ್ಲೈಂಟ್‌ಗೆ ಅಲ್ಲ. ಸಹೋದ್ಯೋಗಿಗೆ ಅವರ ಲ್ಯಾಪ್ಟಾಪ್ ಸರ್ವರ್ ಆಗಿ ಕೆಲಸ ಮಾಡಬಲ್ಲದು ಎಂದು ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಉತ್ಪನ್ನದ ದಾಖಲಿತ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಓದಿ.

ಪೋರ್ಟ್ ತೆರೆಯುವ ಮೊದಲು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿ

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

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

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

ಹೆಸರು ಮತ್ತು ವಿಳಾಸಗಳು ವಿನ್ಯಾಸದ ನಿರ್ಧಾರಗಳು

ಟನಲ್‌ನೊಳಗಿನ ವಿಳಾಸ ತಾನಾಗಿಯೇ ಹೆಸರಾಗುವುದಿಲ್ಲ. ನೀವು ನಿಯಂತ್ರಿಸುವ ಖಾಸಗಿ DNS ದಾಖಲೆ, ಶೋಧನಾ ಪ್ರೋಟೋಕಾಲ್ ಟನಲ್ ದಾಟುತ್ತದೆ ಎಂಬ ನಿರೀಕ್ಷೆಗಿಂತ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಏಕೆಂದರೆ ಲಿಂಕ್-ಲೋಕಲ್ ಮಲ್ಟಿಕಾಸ್ಟ್ ಹೆಸರು ಪರಿಹಾರವು ಸ್ಥಳೀಯ ವಿಭಾಗದಲ್ಲಿಯೇ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಉಪಜಾಲಗಳ ನಡುವಿನ DNS ಆಗುವುದಿಲ್ಲ.

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

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

ಸದಸ್ಯತ್ವವಲ್ಲ, ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ

ಗುರಿಯಿಂದ ಯಾವುದು ಮತ್ತು ಯಾವ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಬಗ್ಗೆ ಗೇಟ್‌ವೇಯ ದೃಷ್ಟಿಯನ್ನು ಖಚಿತಪಡಿಸಿ:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

ಲಭ್ಯತೆ ಅದೇ ಸಂಭಾಷಣೆಗೆ ಸೇರಿದೆ. ಲ್ಯಾಪ್ಟಾಪ್ ನಿದ್ರಿಸುತ್ತದೆ, ಜಾಲಗಳ ನಡುವೆ ಸಂಚರಿಸುತ್ತದೆ ಮತ್ತು ದಿನದ ಕೊನೆಯಲ್ಲಿ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುತ್ತದೆ. ಯಾವುದೇ ಗಂಟೆಗೆ ಉತ್ತರಿಸಬೇಕಾದ ಸೇವೆ ಯಾವಾಗಲೂ ಆನ್ ಆಗಿರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿರಬೇಕು, ಆದರೆ ಉತ್ತಮ-ಪ್ರಯತ್ನದ ಸೇವೆ ಈ ಮಿತಿಯನ್ನು ಬರೆದಿಟ್ಟು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿಯೇ ಉಳಿಯಬಹುದು.

ಸಂಪನ್ಮೂಲವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರಕಟಿಸಿ, ಹೆಸರು, ಅನುಮತಿಸಲಾದ ಕರೆದಾರರ ಪಟ್ಟಿ ಮತ್ತು ಮಾಲೀಕರೊಂದಿಗೆ, ಮತ್ತು ದೂರದ ಸಾಧನವು ಆಕಸ್ಮಿಕ ಸರ್ವರ್ ಬದಲು ಬೆಂಬಲಿತ ಸೇವೆಯಾಗುತ್ತದೆ.