ಕೆಲಸ ಮಾಡುವ VPN ಇದ್ದರೂ ಉತ್ತರಕ್ಕೆ ಸಮಯ ಮೀರುತ್ತದೆ ಏಕೆ
ಒಂದು ವಿನಂತಿ ಖಾಸಗಿ ಸರ್ವರ್ ತಲುಪುವುದು ವಿನಿಮಯದ ಅರ್ಧ ಮಾತ್ರ. ಅದರ ಉತ್ತರವು ಉದ್ದೇಶಿತ ಗೇಟ್ವೇ, ಮಾರ್ಗ ಅಥವಾ ಭಾಷಾಂತರದ ಮೂಲಕ ಟನೆಲ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ತಲುಪಬೇಕು.
ವಿನಂತಿ ಬರುತ್ತದೆ, ಸರ್ವರ್ ಅದನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ ಎಂದರೆ ಉತ್ತರಕ್ಕೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಸಿಗಲಿಲ್ಲ, ಮತ್ತು ಇದು ಎರಡೂ ತುದಿಗಳಿಂದ ಒಟ್ಟಿಗೆ ದೃಢೀಕರಿಸಬಹುದಾದ ಕೆಲವೇ ದೋಷಗಳಲ್ಲಿ ಒಂದು. ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಒಂದು ವಿಫಲವಾದಾಗ ನಿಲ್ಲಿಸಿ.
ವಿನಂತಿ ಎಲ್ಲಿ ಬಂದಿತು ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಬೇರೆ ಯಾವುದನ್ನೂ ಪರಿಶೀಲಿಸುವ ಮೊದಲು ಪ್ಯಾಕೆಟ್ ಸೇವೆಯನ್ನು ತಲುಪಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಸರ್ವರ್ ಕಡೆಯ ಲಾಗ್ ನಮೂದು, ಸಂಪರ್ಕ ಎಣಿಕೆ ಅಥವಾ ದೂರದ ತುದಿಯಲ್ಲಿ ಅನುಮತಿಸಲಾದ ಸೆರೆಹಿಡಿಯುವಿಕೆ — ಎಲ್ಲವೂ ಒಂದೇ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಅವು ಇಲ್ಲದಿರುವುದು ನಿಮ್ಮನ್ನು ಉತ್ತರದ ಕಡೆಗಲ್ಲ, ಟನೆಲಿನ ಕಡೆಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಇದೇ ಮುಂದುವರಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುವ ಪರಿಶೀಲನೆ.
ವಿನಂತಿ ಎಂದೂ ಬಂದಿಲ್ಲದಿದ್ದರೆ, ಇಲ್ಲೇ ನಿಲ್ಲಿಸಿ. ಟನೆಲ್, ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ರೂಟಿಂಗ್ ಅಥವಾ ಪ್ರವೇಶ ನಿಯಮವು ವಿಷಯ, ಮತ್ತು ಉತ್ತರದ ಮಾರ್ಗ ಇನ್ನೂ ಸಂಬಂಧಿತವಲ್ಲ. ಸರ್ವರ್ ನೋಡಿದ ಮೂಲ ವಿಳಾಸವನ್ನೂ ದಾಖಲಿಸಿ. ಅದು ಕ್ಲೈಂಟ್ಗೆ ಸಿಕ್ಕ ಪೂಲ್ ವಿಳಾಸ ಅಥವಾ ಭಾಷಾಂತರಿತ ವಿಳಾಸ, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸವೇ ಮುಂದಿನ ಯಾವ ಪರಿಶೀಲನೆ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಉತ್ತರಕ್ಕೆ ಪೂಲ್ಗೆ ಮಾರ್ಗ ಬೇಕು
ದೂರಸ್ಥ ಪ್ರವೇಶದ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಪೂಲ್ನಿಂದ ವಿಳಾಸ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ಗೆ ಆ ಪೂಲ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು. ತನ್ನದೇ ಗೇಟ್ವೇ ಕಡೆಗೆ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ತೋರಿಸುವ ಸರ್ವರ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಆ ಗೇಟ್ವೇಗೆ ಒಪ್ಪಿಸುತ್ತದೆ, ಅದಕ್ಕೆ ಪೂಲ್ ಎಲ್ಲಿದೆ ಎಂಬುದೇ ಗೊತ್ತಿಲ್ಲ, ಹಾಗಾಗಿ ಉತ್ತರ ಅಲ್ಲೇ ಸಾಯುತ್ತದೆ. ಏನೂ ಹಿಂತಿರುಗದ ಕಾರಣ ಕ್ಲೈಂಟ್ಗೆ ಸಮಯ ಮೀರುವಿಕೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಇದನ್ನು ಎಂದೂ ಹೊರಟಿಲ್ಲದ ವಿನಂತಿಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗದು.
ಸರ್ವರ್ ತನ್ನದೇ ಸಬ್ನೆಟ್ಗೆ ಬಳಸುವ ಮಾರ್ಗವಲ್ಲ, ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ಆಯ್ಕೆ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ. ಈ ಎರಡು ಹುಡುಕಾಟಗಳು ಬೇರೆ ಬೇರೆ ಉತ್ತರ ನೀಡಬಹುದು, ಮತ್ತು ಇಲ್ಲಿ ಎರಡನೆಯದೇ ಮುಖ್ಯ. ಭಾಷಾಂತರವು ಪರ್ಯಾಯ ವಿನ್ಯಾಸ ಮತ್ತು ಅದು ಸರ್ವರ್ ನೋಡುವುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಅದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸರಳಗೊಳಿಸಬಹುದು, ಮತ್ತು ಸರ್ವರ್ನ ಲಾಗ್ಗಳಿಂದ ಮೂಲ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನೂ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇದು ಆ ಕ್ಷೇತ್ರದ ಮೇಲೆ ನಿರ್ಮಿಸಿದ ಯಾವುದೇ ನಿಯಮ ಅಥವಾ ವರದಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಸರ್ವರ್ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಗೇಟ್ವೇ ಸೆರೆಹಿಡಿಯುವಿಕೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ
ಸರ್ವರ್ನಿಂದ ಹೊರಹೋಗುವುದನ್ನು ಗೇಟ್ವೇಗೆ ತಲುಪುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ಸರ್ವರ್ನ ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಮತ್ತು ಟನೆಲ್ ಗೇಟ್ವೇನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಪ್ರಶ್ನೆಯ ಬೇರೆ ಬೇರೆ ಅರ್ಧಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಅಂತರವು ನಷ್ಟದ ಸ್ಥಳವನ್ನು ತೋರಿಸುತ್ತದೆ.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
ಗೇಟ್ವೇ ಸ್ವತಃ ರಚಿಸುವ ವಿನಂತಿ ಕ್ಲೈಂಟ್ ಪರೀಕ್ಷೆಗೆ ಕಳಪೆ ಬದಲಿ, ಏಕೆಂದರೆ ಅದು ಬೇರೆ ವಿಳಾಸದಿಂದ ಬರುತ್ತದೆ ಮತ್ತು ಬೇರೆ ನಿಯಮಗಳನ್ನು ಎದುರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಗೇಟ್ವೇನಿಂದ ಯಶಸ್ವಿ ping ಮತ್ತು ಕ್ಲೈಂಟ್ನಿಂದ ವಿಫಲ ವಿನಂತಿ ಎರಡೂ ಒಟ್ಟಿಗೆ ನಿಜವಾಗಿರಬಹುದು.
ಮಾರ್ಗದಲ್ಲಿ ಹಲವು ರೂಟರ್ಗಳಿದ್ದರೆ, ಪೂಲ್ಗೆ ಮಾರ್ಗ ಬೇಕಾದ ಪ್ರತಿಯೊಂದನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಸೈಟ್ನಿಂದ ಸೈಟ್ ವಿನ್ಯಾಸದಲ್ಲಿ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಾಧನಗಳಲ್ಲಿ ತಿಳಿದಿರಬೇಕು, ಮತ್ತು ಗೇಟ್ವೇ ಸ್ವತಃ ಟನೆಲ್ ಮತ್ತು LAN ನಡುವೆ ಮುಂದುವರಿಸಬೇಕು; strongSwan ನ ಮುಂದುವರಿಕೆ ಟಿಪ್ಪಣಿಗಳು ಅದರ sysctl ಮತ್ತು ಫೈರ್ವಾಲ್ ಭಾಗವನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ.
ಪೂಲ್, ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಜವಾಬ್ದಾರರನ್ನು ದಾಖಲಿಸಿ
ಟಿಪ್ಪಣಿಗೆ ನಾಲ್ಕು ಅಂಶಗಳು ಸೇರುತ್ತವೆ: ಕ್ಲೈಂಟ್ ಪಡೆದ ಪೂಲ್, ಅದಕ್ಕೆ ಬೇಕಾದ ಖಾಸಗಿ ಪ್ರಿಫಿಕ್ಸ್, ಉತ್ತರಕ್ಕೆ ಜವಾಬ್ದಾರನಾದ ರೂಟರ್, ಮತ್ತು ಇದ್ದರೆ ಭಾಷಾಂತರ ನಿಯಮ. ಇವುಗಳಿಂದ ನಂತರದ ಗೇಟ್ವೇ ಬದಲಾವಣೆ ತನಿಖೆಯಲ್ಲ, ಹೋಲಿಕೆ.
ನಂತರ ಸಾಮಾನ್ಯ ಕ್ಲೈಂಟ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ನಿಜವಾದ ಖಾತೆಯೊಂದಿಗೆ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಸವಲತ್ತುಗಳನ್ನು ವಿಸ್ತರಿಸುವುದರಿಂದ ಪ್ಯಾಕೆಟ್ನ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಸರಿಯಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಈ ರೋಗನಿರ್ಣಯದ ವೇಳೆ ಖಾತೆ ಬದಲಿಸುವುದು ಮುಂದಿನ ಹೋಲಿಕೆಯನ್ನು ಗೊಂದಲಗೊಳಿಸುತ್ತದೆ. ವಿನ್ಯಾಸ ಭಾಷಾಂತರವನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಸರ್ವರ್ನ ಲಾಗ್ಗಳನ್ನು ಓದುವಲ್ಲಿಯೇ ಅದನ್ನು ದಾಖಲಿಸಿ. ಆಡಿಟ್ ಜಾಡಿನಲ್ಲಿ ಪರಿಚಯವಿಲ್ಲದ ಮೂಲ ವಿಳಾಸವನ್ನು ನೋಡುವವರು ಟಿಕೆಟ್ನಿಂದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳಬೇಕಾಗಬಾರದು.