Cloud VPN ಸ್ಥಿತಿ: IKE ಲಾಗ್‌ಗಿಂತ ಮೊದಲು ಸಂಪನ್ಮೂಲದ ಸ್ಥಿತಿಯನ್ನು ಓದಿ

Cloud VPN ಟನೆಲ್ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ಜೀವನಚಕ್ರಗಳನ್ನು ನಡೆಸುತ್ತದೆ, ಮತ್ತು ಅವು ಒಂದೇ ಗಡಿಯಾರದ ಮೇಲಿಲ್ಲ. ಸಂಪನ್ಮೂಲವು ಮಾತುಕತೆ ನಡೆಸಲು ಮೊದಲು ಹಂಚಿಕೆಯಾಗಿ ಸಂರಚಿಸಲ್ಪಡಬೇಕು, ಮತ್ತು ನಂತರ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಅದರದೇ ಆದ IKE ಸಂದೇಶಗಳ ಕ್ರಮವಿದೆ. ಸ್ಥಿತಿ ಕ್ಷೇತ್ರವು ಮೊದಲನೆಯದನ್ನು ವರದಿ ಮಾಡಬಹುದು, ಆದರೆ ಎರಡನೆಯದರ ಬಗ್ಗೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಹೇಳದೇ ಇರಬಹುದು. ಅವನ್ನು ಒಂದೇ ವಸ್ತುವಾಗಿ ಓದುವುದು ಕೀ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವುದಕ್ಕೆ ಪೂರೈಕೆ ವಿಳಂಬದ ಆರೋಪ ಬರುವ ರೀತಿ.

ಒಂದು ಟನೆಲ್ ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಒಂದು ಸಮಯ-ವಿಂಡೋದಿಂದ ಪ್ರಾರಂಭಿಸಿ.

ಎರಡು ಜೀವನಚಕ್ರಗಳು, ಒಂದು ಟನೆಲ್ ಆಬ್ಜೆಕ್ಟ್

ಸಂಪನ್ಮೂಲದ ಜೀವನಚಕ್ರ ಎಂದರೆ ಪೂರೈಕೆದಾರರು ಟನೆಲ್ ಸಿದ್ಧಪಡಿಸುವುದು: ವಿಳಾಸಗಳು, ಸಂರಚನೆ, ಸಾಮರ್ಥ್ಯ. ಪ್ರೋಟೋಕಾಲ್‌ನ ಜೀವನಚಕ್ರವು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ IKE_SA_INIT, ನಂತರ IKE_AUTH, ನಂತರ ಚೈಲ್ಡ್ ಭದ್ರತಾ ಸಂಘಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಲು ಸಾಕಷ್ಟು ಸಂರಚನೆ ಇದ್ದಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಮೊದಲ ಹಂತದಲ್ಲಿರುವ ಟನೆಲ್ ದೃಢೀಕರಣದಲ್ಲಿ ವಿಫಲವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ದೃಢೀಕರಣವನ್ನು ಇನ್ನೂ ಪ್ರಯತ್ನಿಸಿಲ್ಲ.

ಆ ವ್ಯತ್ಯಾಸವೇ ಇಡೀ ಸಮಸ್ಯೆ. ಉಳಿದದ್ದೆಲ್ಲಾ ಸಂಬಂಧವಿಲ್ಲದ ಸಂದೇಶಗಳನ್ನು ಸೇರಿಸದೆ ಅದನ್ನು ಗಮನಿಸುವ ಬಗ್ಗೆ.

ಆಬ್ಜೆಕ್ಟ್ ಓದಿ, ಕನ್ಸೋಲ್ ಸಾರಾಂಶವಲ್ಲ

API ಗೆ ಮುಖ್ಯವಾದ ಎರಡು ಕ್ಷೇತ್ರಗಳನ್ನು ಮಾತ್ರ ಕೇಳಿ, ಬೇರೆ ಏನೂ ಬೇಡ, ಆಗ ಉತ್ತರ ರಾತ್ರಿ ಮೂರು ಗಂಟೆಗೆ ಓದಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status ಕ್ಷೇತ್ರವು ಜೀವನಚಕ್ರದ ಹಂತವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು detailedStatus ಅದಕ್ಕೆ ಸೇರಿದ ಓದಬಹುದಾದ ಕಾರಣವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ಪೂರ್ಣ ಸಂರಚನೆ ಡಂಪ್ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಟಿಕೆಟ್‌ಗೆ ಅಂಟಿಸಲು ಕಷ್ಟ. ಇಂತಹ ಓದಲು-ಮಾತ್ರ ಕರೆಗಳು ಟನೆಲ್ ಅನ್ನು ಬದಲಿಸಲಾರವು, ಇದು ಘಟನೆ ಇನ್ನೂ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಮುಖ್ಯ.

ಕರೆಯ ಸಮಯಮುದ್ರೆಯನ್ನು ಮೌಲ್ಯಗಳ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ಕ್ಷೇತ್ರಗಳು ಚಲಿಸುತ್ತವೆ.

ALLOCATING_RESOURCES ಕೀ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವುದಲ್ಲ

ಟನೆಲ್ ALLOCATING_RESOURCES ವರದಿ ಮಾಡಿದಾಗ, ಪೂರೈಕೆದಾರರು ಇನ್ನೂ ಆಬ್ಜೆಕ್ಟ್ ಜೋಡಿಸುತ್ತಿದ್ದಾರೆ. ಆ ಹಂತದಲ್ಲಿ ಮೊದಲೇ ಹಂಚಿದ ಕೀಯ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವುದನ್ನು ಗಮನಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ತಡೆಹಿಡಿದ ಪೀರ್ ಪೋರ್ಟ್ ಕೂಡ ಅಷ್ಟೇ ಅಪ್ರಮಾಣಿತ. ನೀವು ಪರಿಶೀಲಿಸಬಹುದಾದದ್ದು ವಿವರವಾದ ಸಂದೇಶ, ಯೋಜನೆ ಮತ್ತು ಸೇವೆ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತವೆಯೇ, ಮತ್ತು ಪೀರ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಲು ಟನೆಲ್ ಸಂರಚನೆ ಸಾಕಷ್ಟು ಪೂರ್ಣವಾಗಿದೆಯೇ ಎಂಬುದು. ಈಗ ರಹಸ್ಯವನ್ನು ಬದಲಾಯಿಸುವುದು ಎಂದಿಗೂ ಪರೀಕ್ಷಿಸದ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

ಸಂರಚನೆಯ ಬಗ್ಗೆ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ಸ್ಥಿತಿ ಚಲಿಸುವವರೆಗೆ ಕಾಯಿರಿ.

ESTABLISHED ಪ್ರವೇಶ ಪರಿಶೀಲನೆಗಳ ಪ್ರಾರಂಭ

ಸ್ಥಾಪಿತ ಟನೆಲ್ ಎಂದರೆ IKE ಪೂರ್ಣಗೊಂಡಿತು, ಸಂಚಾರ ಹರಿಯುತ್ತಿದೆ ಎಂದಲ್ಲ. ಟನೆಲ್ ಹೊತ್ತೊಯ್ಯುವ ಮಾರ್ಗಗಳನ್ನು ದೃಢೀಕರಿಸಿ ಮತ್ತು Cloud Router ಒಳಗೊಂಡಿರುವಲ್ಲಿ BGP ಅಧಿವೇಶನ ಮತ್ತು ಅದು ಕಲಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ದೃಢೀಕರಿಸಿ. ನಂತರ ಅನುಮತಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್ ವಿನಿಮಯವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಅಥವಾ ಕಾಣೆಯಾದ ಮಾರ್ಗವು ಸಂಪೂರ್ಣ ಆರೋಗ್ಯಕರ ಟನೆಲ್ ಮೂಲಕ ಸಂಚಾರವನ್ನು ತಡೆಯಬಹುದು. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಪ್ರತ್ಯೇಕ ವೀಕ್ಷಣೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಪರಿಹಾರ.

ಸ್ಥಿತಿ ಮುಂದೆ ಯಾವ ಪ್ರಶ್ನೆ ಕೇಳಬೇಕೆಂದು ಹೇಳುತ್ತದೆ. ಅದು ನಿಮ್ಮ ಬದಲಿಗೆ ಪ್ರವೇಶದ ಪ್ರಶ್ನೆಗೆ ಎಂದಿಗೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ.

ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಒಂದು ಸಮಯ-ವಿಂಡೋವನ್ನು ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿ

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

ನೀವು ಏನನ್ನೂ ಸಂಗ್ರಹಿಸುವ ಮೊದಲೇ ಟನೆಲ್ ಚೇತರಿಸಿಕೊಂಡರೆ, ಹಾಗೆ ಹೇಳಿ. ಅನಿರ್ಧಾರಿತ ಕಾರಣವು ಸಂಬಂಧವಿಲ್ಲದ ಸಾಲುಗಳಿಂದ ಜೋಡಿಸಿದ ಆತ್ಮವಿಶ್ವಾಸದ ಕಥೆಗಿಂತ ಉತ್ತಮ ದಾಖಲೆ.

ಮುಂದಿನ ಹೆಜ್ಜೆ ಯಾವಾಗಲೂ ಒಂದೇ ಆಕಾರ: ಒಂದು ಆಬ್ಜೆಕ್ಟ್, ಒಂದು ವಿಂಡೋ, ಒಂದು ಹಂತ. ಇದಕ್ಕಿಂತ ಅಗಲವಾದದ್ದು ಸಾರಾಂಶ, ರೋಗನಿರ್ಣಯವಲ್ಲ.