ಸಮಾನ ವೆಚ್ಚದ ಮಾರ್ಗಗಳು VPN ದೋಷಗಳನ್ನು ನೋಡಲು ಕಷ್ಟವಾಗಿಸುವುದೇಕೆ
ಹಲವು ಸುರಂಗಗಳು ಒಂದೇ ವೆಚ್ಚವನ್ನು ಹಂಚಿಕೊಂಡಾಗ, ಪ್ರತಿ ಹರಿವೂ ಬೇರೊಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಯಶಸ್ವಿ ping ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಬಳಸುವ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಒಬ್ಬ ಬಳಕೆದಾರರು ಆಂತರಿಕ ಅಪ್ಲಿಕೇಶನ್ ಒಂದು ಯಂತ್ರದಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದರಿಂದ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಗೇಟ್‌ವೇಯಿಂದ ನೀವು ಚಲಾಯಿಸುವ ping ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ. ಸಮಾನ ವೆಚ್ಚದ ಹಲವು ಸುರಂಗಗಳಿದ್ದಾಗ ಇದು ವಿರೋಧಾಭಾಸವಲ್ಲ. ಪ್ರತಿ ಹರಿವೂ ತನ್ನದೇ ಮುಂದಿನ ಹಾಪ್‌ನಲ್ಲಿ ಇಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಪರಿಶೀಲನೆ ಮತ್ತು ಬಳಕೆದಾರರ ಅಧಿವೇಶನ ಬೇರೆ ಬೇರೆ ಮಾರ್ಗಗಳನ್ನು ಬಳಸುತ್ತಿರಬಹುದು. ಕೆಳಗಿನ ವಿವರಣೆ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಆ ಆಯ್ಕೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ.
ಒಂದು ping, ಹಲವು ಸಾಧ್ಯ ಮಾರ್ಗಗಳು
ಒಂದೇ ವೆಚ್ಚದಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಂದಿನ ಹಾಪ್‌ಗಳಿದ್ದರೆ, ರೌಟರ್ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ಗೆ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕು. ಬಹುಪಾಲು ಅನುಷ್ಠಾನಗಳು ಪ್ಯಾಕೆಟ್‌ನ ಕ್ಷೇತ್ರಗಳನ್ನು ಹ್ಯಾಶ್ ಮಾಡುತ್ತವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸಗಳನ್ನು ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಪೋರ್ಟ್‌ಗಳೊಂದಿಗೆ, ಪ್ರತಿಕ್ರಿಯೆಗಳು ಅದೇ ಮಾರ್ಗದಲ್ಲಿ ಉಳಿಯಲು. ಬೇರೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಅಥವಾ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಬೇರೆ ಸಂಪರ್ಕಗಳೂ ಬೇರೆ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ.
ಅದಕ್ಕೇ ಗೇಟ್‌ವೇಯಿಂದ ಮಾಡಿದ ರೋಗನಿರ್ಣಯ ಎಷ್ಟು ಕಡಿಮೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಪರಿಶೀಲನೆಗೆ ತನ್ನದೇ ವಿಳಾಸಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳು ಇವೆ, ಹಾಗಾಗಿ ತನ್ನದೇ ಹ್ಯಾಶ್ ಕೂಡ. ಅದು ಆರೋಗ್ಯಕರ ಸುರಂಗದ ಮೇಲೆ ಇಳಿಯಬಹುದು, ಆದರೆ ಬಳಕೆದಾರರು ಮುರಿದ ಸುರಂಗದ ಮೇಲೆಯೇ ಇಳಿಯುತ್ತಿರುತ್ತಾರೆ.
ವೇದಿಕೆ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ
ಊಹಿಸುವ ಬದಲು ಆಯ್ಕೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸಿ. ವಿಫಲವಾಗುತ್ತಿರುವ ಅಧಿವೇಶನದಂತೆಯೇ ಅದೇ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕರ್ನೆಲ್ ಯಾವ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಕೇಳಿ. ಆ ಹುಡುಕಾಟವು ಸಾಮಾನ್ಯ ಗಮ್ಯಸ್ಥಾನ ಹುಡುಕಾಟವು ನಿರ್ಲಕ್ಷಿಸುವ ಕ್ಷೇತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಕ್ಲೈಂಟ್‌ನಿಂದಲೂ ಅದನ್ನು ಚಲಾಯಿಸಿ ಮತ್ತು ಎರಡೂ ಉತ್ತರಗಳನ್ನು ಹೋಲಿಸಿ:
ip route get 10.20.5.7 from 10.20.0.14ಹೊಸ iproute2 ಬಿಡುಗಡೆಗಳು ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಅನ್ನೂ ಸ್ವೀಕರಿಸುತ್ತವೆ, ಹ್ಯಾಶ್ ಅವುಗಳನ್ನು ಒಳಗೊಂಡಾಗ ಇದು ಮುಖ್ಯ. ಆ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಕ್ಲೈಂಟ್‌ನ ಅದೇ ಹುಡುಕಾಟದೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ವ್ಯತ್ಯಾಸವೇ ನಿಮಗೆ ಕಾಣದಿದ್ದ ಸಾಕ್ಷ್ಯ.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
ವಿಫಲವಾಗುವ ಹರಿವನ್ನು ಅನುಸರಿಸಿ, ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನಲ್ಲ
ಮಾರ್ಗ ಕೋಷ್ಟಕವು ಎರಡೂ ಸುರಂಗಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ವ್ಯಾಖ್ಯಾನದಂತೆಯೇ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ಪ್ರಶ್ನೆ ಎಂದರೆ ಆಯ್ಕೆಯಾದ ನಂತರ ಪ್ರತಿ ಸುರಂಗವೂ ಪ್ಯಾಕೆಟ್‌ನೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ. ಎರಡೂ ಒಂದೇ ರಕ್ಷಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು, ಒಂದೇ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನುಮತಿಯನ್ನು ಮತ್ತು ಅದೇ ಕ್ಲೈಂಟ್ ತಲುಪುವ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಹೊತ್ತಿವೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಮಧ್ಯದಲ್ಲಿರುವ ಸ್ಥಿತಿಧಾರಿ ಸಾಧನಗಳಿಗೆ ಗಮನ ಕೊಡಿ. ಒಂದು ವಿನಂತಿ ಒಂದು ಸುರಂಗದ ಮೂಲಕ ಹೊರಟು ಉತ್ತರ ಇನ್ನೊಂದರ ಮೂಲಕ ಹಿಂತಿರುಗಿದರೆ, ಮೂಲ ಹರಿವನ್ನು ಎಂದೂ ನೋಡದ ಫೈರ್ವಾಲ್ ಅಥವಾ NAT ಅದನ್ನು ಬಿಸಾಡುತ್ತದೆ. ಎರಡೂ ಸುರಂಗಗಳು ಸಂಚಾರವನ್ನು ಸರಿಯಾಗಿ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಸಂಪರ್ಕವು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ.
ಪ್ರತಿ ಮಾರ್ಗಕ್ಕೂ MTU ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಹೆಚ್ಚುವರಿ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಇರುವ ಮಾರ್ಗವು ಬಳಸಬಹುದಾದ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಒಂದು ಸುರಂಗದಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುವ ವರ್ಗಾವಣೆ ಇನ್ನೊಂದರಲ್ಲಿ ಚಿಕ್ಕದು ಮುರಿಯುವ ಅದೇ ಗಾತ್ರದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ.
ಒಂದೊಂದೇ ಮಾರ್ಗವನ್ನು ಹೋಲಿಸಿ
ವಿನ್ಯಾಸವು ನಿರ್ವಹಣೆಗೆ ಅವಕಾಶ ನೀಡುವಲ್ಲಿ, ಒಂದು ಸುರಂಗವನ್ನು ಸೇವೆಯಿಂದ ಹೊರತೆಗೆದು ಬಳಕೆದಾರರ ಕೆಲಸವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ದೋಷ ಮಾಯವಾದರೆ, ಸಮಸ್ಯೆ ನೀವು ತೆಗೆದ ಮಾರ್ಗದ್ದೇ, ಮತ್ತು ಮುಂದಿನ ಹೆಜ್ಜೆ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕವನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸುವುದಲ್ಲ, ಅದರ ಸಂರಚನೆಯನ್ನು ನೆರೆಯವರೊಂದಿಗೆ ಹೋಲಿಸುವುದು.
ಪುನರಾವರ್ತಿತ ping ಅಲ್ಲ, ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೋಲಿಸಿ. ದೋಷವು ನಿರ್ದಿಷ್ಟ ಮುಂದಿನ ಹಾಪ್, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ ಅಥವಾ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರದ ಪರಿವರ್ತನೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಆ ಮೂರು ಮಾದರಿಗಳು ಬೇರೆ ಬೇರೆ ದುರಸ್ತಿಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ.
ಕೊನೆಯದಾಗಿ, ಮಾರ್ಗಗಳನ್ನು ಸಮಾನವೆಂದು ಏಕೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ದೋಷವು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಸೇವೆಯಿಂದ ಹೇಗೆ ತೆಗೆಯಬೇಕು ಎಂದು ಬರೆಯಿರಿ. ಮಾರ್ಗಗಳು ನಿಜವಾಗಿಯೂ ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದಾಗ ಮಾತ್ರ ಬಹುಮಾರ್ಗ ಸುರಕ್ಷಿತ, ಮತ್ತು ಅದು ಊಹಿಸುವ ಬದಲು ಪರಿಶೀಲಿಸಬೇಕಾದ ವಿನ್ಯಾಸದ ಹೇಳಿಕೆ.