OpenVPN ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ತಲುಪುತ್ತದೆ ಆದರೆ LAN ಹೋಸ್ಟ್ಗಳನ್ನು ತಲುಪುವುದಿಲ್ಲ: ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಟನೆಲ್ ವಿಳಾಸ ping ಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಕಚೇರಿ LAN ನಲ್ಲಿ ಯಾವುದೂ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ. ಬಹುತೇಕ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅಪ್ಗ್ರೇಡ್ ನಂತರ ನಾನು ಇದನ್ನು ನೋಡುತ್ತೇನೆ, ಮತ್ತು ಮೊದಲ ಪ್ರವೃತ್ತಿ ಫೈರ್ವಾಲ್ ತೆರೆಯುವುದು, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಹೆಜ್ಜೆ: ಟನೆಲ್ ಸರಿಯಾಗಿದೆ, ಮತ್ತು ಕಡಿತವು ಪ್ಯಾಕೆಟ್ ದಾಟಬೇಕಾದ ಮೂರು ಹಾಪ್ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿದೆ. ಪ್ಯಾಕೆಟ್ ಹೋಗುವ ಕ್ರಮದಲ್ಲೇ ಮಾರ್ಗವನ್ನು ನಡೆಯಿರಿ, ಮೊದಲು ಕ್ಲೈಂಟ್ ಮಾರ್ಗ, ನಂತರ ಸರ್ವರ್ನ ಫಾರ್ವರ್ಡಿಂಗ್, ನಂತರ ಹಿಂತಿರುಗುವ ಪ್ರಯಾಣ, ಮತ್ತು ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ದೋಷದ ಮಾಲೀಕರನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ.

ಮೊದಲ ಹಂತ: ಕ್ಲೈಂಟ್ನ ರೂಟಿಂಗ್ ನಿರ್ಧಾರವನ್ನು ಗಮನಿಸಿ

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

ip route get 192.168.50.10

ಉತ್ತರವು ನಿಮ್ಮ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ಮತ್ತು ಕಚೇರಿ ಗೇಟ್ವೇಯನ್ನು ಹೆಸರಿಸಿದರೆ, ಸರ್ವರ್ ಬದಿಯ ಯಾವುದೇ ಬದಲಾವಣೆಯೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. OpenVPN ಮಾರ್ಗಗಳನ್ನು ಸರ್ವರ್ ಅವುಗಳನ್ನು ತಳ್ಳಿದಾಗ ಮಾತ್ರ ಹಂಚುತ್ತದೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್ನಲ್ಲಿ push "route 192.168.50.0 255.255.255.0" ಹುಡುಕಿ, ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. ಬಹುತೇಕ ಕ್ಲೈಂಟ್ಗಳು ತಳ್ಳಲಾದ ಮಾರ್ಗಗಳನ್ನು ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತವೆ, ಪ್ರೊಫೈಲ್ ಮರುಲೋಡ್ ಮಾಡಿದಾಗ ಅಲ್ಲ.

Windows ನಲ್ಲಿ ಅದೇ ಪ್ರಶ್ನೆಗೆ ಬೇರೆ ಆಜ್ಞೆ ಇದೆ. Find-NetRoute -RemoteIPAddress 192.168.50.10 ಸ್ಟಾಕ್ ಆಯ್ಕೆಮಾಡುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು route print -4 ತಳ್ಳಲಾದ ಪೂರ್ವಪ್ರತ್ಯಯವು ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ.

ಎರಡನೇ ಹಂತ: ಸರ್ವರ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

ಕ್ಲೈಂಟ್ ಮಾರ್ಗ ಸರಿಯಾಗಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಸರ್ವರ್ ತಲುಪುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಒಪ್ಪಬೇಕು. ಕರ್ನಲ್ ಸ್ವಿಚ್ ಮೊದಲ ದ್ವಾರ, ಮತ್ತು sysctl net.ipv4.ip_forward 1 ಹಿಂತಿರುಗಿಸಬೇಕು. echo 1 > /proc/sys/net/ipv4/ip_forward ನಿಂದ ಅದನ್ನು ಸೆಟ್ ಮಾಡುವುದು ಮುಂದಿನ ರೀಬೂಟ್ವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದೇ ಕಾರಣಕ್ಕೆ ಅದೇ ದೂರು ವಾರಗಳ ನಂತರ ಮತ್ತೆ ಬರುತ್ತದೆ.

ರೀಸ್ಟಾರ್ಟ್ ಅನ್ನು ಬದುಕುವ ಸ್ಥಳದಲ್ಲಿ ಅದನ್ನು ಬರೆಯಿರಿ:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

ಎರಡನೇ ದ್ವಾರ ಫಿಲ್ಟರ್ ಕೋಷ್ಟಕ. Docker ಸ್ಥಾಪಿಸಿದ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ FORWARD ನೀತಿ DROP ಆಗಿರುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಆ ನಿರ್ಧಾರವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ. iptables -L FORWARD -v -n ನೀತಿ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ಗಳನ್ನು ಎರಡನ್ನೂ ತೋರಿಸುತ್ತದೆ; ನೀತಿ DROP ಆಗಿದ್ದರೆ, ಫಾರ್ವರ್ಡಿಂಗ್ಗೆ ಟನೆಲ್ನಿಂದ LAN ದಿಕ್ಕಿಗೆ ಒಂದು ಸ್ಪಷ್ಟ ಅನುಮತಿ ಮತ್ತು ಉತ್ತರಕ್ಕೆ ಇನ್ನೊಂದು ಬೇಕು.

ಮೂರನೇ ಹಂತ: ಪ್ಯಾಕೆಟ್ ಅನ್ನು LAN ವರೆಗೆ ಅನುಸರಿಸಿ ಮತ್ತು ಉತ್ತರವನ್ನು ಹುಡುಕಿ

ಸರ್ವರ್ನ ಎರಡೂ ಬದಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗಮನಿಸಿ. ಟನೆಲ್ನಲ್ಲಿ ಮತ್ತು LAN ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ಒಂದು ಕ್ಲೈಂಟ್ ಮತ್ತು ಒಂದು ಹೋಸ್ಟ್ಗೆ ಫಿಲ್ಟರ್ ಮಾಡಿ ಇದರಿಂದ ಔಟ್ಪುಟ್ ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 ನಲ್ಲಿ ಮತ್ತು ನಂತರ ಮತ್ತೆ eth0 ನಲ್ಲಿ 10.8.0.x ಮೂಲದೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುವ ವಿನಂತಿಗಳು, ನಂತರ ಮೌನ ಬಂದರೆ, ಪ್ಯಾಕೆಟ್ ಬಂದಿತು ಮತ್ತು ಉತ್ತರ ಬೇರೆಡೆಗೆ ಹೋಯಿತು ಎಂದರ್ಥ. LAN ಹೋಸ್ಟ್ ತನ್ನ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಆ ಗೇಟ್ವೇಗೆ VPN ಪೂಲ್ಗೆ ಮಾರ್ಗವಿಲ್ಲ, ಮತ್ತು ಉತ್ತರ LAN ರೌಟರ್ನಲ್ಲಿ ಸಾಯುತ್ತದೆ. ಸರ್ವರ್ನಿಂದ LAN ಹೋಸ್ಟ್ಗೆ ping ಮಾಡುವುದು ಈ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಆ ಸಂಚಾರ ಎಂದಿಗೂ ಟನೆಲ್ ದಾಟುವುದಿಲ್ಲ.

ನಾಲ್ಕನೇ ಹಂತ: ಅನುವಾದ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ನಡುವೆ ಆಯ್ಕೆಮಾಡಿ

ಎರಡು ದುರಸ್ತಿಗಳು ರಂಧ್ರವನ್ನು ಮುಚ್ಚುತ್ತವೆ, ಮತ್ತು ping ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಪರಿಣಾಮಗಳು ಈ ಆಯ್ಕೆಗೆ ಇವೆ. ಮೂಲ ಅನುವಾದವು ಸರ್ವರ್ ಅನ್ನು ಕಾಣುವ ಕಳುಹಿಸುವವನನ್ನಾಗಿ ಮಾಡುತ್ತದೆ:

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

ನಿಯಮವನ್ನು ಪೂಲ್ ಮತ್ತು LAN ಇಂಟರ್ಫೇಸ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ನಂತರ ಅದನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಫೈರ್ವಾಲ್ ಮರುಲೋಡ್ ನಿಮ್ಮ ದುರಸ್ತಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಬೆಲೆ ಗುರುತು: LAN ಲಾಗ್ಗಳಲ್ಲಿ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಮಗಳಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ VPN ಸರ್ವರ್ನಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು per-client policy becomes guesswork.

LAN ರೌಟರ್ನಲ್ಲಿ VPN ಸರ್ವರ್ಗೆ ತೋರಿಸುವ 10.8.0.0/24 ಗಾಗಿ ಸ್ಥಿರ ಮಾರ್ಗವು ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ಗೋಚರವಾಗಿ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಆ ರೌಟರ್ ನಿಮ್ಮದಾಗಿದ್ದರೆ ಇದು ಉತ್ತಮ ದೀರ್ಘಾವಧಿ ಉತ್ತರ. ಅನೇಕ ಸೈಟ್ಗಳು ಸ್ವಲ್ಪ ಕಾಲ ಎರಡನ್ನೂ ನಡೆಸುತ್ತವೆ, ತಕ್ಷಣದ ದುರಸ್ತಿಗೆ NAT ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿ ಬರೆದ ನಂತರ ಮಾರ್ಗ. ಸರ್ವರ್ ಪೂಲ್ ಬದಲು ಸೈಟ್-ಟು-ಸೈಟ್ ಪೀರ್ ಆಗಿದ್ದರೆ, ಸರ್ವರ್ ಬದಿಗೂ ದೂರದ ಸಬ್ನೆಟ್ಗೆ iroute ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಪೀರ್ ಮಾರ್ಗ ಇರುತ್ತದೆ ಆದರೆ ಕ್ಲೈಂಟ್ ಸಂಚಾರ ಎಂದಿಗೂ ಅದರೊಂದಿಗೆ ಸಂಬಂಧಿಸುವುದಿಲ್ಲ.

ಐದನೇ ಹಂತ: ಕ್ಲೈಂಟ್ನಿಂದ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಏನು ಬದಲಾಯಿತು ಎಂದು ದಾಖಲಿಸಿ

ಲೂಪ್ ಅನ್ನು ಸರ್ವರ್ನಿಂದ ಅಲ್ಲ, ಕ್ಲೈಂಟ್ನಿಂದ ಮುಚ್ಚಿ. LAN ಹೋಸ್ಟ್ನಲ್ಲಿ ನಿಜವಾದ ಸೇವೆಗೆ ಸಂಪರ್ಕಿಸಿ, ನಂತರ iptables -t nat -L POSTROUTING -v -n ನಿಂದ ಅನುವಾದ ಕೌಂಟರ್ಗಳು ಚಲಿಸಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಶೂನ್ಯ ಪ್ಯಾಕೆಟ್ಗಳ ನಿಯಮವು ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದ ನಿಯಮ. ಹಿಂತಿರುಗುವ ದಿಕ್ಕು ಟ್ರ್ಯಾಕ್ ಆಗುತ್ತಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯ ಬೇಕಾದಾಗ conntrack -L -s 10.8.0.5 ಹರಿವು ಮತ್ತು ಅದರ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ.

ಸರ್ವರ್ ಕಾನ್ಫಿಗ್ನಲ್ಲಿ ಟಿಪ್ಪಣಿ ಬಿಡಿ: ಯಾವ ಸಬ್ನೆಟ್, ಯಾವ ಇಂಟರ್ಫೇಸ್, ಯಾವ ನಿಯಮ, ಮತ್ತು LAN ರೌಟರ್ನಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇದೆಯೇ. ಮುಂದಿನ ಬಾರಿ ಕ್ಲೈಂಟ್ ಅಪ್ಗ್ರೇಡ್ ತಳ್ಳಲಾದ ಮಾರ್ಗವನ್ನು ಅಳಿಸಿದಾಗ, ಆ ಟಿಪ್ಪಣಿ ಬೆಂಕಿ ನಂದಿಸುವ ಅಧಿವೇಶನವನ್ನು ಒಂದು ಸಾಲಿನ ದುರಸ್ತಿಯಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ.