Ping ಸಾಕ್ಷ್ಯವಲ್ಲ: ಎರಡು ಸೈಟ್ಗಳ ನಡುವಿನ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ಸೇವೆ ಬೇಕಾದ ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಬರೆಯಿರಿ: ಕ್ಲೈಂಟ್ನ ವಿಳಾಸ, ಗಮ್ಯಸ್ಥಾನದ ವಿಳಾಸ, ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪೋರ್ಟ್. ನಂತರ ಸೇವೆ ತನ್ನದೇ ಸೈಟ್ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಪಕ್ಕದ ಹೋಸ್ಟ್ನಿಂದ ದೃಢೀಕರಿಸಿ. ಈ ಮೂಲರೇಖೆ ಇಲ್ಲದೆ ಮುರಿದ ಸುರಂಗವನ್ನು ಮುರಿದ ಸೇವೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಈ ಟಿಕೆಟ್ಗಳ ಅರ್ಧ ಭಾಗ ಎರಡನೆಯದು.

ದಾಖಲಿತ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಸೇವೆ ಅನುಮತಿಸುವಲ್ಲಿ ಅದೇ ಪೋರ್ಟ್ನ ನೇರ ವಿಳಾಸ ಪರಿಶೀಲನೆಯನ್ನೂ ಮಾಡಿ. ವಿಫಲ ಹೆಸರು ಹುಡುಕಾಟ ಮತ್ತು ತಲುಪಲಾಗದ ಪರಿಹರಿಸಿದ ವಿಳಾಸ ನಿಮ್ಮನ್ನು ಬೇರೆ ಬೇರೆ ಮಾರ್ಗಗಳಿಗೆ ಕರೆದೊಯ್ಯುತ್ತವೆ. ಹೋಸ್ಟ್ ಹೆಸರಿನ ಬದಲು IP ಹಾಕಿದರೆ, ಅದು ಕೆಲಸ ಮಾಡಲು HTTPS ಗುರುತು ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ; ಪ್ರಮಾಣಪತ್ರದ ಎಚ್ಚರಿಕೆ ಮಾಹಿತಿ, ಅಡ್ಡಿಯಲ್ಲ.

ಪ್ರತಿ ಅಂಚಿನಲ್ಲಿ ಮಾರ್ಗವನ್ನು ನಡೆಯಿರಿ

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಪ್ರೋಟೋಕಾಲ್ ಬಳಸಿ

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

ವಿಫಲವಾಗುವ ಸ್ಥಿತಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸಿ

ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳಲ್ಲಿ ಮಾತ್ರ ಕಾಣುವ ವೈಫಲ್ಯಗಳು ಗಾತ್ರದ ಸಮಸ್ಯೆ, ಸಂಪರ್ಕದ್ದಲ್ಲ. don't-fragment ಬಿಟ್ ಸೆಟ್ ಮಾಡಿದ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿ ಅದು ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ನೋಡಿ. ಸಣ್ಣ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗಿ ದೊಡ್ಡದು ನೇತಾಡಿದರೆ, ಸುರಂಗದ MTU ಮತ್ತು ಗೇಟ್ವೇಗಳಲ್ಲಿ MSS ನಿರ್ವಹಣೆ ಮುಂದಿನ ಶಂಕಿತರು.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

ಸರಿಪಡಿಸಿದ ನಂತರ ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ

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

ನಾಲ್ಕು ಮೂಲ ಮೌಲ್ಯಗಳು ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಿ. ಅದೇ ಲಕ್ಷಣದ ಮುಂದಿನ ವರದಿ ಆಗ ಪಿಂಗ್ ಬದಲು ಸಾಕ್ಷ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗಬಹುದು.