IPsec ಗೇಟ್ವೇಯಿಂದ ಪಿಂಗ್ ಬೇರೆ ಮೂಲ ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತದೆ

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

ಪಿಂಗ್ ಉತ್ತರಿಸಬಲ್ಲ ಮೂರು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳು

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

ಮೊದಲು ಪ್ರಶ್ನೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ಇಲ್ಲದಿದ್ದರೆ ವಿಫಲವಾದ ಪಿಂಗ್ ನಿಮ್ಮಲ್ಲಿ ಈಗಾಗಲೇ ಇದ್ದ ಸಿದ್ಧಾಂತಕ್ಕೆ ಸಾಕ್ಷಿಯಾಗುತ್ತದೆ.

ಗೇಟ್ವೇ ನೀವು ನಿರೀಕ್ಷಿಸದ ವಿಳಾಸವನ್ನು ಏಕೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ

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

ಆದ್ದರಿಂದ ಆಚೆಯ ಬದಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲದ ವಿಳಾಸದಿಂದ, ಅಥವಾ ಯಾವ ಸೆಲೆಕ್ಟರ್ಗೂ ಹೊಂದದ ವಿಳಾಸದಿಂದ ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿ ಬರಬಹುದು. ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿದ್ದರೂ ಪಿಂಗ್ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ಈ ಲೇಖನ ಹೇಳುವುದು ಅದೇ ತಪ್ಪು ಋಣಾತ್ಮಕ ಫಲಿತಾಂಶದ ಬಗ್ಗೆ.

ಮೂಲವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿ

ನಿಯಂತ್ರಿತ Linux ಗೇಟ್ವೇಯಲ್ಲಿ ಈಗಾಗಲೇ ಸ್ಥಳೀಯವಾಗಿ ನಿಗದಿಯಾದ ಮೂಲವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ: ping -c 4 -I 10.30.0.1 10.40.0.20. ಇಲ್ಲಿನ ವಿಳಾಸಗಳು ಉದಾಹರಣೆಗಾಗಿ, ಆದ್ದರಿಂದ ಗೇಟ್ವೇಯ ನಿಜವಾದ ಒಳಗಿನ ವಿಳಾಸ ಮತ್ತು ನಿಜವಾದ ದೂರದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹಾಕಿ, ಮತ್ತು ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಮೂಲ ಈ ಸಾಧನಕ್ಕೆ ಸೇರಿದ್ದು ಮತ್ತು ಸೈಟ್ ನೀತಿ ಅದನ್ನು ಒಪ್ಪುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

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

ಕೇವಲ ವಿನಂತಿಯಲ್ಲ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಓದಿ

ದೂರದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ನಿಜವಾಗಿ ಯಾವ ಮೂಲ ತಲುಪುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ದಾರಿಯಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕ ಭಾಷಾಂತರವಿದ್ದರೂ ಸೇರಿಸಿ. ನಂತರ ಆಚೆಯ ಬದಿಯ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಆ ಮೂಲಕ್ಕೆ ಮತ್ತು ಅದನ್ನು ಅನುಮತಿಸುವ ಸೆಲೆಕ್ಟರ್ಗಳು ಅಥವಾ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಅನಿರೀಕ್ಷಿತ ಮೂಲದೊಂದಿಗೆ ಬರುವ ವಿನಂತಿ ಮಾರ್ಗ ಮತ್ತು ನೀತಿಯ ಪ್ರಶ್ನೆ, ಗೂಢಲಿಪೀಕರಣದ್ದಲ್ಲ.

ಇಲ್ಲಿ ಇನ್ನೊಂದು ಪಿಂಗ್ಗಿಂತ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವುದು ಹೆಚ್ಚು ಸಹಾಯ ಮಾಡುತ್ತದೆ: ಅದು ಆಚೆಯ ಬದಿ ನೋಡಿದ ಮೂಲವನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಉತ್ತರ ತಲುಪಬೇಕಾದ ವಿಳಾಸ ಅದೇ.

ನಂತರ ವರ್ಕ್ಲೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ

ನಿರ್ಣಾಯಕ ಪರೀಕ್ಷೆ ಎಂದರೆ ಗೇಟ್ವೇಯ ಹಿಂದಿನ ಸಾಮಾನ್ಯ ಹೋಸ್ಟ್ನಿಂದ ದೂರದ ಗೇಟ್ವೇಯ ಹಿಂದಿನ ಸಾಮಾನ್ಯ ಹೋಸ್ಟ್ಗೆ ಪಿಂಗ್. ಅದು ಗೇಟ್ವೇಯ ಮುಂದೆ ಕಳುಹಿಸುವ ಪಾತ್ರ, ಅಪ್ಲಿಕೇಶನ್ನ ನಿಜವಾದ ಮೂಲ ಮತ್ತು ನಿಜವಾದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಮುಖ್ಯವಾದ ಹರಿವು ಅದೇ.

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

ಕೇವಲ ಒಂದು ರೋಗನಿರ್ಣಯದ ಉತ್ತರ ಪಡೆಯಲು 169.254.0.0/16 ಗೆ ವ್ಯಾಪಕ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಬೇಡಿ. ಅದು ದಾರಿತಪ್ಪಿಸುವ ಪರೀಕ್ಷೆಯನ್ನು ಶಾಶ್ವತ ರೂಟಿಂಗ್ ನಿರ್ಧಾರಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ಸಂದರ್ಭವಿಲ್ಲದೆ ಪಡೆಯುತ್ತಾನೆ.