VPN ಕ್ಲೈಂಟ್‌ಗಳು ಸರ್ವರ್ ತಲುಪುತ್ತವೆ, LAN ಅಲ್ಲ: ಯಾವ ಪರಿಹಾರ?

ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಗೇಟ್‌ವೇ ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ಅದರ ಹಿಂದಿನ ಹೋಸ್ಟ್‌ಗಳು ಸದ್ದಿಲ್ಲದೆ ಇವೆ. ದೂರದ LAN ನಲ್ಲಿ ಸ್ಥಿರ ಮಾರ್ಗ, ಸರ್ವರ್‌ನಲ್ಲಿ NAT ಅಥವಾ ಎರಡನೇ ಸುರಂಗ ಆಯ್ಕೆಮಾಡಿ.

ಕ್ಲೈಂಟ್ OpenVPN ಸರ್ವರ್‌ನ ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ping ಮಾಡಿ ಉತ್ತರ ಪಡೆಯುತ್ತದೆ, ನಂತರ ಸರ್ವರ್‌ನ LAN ನಲ್ಲಿ ಹೋಸ್ಟ್ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಏನೂ ಸಿಗುವುದಿಲ್ಲ. ಈ ವಿಭಜನೆ ದೋಷವನ್ನು ಬಹಳ ಮಿತಿಗೊಳಿಸುತ್ತದೆ: ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಫಾರ್ವರ್ಡಿಂಗ್ ಬಹುಶಃ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ, ಉತ್ತರವಾದರೂ ಹಿಂತಿರುಗಿಸದ ಬಾಗಿಲಿನಿಂದ ಹೊರಗೆ ಹೋಗುತ್ತದೆ. ಮೂರು ಪರಿಹಾರಗಳಿವೆ, ಸರಿಯಾದದ್ದು ನೀವು ಏನನ್ನು ನಿಯಂತ್ರಿಸುತ್ತೀರಿ ಮತ್ತು ಏನನ್ನು ಬಿಟ್ಟುಕೊಡಲು ಸಿದ್ಧ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಕೆಳಗಿನ ಮೂರು ಪ್ರಶ್ನೆಗಳಿಗೆ ಕ್ರಮವಾಗಿ ಉತ್ತರಿಸಿ, ಆಯ್ಕೆ ರುಚಿಯ ವಿಷಯವಲ್ಲ.

ಮೊದಲು ಯಾವ ದಿಕ್ಕು ಮುರಿದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

ವಿನಂತಿ VPN ಪೂಲ್‌ನಿಂದ ಬಂದ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬರುತ್ತದೆ. ಸರ್ವರ್ ಅದನ್ನು LAN ನ ಹೋಸ್ಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಆ ಹೋಸ್ಟ್ ತನ್ನದೇ ಕೋಷ್ಟಕ ಹೆಸರಿಸುವ ಗೇಟ್‌ವೇಗೆ, ಸಾಮಾನ್ಯವಾಗಿ LAN ನ ರೌಟರ್‌ಗೆ, ಉತ್ತರಿಸುತ್ತದೆ. ರೌಟರ್‌ಗೆ ಪೂಲ್‌ಗೆ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ ಉತ್ತರ ಅಲ್ಲಿಯೇ ಸಾಯುತ್ತದೆ ಅಥವಾ ಇಂಟರ್ನೆಟ್ ಕಡೆ ಅಲೆದಾಡುತ್ತದೆ.

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

LAN ನ ಹೋಸ್ಟ್ ಈಗಾಗಲೇ VPN ಸರ್ವರ್‌ನ್ನು ತೋರಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಸಮಸ್ಯೆ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಅಥವಾ MTU ಮಿತಿ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಕಾಣೆಯಾಗಿಲ್ಲ. ಫಿಲ್ಟರ್ ಸರಿಪಡಿಸಲು ಮಾರ್ಗ ಸೇರಿಸಬೇಡಿ.

ಮೊದಲ ಪ್ರಶ್ನೆ: ದೂರದ LAN ನ ರೌಟರ್ ಸಂಪಾದಿಸಬಹುದೇ?

LAN ನ ರೌಟರ್ ನಿಮ್ಮದಾಗಿದ್ದರೆ, ಸ್ವಚ್ಛ ಉತ್ತರ VPN ಪೂಲ್‌ಗೆ ಸ್ಥಿರ ಮಾರ್ಗ, ಅದರಲ್ಲಿ VPN ಸರ್ವರ್‌ನ LAN ವಿಳಾಸ ಮುಂದಿನ ನೆಗೆತ. ಇದು ಕ್ಲೈಂಟ್‌ಗಳ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಹಾಗೆಯೇ ಇರಿಸುತ್ತದೆ, LAN ಹೋಸ್ಟ್‌ಗಳು ವಿಳಾಸದ ಆಧಾರದಲ್ಲಿ ಲಾಗ್, ಫಿಲ್ಟರ್ ಅಥವಾ ವೇಗ ಮಿತಿಗೊಳಿಸುವಾಗ ಇದು ಮುಖ್ಯ. ಸರ್ವರ್‌ನಲ್ಲಿ ಅನುವಾದವೂ ಬೇಕಿಲ್ಲ, ಹೀಗಾಗಿ ಸುರಂಗ ಶುದ್ಧ ಮಾರ್ಗವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಇದು ಸೃಷ್ಟಿಸುವ ಬಾಧ್ಯತೆ ದಾಖಲೀಕರಣ, ಏಕೆಂದರೆ ಪೂಲ್, ಮಾರ್ಗ ಮತ್ತು ಸರ್ವರ್ ಸಂರಚನೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.

ಯಾರಾದರೂ ಪೂಲ್ ಬದಲಿಸುವ ದಿನ ಇದು ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ. ಮೌಲ್ಯವನ್ನು ಒಮ್ಮೆ ಬರೆದಿಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಮೂರರಲ್ಲಿ ಯಾವುದಾದರೂ ಒಂದರಲ್ಲಿನ ಬದಲಾವಣೆಯನ್ನು ಮೂರಕ್ಕೂ ಬದಲಾವಣೆ ಎಂದು ಪರಿಗಣಿಸಿ.

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

ಎರಡನೇ ಪ್ರಶ್ನೆ: LAN ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ನೋಡುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದೇ?

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

ಬೆಲೆ ಆಪಾದನೆ: ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ನ ವಿಳಾಸಗಳು LAN ಲಾಗ್‌ಗಳಿಂದ ಮಾಯವಾಗುತ್ತವೆ. LAN ನ ಹೋಸ್ಟ್‌ನಲ್ಲಿನ ಯಾವುದೇ ಅನುಮತಿ ಪಟ್ಟಿ ಆಗ ಪೂಲ್‌ ಬದಲು ಸರ್ವರ್‌ನ್ನು ಹೆಸರಿಸಬೇಕು.

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

ಮೂರನೇ ಪ್ರಶ್ನೆ: ಸರ್ವರ್ ಸ್ವತಃ ಇನ್ನೊಂದು ಸುರಂಗದ ಕ್ಲೈಂಟ್‌ನೇ?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

ನಂತರ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಮತ್ತು ಎರಡೂ ಗಾತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

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

ನಂತರ ನಿಜವಾದ ಡೇಟಾ ಸರಿಸಿ, ಏಕೆಂದರೆ ಸಣ್ಣ ping ಯಶಸ್ವಿಯಾದರೆ ದೊಡ್ಡ ವರ್ಗಾವಣೆ ನಿಂತುಕೊಳ್ಳುವುದು MTU ಲಕ್ಷಣ. ಆ ದೋಷ ಮಾರ್ಗ ಸರಿಪಡಿಸಿದ್ದಕ್ಕಾಗಿ ನಿಮ್ಮನ್ನು ನೀವು ಅಭಿನಂದಿಸಿಕೊಂಡ ಕೂಡಲೇ ಕಾಣಿಸುತ್ತದೆ.

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು