ರೂಟ್ ಆದ VPN ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ತಲುಪುತ್ತದೆ ಆದರೆ LAN ಹೋಸ್ಟ್ಗಳನ್ನಲ್ಲ

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

ವಿನಂತಿಯನ್ನಲ್ಲ, ಉತ್ತರವನ್ನು ಅನುಸರಿಸಿ

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

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

ಹೋಸ್ಟ್ಗಳು ನೋಡುವಲ್ಲಿಯೇ ರಿಟರ್ನ್ ರೂಟ್ ಇರಿಸಿ

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

ಗೇಟ್ವೇ ತನ್ನ ವಿಳಾಸವನ್ನು DHCP ಆಯ್ಕೆಯಾಗಿ ಹಂಚಿದರೆ, ರೂಟ್ ಅನ್ನು ಅದೇ ರೀತಿ ಹಂಚಿ ಇದರಿಂದ ಹೊಸ ಯಂತ್ರಗಳು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ. ಇಲ್ಲದಿದ್ದರೆ ರೂಟ್ ಒಂದು ಸಂರಚನಾ ಫೈಲ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಪುನರ್ನಿರ್ಮಾಣದಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

ಮೂಲ NAT ಅದನ್ನು ಸರಿಪಡಿಸಿದಂತೆ ಏಕೆ ಕಾಣುತ್ತದೆ

ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅನ್ನು VPN ಸರ್ವರ್ ವಿಳಾಸದ ಹಿಂದೆ ಮುಸುಕು ಮಾಡುವುದು ಪ್ಯಾಕೆಟ್ನಿಂದ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ನಂತರ ಉತ್ತರಗಳು ಟನೆಲ್ ತಲುಪುವ ಬಗೆ ತಿಳಿದಿರುವ ಸರ್ವರ್ಗೆ ಹಿಂತಿರುಗುತ್ತವೆ, ಮತ್ತು ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಬೆಲೆ ಎಂದರೆ ಒಳಗಿನ ಹೋಸ್ಟ್ಗಳು ಕ್ಲೈಂಟ್ ಯಾರೆಂದು ಇನ್ನು ಮುಂದೆ ನೋಡಲಾರರು, ಮತ್ತು ಪ್ರತಿ ಸಂಪರ್ಕವೂ ಒಂದೇ ಯಂತ್ರದಿಂದ ಬಂದಂತೆ ಕಾಣುತ್ತದೆ.

ಈ ವಿನಿಮಯ ಕೆಲವೊಮ್ಮೆ ಸರಿಯಾಗಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಮಾರಾಟಗಾರರ ಸಾಧನಕ್ಕೆ ಸ್ಥಿರ ರೂಟ್ ನೀಡಲು ಸಾಧ್ಯವಿಲ್ಲದಾಗ. ನಿಯಮವನ್ನು ಪ್ರಸ್ತುತ ಪೂಲ್ಗಿಂತ ಅಗಲ ಮಾಡಬೇಡಿ, ಏಕೆಂದರೆ /24 ಗಾಗಿ ಬರೆದ ನಿಯಮವು ಪೂಲ್ /16 ಗೆ ಮರುಸಂಖ್ಯೆಯಾದ ದಿನ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಸೂಚನೆ ಎಂದರೆ ಸಂಪರ್ಕಿಸಿ ಯಾವುದನ್ನೂ ತಲುಪದ ಹೊಸ ಕ್ಲೈಂಟ್ಗಳ ಗುಂಪು.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

ಕ್ಲೌಡ್ ದಾರಿಗೆ ಮೂರು ಸೆಟ್ಟಿಂಗ್ಗಳು ಬೇಕು

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

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

ಪರಿಶೀಲನೆಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ನಡೆಸಿ

ರೂಟಿಂಗ್ಗೆ ದೋಷ ಹೇರುವ ಮೊದಲು ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಫಿಲ್ಟರ್ ನೀತಿಯನ್ನು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡದ ಹೋಸ್ಟ್ ಕೂಡ ಅದೇ ನಿಶ್ಶಬ್ದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ನಂತರ ಟನೆಲ್ ಸಾಗಿಸುವ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ರಿವರ್ಸ್-ಪಾತ್ ಸೆಟ್ಟಿಂಗ್ ಓದಿ, ಏಕೆಂದರೆ ಕಟ್ಟುನಿಟ್ಟಿನ ಫಿಲ್ಟರ್ ಅನಿರೀಕ್ಷಿತ ದಿಕ್ಕಿನಿಂದ ಬರುವ ಉತ್ತರಗಳನ್ನು ಬಿಸಾಡಬಹುದು.

ಕ್ಲೈಂಟ್ LAN ಹೋಸ್ಟ್ಗೆ ಪಿಂಗ್ ಮಾಡುತ್ತಿರುವಾಗ ಅಲ್ಲಿ ತೆಗೆದ ಕ್ಯಾಪ್ಚರ್ನೊಂದಿಗೆ ಮುಗಿಸಿ. ಹೊಂದುವ ಉತ್ತರವಿಲ್ಲದೆ ಬರುವ ವಿನಂತಿ ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಎಂದಿಗೂ ಬರದ ವಿನಂತಿ ದೋಷವನ್ನು ಸರ್ವರ್ ಅಥವಾ ಟನೆಲ್ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಪರಿಶೀಲನೆ ಎಲಾಸ್ಟಿಕ್ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ದಾಖಲಾಗಿದೆ. ಅದನ್ನು ಟನೆಲ್ ಸಂಚಾರವನ್ನು ನಿಜವಾಗಿ ಸಾಗಿಸುವ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸೆಟ್ ಮಾಡಿ, ಅದೇ ಇನ್ಸ್ಟೆನ್ಸ್ಗೆ ಜೋಡಿಸಿದ ಅಸಂಬಂಧಿತ ಅಡಾಪ್ಟರ್ನಲ್ಲಿ ಅಲ್ಲ.