ರೂಟಿಂಗ್ ಟೇಬಲ್ ಮತ್ತು ನಿಜವಾದ ಹುಡುಕಾಟ: VPN ಸಂಚಾರ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ

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

ಟೇಬಲ್ ಅಭ್ಯರ್ಥಿಗಳ ಗುಂಪು, ನಿರ್ಣಯವಲ್ಲ

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

ಆದ್ದರಿಂದ ಮೊದಲ ಹೆಜ್ಜೆ ಪಟ್ಟಿ ಓದುವ ಬದಲು ಕರ್ನೆಲ್ಗೆ ಕೇಳುವುದು. ಹುಡುಕಾಟ ಆಜ್ಞೆ ಒಂದು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಮೂಲ ಆರ್ಗ್ಯುಮೆಂಟ್ನೊಂದಿಗೆ ಮುಂದುವರಿಸಲಾದ ಅಥವಾ ಬದ್ಧ ಸಂಪರ್ಕ ಬಳಸುವ ನಿಖರ ಜೋಡಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

ಮೇಲಿನ ಪ್ರತಿ ವಿಳಾಸವೂ ದಾಖಲೆ ಉದಾಹರಣೆ. ಮುಖ್ಯ ಅಂಶ ಉತ್ತರದ ಆಕಾರ: ಇಂಟರ್ಫೇಸ್, ಆಯ್ಕೆಮಾಡಿದ ಮೂಲ ವಿಳಾಸ, ಗೇಟ್ವೇ, ಮತ್ತು ನಮೂದು ಬಂದ ಟೇಬಲ್. ಆ ಔಟ್ಪುಟ್ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಇಂಟರ್ಫೇಸ್ಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಿದ್ದೀರಿ, ಮತ್ತು ಪೂರ್ಣ ಟೇಬಲ್ ಓದುವ ಯಾವುದೇ ಪ್ರಮಾಣವೂ ಯಾವ ಅಭ್ಯರ್ಥಿ ಗೆದ್ದಿತು ಎಂದು ಹೇಳುತ್ತಿರಲಿಲ್ಲ.

ಹುಡುಕಾಟ ಮೊದಲು ನಿಯಮಗಳ ಮೂಲಕ, ನಂತರ ಟೇಬಲ್ಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ

Linux ನಲ್ಲಿ ನಿರ್ಣಯ ಎರಡು ಹಂತದಲ್ಲಿದೆ. ನೀತಿ ನಿಯಮಗಳನ್ನು ಆದ್ಯತಾ ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ ಮೊದಲ ನಿಯಮ ಸಂಪರ್ಕಿಸಬೇಕಾದ ಟೇಬಲ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ; ಆ ಟೇಬಲ್ ನಂತರ ಅತ್ಯಂತ ಉದ್ದದ ಪ್ರಿಫಿಕ್ಸ್ ಹೊಂದಿಕೆಯನ್ನು ಮಾಡುತ್ತದೆ. ನಿಯಮವು ಮೂಲ, ಗಮ್ಯಸ್ಥಾನ, ಫೈರ್ವಾಲ್ ಮಾರ್ಕ್, ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಸಂಯೋಜನೆಯ ಮೇಲೆ ಹೊಂದಿಕೆಯಾಗಬಹುದು, ಆದ್ದರಿಂದ ಮುಖ್ಯ ಟೇಬಲ್ನ ಡಂಪ್ ಸಂಪೂರ್ಣ ನಿಖರ ಮತ್ತು ನೀವು ತನಿಖೆ ಮಾಡುತ್ತಿರುವ ಪ್ಯಾಕೆಟ್ಗೆ ಸಂಪೂರ್ಣ ಅಪ್ರಸ್ತುತವಾಗಿರಬಹುದು.

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 ಗೆ ತನ್ನದೇ ನಿಯಮಗಳು ಮತ್ತು ಟೇಬಲ್ಗಳಿವೆ. ಎರಡೂ ಕುಟುಂಬಗಳನ್ನು ಚಲಾಯಿಸುವ ವಿನ್ಯಾಸಕ್ಕೆ ಎರಡೂ ಹುಡುಕಾಟಗಳು ಬೇಕು, ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ IPv4 ಉತ್ತರ ಡ್ಯುಯಲ್-ಸ್ಟ್ಯಾಕ್ ಕ್ಲೈಂಟ್ ಇಷ್ಟಪಡಬಹುದಾದ v6 ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

VPN ಕ್ಲೈಂಟ್ ಏನನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ

ಕ್ಲೈಂಟ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಸುರಂಗದ ಸ್ವಂತ ಹೊರ ಮಾರ್ಗವನ್ನು ಮುರಿಯುತ್ತದೆ. ಅವು ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದದಿಂದ ಗೆಲ್ಲುವ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾದುದನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ: 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಅನ್ನು ಆವರಿಸುವ ಅರ್ಧ-ಡಿಫಾಲ್ಟ್ ಜೋಡಿ ಕ್ಲಾಸಿಕ್ ಉಪಾಯ, ಏಕೆಂದರೆ ಎರಡೂ 0.0.0.0/0 ಗಿಂತ ಉದ್ದವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಒಟ್ಟಾಗಿ ಇಡೀ ಜಾಗವನ್ನು ಆವರಿಸುತ್ತವೆ. ಇತರರು ನಿರ್ದಿಷ್ಟ ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್ಗಳ ಜೊತೆಗೆ ನೀತಿ ನಿಯಮವನ್ನು ಸ್ಥಾಪಿಸುತ್ತಾರೆ, ಮತ್ತು ಕೆಲವರು ಆಯ್ದ ಸಂಚಾರ ಮಾತ್ರ ಸೆಳೆಯಲ್ಪಡುವಂತೆ ಮಾರ್ಕ್ ಸೇರಿಸುತ್ತಾರೆ.

ಆದ್ದರಿಂದ "VPN ನನ್ನ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಾಯಿಸಲಿಲ್ಲ" ವಿಫಲತೆಯ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಅದು ನಿಜವಾಗಿ ಏನನ್ನು ಸೇರಿಸಿತು, ಮತ್ತು ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ಗಮ್ಯಸ್ಥಾನ ಆ ಪ್ರಿಫಿಕ್ಸ್ಗಳ ಒಳಗೆ ಬರುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

ಡಂಪ್ನಲ್ಲಿ ಎರಡು ಅರ್ಧ-ಮಾರ್ಗಗಳನ್ನು ಗಮನಿಸದೇ ಬಿಡುವುದು ಸುಲಭ, ಏಕೆಂದರೆ ಅವು ಡಿಫಾಲ್ಟ್ನಂತೆ ಕಾಣುವುದಿಲ್ಲ. ಪ್ರಿಫಿಕ್ಸ್ ಸೇರಿಸಲು ಮರೆತ split-tunnel ಸಂರಚನೆ ನೀವು ಬೆನ್ನಟ್ಟುತ್ತಿರುವ ಲಕ್ಷಣವನ್ನೇ ಉತ್ಪಾದಿಸುತ್ತದೆ: ಸುರಂಗ ಬಳಸಬೇಕಿದ್ದ ಅಪ್ಲಿಕೇಶನ್ ಬದಲಿಗೆ ಸ್ಥಳೀಯವಾಗಿ ಪರಿಹರಿಸಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಸ್ಥಾಪಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಬಳಕೆದಾರರಿಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ ಗಮ್ಯಸ್ಥಾನಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ, ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಪರೀಕ್ಷಿಸಿದ ವಿಳಾಸಗಳೊಂದಿಗಲ್ಲ. ಫೈಲ್ ಸರ್ವರ್ ಅನ್ನು ಆವರಿಸಿ ಅದರ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಆವರಿಸದ split-tunnel ಪಟ್ಟಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಿ ನಂತರ ದೃಢೀಕರಣದಲ್ಲಿ ವಿಫಲವಾಗುವ ಸಂಪರ್ಕವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅದು ಗುಪ್ತಪದ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಮಾರ್ಗ ಸಮಸ್ಯೆಯಾಗಿದೆ.

ಹೊರ ಮಾರ್ಗವೂ ಉಳಿಯಬೇಕು

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

ಒಳ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರಿಶೀಲಿಸಿದ ರೀತಿಯಲ್ಲೇ ಪೀರ್ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಅದು ಸುರಂಗಕ್ಕಲ್ಲದೆ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ಗೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ದೃಢಪಡಿಸಿ:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

ರೂಟಿಂಗ್ ಔಟ್ಪುಟ್ ನಿಮಗೆ ಏನನ್ನು ಹೇಳಲಾಗದು

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

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

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