Azure S2S VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ಸಂಚಾರವಿಲ್ಲ: IKE ಲಾಗ್ ಓದಿ

ಪೋರ್ಟಲ್ Connected ಎಂದು ಹೇಳುತ್ತದೆ, ಸುರಂಗಕ್ಕೆ ಅಪ್ಟೈಮ್ ಕೌಂಟರ್ ಇದೆ, ಮತ್ತು ನಿಮ್ಮ ವರ್ಚುವಲ್ ಯಂತ್ರದಿಂದ ಬಂದ trace ಎರಡನೇ ಹಾಪ್ನಲ್ಲಿ ಸಾಯುತ್ತದೆ. ಸಂಪರ್ಕದ ಸ್ಥಿತಿ IKE ಮತ್ತು IPsec ಮಾತುಕತೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಒಂದು ಪ್ಯಾಕೆಟ್ ನೀತಿ ಪದರದ ಮೂಲಕ ಉಳಿಯುತ್ತದೆಯೇ ಎಂದಲ್ಲ. ಈ ಟಿಕೆಟ್ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವನ್ನು ಎರಡು ದೋಷಗಳು ವಿವರಿಸುತ್ತವೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನೂ Azure ಮಾರ್ಗವನ್ನು ಬದಲಿಸಿ ಸರಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ಎರಡೂ ಈಗಾಗಲೇ ಗೇಟ್ವೇ ಸೃಷ್ಟಿಸಿದ ಲಾಗ್ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾನು ಮಾರ್ಗ ಕೋಷ್ಟಕದಿಂದ ಅಲ್ಲ, ಅಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ.

Connected ನಿಜವಾಗಿ ಏನನ್ನು ಪ್ರಮಾಣೀಕರಿಸುತ್ತದೆ

ಸಂಪರ್ಕಗೊಂಡ site-to-site ಸಂಪರ್ಕ ಎಂದರೆ ಹಂತ 1 ಮತ್ತು ಹಂತ 2 ಪೂರ್ಣಗೊಂಡಿವೆ ಮತ್ತು ಭದ್ರತಾ ಸಂಘಗಳು ಸಕ್ರಿಯವಾಗಿವೆ. ಇದು ಮಾತುಕತೆಯ ಬಗ್ಗೆ ಒಂದು ಹೇಳಿಕೆ: ಎರಡೂ ಪೀರ್ ಒಂದು ಪ್ರಸ್ತಾವನೆಗೆ ಒಪ್ಪಿಗೆ ನೀಡಿ, ಕೀಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿ SA ಜೋಡಿಯನ್ನು ಸ್ಥಾಪಿಸಿವೆ. ನೀವು ರಕ್ಷಿತ ಎಂದು ಭಾವಿಸುವ ಸಬ್ನೆಟ್ಗಳಿಗೆ ಸಂಚಾರ ಆಯ್ಕೆಗಾರರು ಹೊಂದುತ್ತವೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ನಂತರ ದೂರದ ಬದಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಲ್ಲಾದರೂ ರೂಟ್ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆಯೂ ಹೇಳುವುದಿಲ್ಲ. ಸುರಂಗವು ವಾರಗಳವರೆಗೆ ಚಾಲ್ತಿಯಲ್ಲಿದ್ದು ಪ್ರತಿ ಆಸಕ್ತಿಕರ ಹರಿವನ್ನೂ ಬಿಟ್ಟುಬಿಡಬಹುದು, ಮತ್ತು ಆರೋಗ್ಯಕರ ಗೇಟ್ವೇಯನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುವಂತೆ ಜನರನ್ನು ಪ್ರೇರೇಪಿಸುವುದು ನಿಖರವಾಗಿ ಇದೇ ಮಾದರಿ.

ಮೊದಲು ಪರಿಶೀಲಿಸಬೇಕಾದ ಎರಡು ದೋಷಗಳೆಂದರೆ ESP ಬದಲು AH ಪ್ರಸ್ತಾಪಿಸುವ ಪೀರ್, ಮತ್ತು ಗೇಟ್ವೇ ಒಳಗಿನದೆಂದು ಪರಿಗಣಿಸದ ಸ್ಥಳದಲ್ಲಿ ಸಂಖ್ಯೆ ಮಾಡಿದ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್.

ಮಾರ್ಗಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ರಫ್ತು ಮಾಡಿದ ಲಾಗ್ ತೆರೆಯಿರಿ

ಪೋರ್ಟಲ್ನಲ್ಲಿ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಗೇಟ್ವೇ ತೆರೆದು ಸಂಪರ್ಕದ ಮೇಲೆ VPN troubleshoot ಕಾರ್ಯಾಚರಣೆ ನಡೆಸಿ, ನಂತರ ಅದು ಉತ್ಪಾದಿಸುವ ಬಂಡಲ್ ಡೌನ್ಲೋಡ್ ಮಾಡಿ ಅನ್ಪ್ಯಾಕ್ ಮಾಡಿ. ಒಳಗೆ ಹಂತ 1 ಮತ್ತು ಹಂತ 2 ರ ವಿನಿಮಯಗಳಿರುವ IKE ಲಾಗ್ ಇದೆ, ಸಮಯ ಮುದ್ರೆಗಳೊಂದಿಗೆ ಮತ್ತು ಸರಳ ಪಠ್ಯವಾಗಿ ಓದಬಹುದು. ಮೇಲಿನಿಂದ ಕೆಳಗೆ ಓದುವ ಬದಲು ಅದರಲ್ಲಿ transform ಸಾಲನ್ನು ಹುಡುಕಿ, ಏಕೆಂದರೆ ಆಸಕ್ತಿಕರ ನಮೂದು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲವು ನೂರು ಸಾಲುಗಳ ಒಳಗಿರುತ್ತದೆ. ಪೋರ್ಟಲ್ ಪ್ರವೇಶ ಇಲ್ಲದಿದ್ದರೆ, ಡಯಾಗ್ನೋಸ್ಟಿಕ್ ಸೆಟ್ಟಿಂಗ್ಗಳು ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ಅದೇ ಡಯಾಗ್ನೋಸ್ಟಿಕ್ಸ್ ಗೇಟ್ವೇಯ ಲಾಗ್ ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ.

ಎರಡು ನಮೂದುಗಳು ಬಹುಪಾಲು ಮೌಲ್ಯವನ್ನು ಹೊತ್ತಿವೆ. ಮೊದಲನೆಯದು ಸುಮಾರು ಹೀಗೆ ಓದುತ್ತದೆ: expected ESP with combined authentication and cipher, received AH. ಎರಡನೆಯದು IKE ವಿನಿಮಯದ ಸಮಯದಲ್ಲಿ invalid payload ದೋಷ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಾಗಿ ರೂಪುಗೊಂಡ ಅಥವಾ ಬೆಂಬಲವಿಲ್ಲದ ಪ್ರಸ್ತಾವನೆ ಕ್ಷೇತ್ರ ಎಂದರ್ಥ.

ಎರಡೂ ಆನ್-ಪ್ರಿಮೈಸ್ ಸಾಧನ ಏನನ್ನು ಪ್ರಸ್ತಾಪಿಸಿತು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಎರಡೂ ಪೀರ್ ಬದಿಯ ಸೆಟ್ಟಿಂಗ್ಗಳು. ಸಂಪರ್ಕದ Azure ಬದಿಯನ್ನು ಮತ್ತೆ ಉತ್ಪಾದಿಸುವುದರಿಂದ ನಿಮ್ಮ ಫೈರ್ವಾಲ್ ಕಳುಹಿಸುವ ಪ್ರಸ್ತಾವನೆ ಬದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಹಾಗೆ ಮಾಡುವುದು ಈ ಕೆಲಸದಲ್ಲಿ ಹೆಚ್ಚು ವ್ಯರ್ಥವಾಗುವ ಗಂಟೆ. ಪೀರ್ನಲ್ಲಿ ಹಂತ 2 ಅನ್ನು ಸಂಯೋಜಿತ ದೃಢೀಕರಣ ಮತ್ತು ಸೈಫರ್ನೊಂದಿಗೆ ESP ಗೆ ಹೊಂದಿಸಿ ಮತ್ತು ಅಲ್ಗಾರಿದಮ್ ಮಾತುಕತೆ ನಡೆಸಲು ಬಿಡಿ, ನಂತರ combined mode ಎಂಬಂತಹ ಹೆಸರಿನ ವೆಂಡರ್ ಚೆಕ್ಬಾಕ್ಸ್ ಕೆಳಗಿನಿಂದ ಸದ್ದಿಲ್ಲದೆ AH ಪ್ರಸ್ತಾವನೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ನ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ದೃಢೀಕರಿಸಿ

ಗೇಟ್ವೇ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಖಾಸಗಿ ಶ್ರೇಣಿಗಳಲ್ಲಿರಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ಬ್ಲಾಕ್ನಲ್ಲಿ ಸಂಖ್ಯೆ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್, ಉದಾಹರಣೆಗೆ 111.x ನಿಂದ ಪ್ರಾರಂಭವಾಗುವಂತಹದ್ದು, ಸುರಂಗವನ್ನು ಎತ್ತಬಹುದು ಆದರೆ Azure ಆ ಸ್ಥಳವನ್ನು ಒಳಗಿನದೆಂದು ಪರಿಗಣಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಹರಿವು ಸ್ವೀಕರಿಸಲ್ಪಡುವುದಿಲ್ಲ. ಆಯ್ಕೆಗಾರರ ಮೇಲೆ ಮಧ್ಯಾಹ್ನ ವ್ಯರ್ಥ ಮಾಡುವ ಮೊದಲು ವಿಳಾಸ ಸ್ಥಳವನ್ನು ದೃಢೀಕರಿಸಿ. ಸಂಖ್ಯೆಯು ಹಳೆಯ ಹಂಚಿಕೆಯಿಂದ ಬಂದ ಕಠಿಣ ಅಗತ್ಯವಾಗಿದ್ದರೆ, ಪರಿಹಾರ ಬೇರೆ ಗೇಟ್ವೇ ಅಲ್ಲ, ವಿಳಾಸ ಯೋಜನೆಯನ್ನು ಬದಲಿಸುವುದು.

ವಿಳಾಸ ಸ್ಥಳ ಬ್ಲೇಡ್ನಲ್ಲಿರುವಾಗಲೇ ಆನ್-ಪ್ರಿಮೈಸ್ ಶ್ರೇಣಿಗಳೊಂದಿಗಿನ ಅತಿಕ್ರಮಣವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಅತಿಕ್ರಮಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಕ್ಲೈಂಟ್ನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಬೇರೆ ರೀತಿಯ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.

ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

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

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

ping ಅಲ್ಲ, ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ಪೀರ್ ಪ್ರಸ್ತಾವನೆ, ಎರಡೂ ವಿಳಾಸ ಸ್ಥಳಗಳು ಮತ್ತು ಸಂಪರ್ಕ ರಚಿಸಿದ ಸಮಯವನ್ನು ಟಿಕೆಟ್ನಲ್ಲಿ ಬರೆಯಿರಿ, ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಯಾವ ಮೌಲ್ಯಗಳನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸಲಾಯಿತು ಮತ್ತು ಯಾವುದನ್ನು ಎಂದಿಗೂ ಮುಟ್ಟಲಿಲ್ಲ ಎಂದು ತಿಳಿಯಲು.

ಲಾಗ್ ಖಾಲಿಯಾಗಿ ಹಿಂತಿರುಗಿದರೆ, ಗೇಟ್ವೇ ನಿಮ್ಮ ಸಂಪರ್ಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕೊನೆಗೊಳಿಸುತ್ತಿಲ್ಲದಿರಬಹುದು. ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಗೇಟ್ವೇಯಲ್ಲಿನ ಪೀರ್ ವಿಳಾಸವು ನೀವು ಲಾಗ್ ಓದುತ್ತಿರುವ ಸಾಧನಕ್ಕೆ ಹೊಂದುತ್ತದೆಯೇ ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಒಂದೇ ಚಂದಾದಾರಿಕೆಯಲ್ಲಿ ಎರಡು ಗೇಟ್ವೇಗಳನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುವಾಗ ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭ. ಆ ತಪ್ಪು ಒಂದು ದಿನ ವೆಚ್ಚ ಮಾಡಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಲಾಗ್ನಲ್ಲಿ ಗುರುತು ಬಿಡುವುದಿಲ್ಲ.