LAN ಸರ್ವರ್ನಲ್ಲಿ VPN ಕ್ಲೈಂಟ್: ಉತ್ತರಗಳು ತಪ್ಪು ಮಾರ್ಗದಲ್ಲಿ ಏಕೆ ಹೊರಡುತ್ತವೆ

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

ಉತ್ತರ ಹೊಸ ಪ್ಯಾಕೆಟ್, ಮಾರ್ಗದ ಹಿಮ್ಮುಖವಲ್ಲ

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

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

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

ಕ್ಯಾಪ್ಚರ್ ಮತ್ತು ಲುಕಪ್ನಿಂದ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು, ಉತ್ತರ ಯಾವ ಸಾಧನವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಲುಕಪ್ ಕ್ಯಾಪ್ಚರ್ಗಿಂತ ವೇಗವಾಗಿದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಿರ್ಮಿಸುವಾಗ ಕರ್ನಲ್ ಉತ್ತರಿಸುವ ಅದೇ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

ಉತ್ತರವನ್ನು ಎರಡು ಭಾಗಗಳಲ್ಲಿ ಓದಿ. ಅದು dev tun0 ಎಂದು ಹೆಸರಿಸಿದರೆ, ಹೋಸ್ಟ್ ಉತ್ತರವನ್ನು ಸುತ್ತಿಕೊಂಡು ಪೂರೈಕೆದಾರರಿಗೆ ನೀಡುತ್ತದೆ, ಮತ್ತು LAN ಕ್ಲೈಂಟ್ ಅದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಅದು dev eth0 ಎಂದು ಹೆಸರಿಸಿ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಮಯ ಮೀರುವಿಕೆ ಪಡೆದರೆ, ರೂಟ್ ಈಗಾಗಲೇ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಂತರ ಬಿಸಾಡಲ್ಪಡುತ್ತದೆ, ಅದು ಬೇರೆ ಸಮಸ್ಯೆ ಮತ್ತು ಬೇರೆ ಪರಿಹಾರ.

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

ಟನಲ್ ಮೀರಿಸುವ ಅತ್ಯಂತ ಸಣ್ಣ ರೂಟ್ ಸ್ಥಾಪಿಸಿ

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

ಎರಡನೇ add ಬದಲು replace ಬಳಸಿ, ಏಕೆಂದರೆ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ನಮೂದನ್ನು ಸ್ಥಾಪಿಸಿರುತ್ತದೆ ಮತ್ತು ಎರಡನೇ add ಅನುಮತಿ ಸಮಸ್ಯೆಯಂತೆ ಓದುವ ಇರುವ-ಮಾರ್ಗ ದೋಷದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ. Windows ಹೋಸ್ಟ್ನಲ್ಲಿ ಸಮಾನವಾದದ್ದು route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, ಅಲ್ಲಿ -p ಮರುಪ್ರಾರಂಭಗಳ ನಡುವೆ ನಮೂದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಟನಲ್ ಮತ್ತೆ ಏಳುವಾಗ ಕ್ಲೈಂಟ್ ಕೋಷ್ಟಕವನ್ನು ಮರುನಿರ್ಮಿಸಬಹುದು. ಆಧುನಿಕ Windows ಹೋಸ್ಟ್ನಲ್ಲಿ ಬೆಂಬಲಿತ ಸಮಾನವಾದದ್ದು New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, ಮತ್ತು ಹಳೆಯ route ಆಜ್ಞೆ ಪರಂಪರೆಯ ರೂಪವಾಗಿ ಉಳಿಸಲ್ಪಟ್ಟಿದೆ.

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

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಉತ್ತರವನ್ನು ಉಳಿಸಿ

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

ಸ್ಥಿತಿ ಇರುವ ಫೈರ್ವಾಲ್ ಸರಿಯಾದ ರೂಟ್ ಅನ್ನು ಇನ್ನೂ ಸೋಲಿಸಬಹುದು. ಕ್ಯಾಪ್ಚರ್ ಈಗ ಉತ್ತರ eth0 ಮೂಲಕ ಹೊರಡುತ್ತದೆ ಎಂದು ತೋರಿಸಿ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಮಯ ಮೀರುವಿಕೆ ಪಡೆದರೆ, ಹೋಸ್ಟ್ ಕಳುಹಿಸುವ ಮೊದಲು ಪ್ಯಾಕೆಟ್ ಬಿಸಾಡುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕಟ್ಟುನಿಟ್ಟಿನ ರಿವರ್ಸ್-ಪಾತ್ ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು net.ipv4.conf.all.rp_filter ಅನ್ನು 1 ಗೆ ಹೊಂದಿಸುವುದು, ಯಾವ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಬಂದಿತೋ ಅದರ ಮೂಲಕವೇ ಹಿಂದಕ್ಕೆ ರೂಟ್ ಆಗದ ಮೂಲವನ್ನು ಹೊಂದಿರುವ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಬಿಸಾಡುತ್ತದೆ, ಮತ್ತು ಇದು ನೀವು ಈಗಷ್ಟೇ ಸೃಷ್ಟಿಸಿ ನಂತರ ಸರಿಪಡಿಸಿದ ಅಸಮ್ಮಿತ ಪ್ರಕರಣವೇ, ಮತ್ತು conntrack ಸ್ಥಿತಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪೋರ್ಟ್ಗಳಿಗೆ ಅದೇ ಕಥೆ ಹೇಳುತ್ತದೆ.

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