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 घटना बोलणी सुरू झाल्याचे दाखवू शकते, तर तुम्ही पाहत असलेला कन्सोल संदेश आधीच जुना झालेला असतो.

तुम्ही काही गोळा करण्यापूर्वी टनेल बरे झाले, तर तसे सांगा. अनिर्धारित कारण असंबद्ध ओळींनी बनवलेल्या आत्मविश्वासू कथेपेक्षा चांगली नोंद आहे.

पुढचे पाऊल नेहमी एकाच आकाराचे असते: एक ऑब्जेक्ट, एक विंडो, एक टप्पा. यापेक्षा रुंद काहीही सारांश आहे, निदान नाही.