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 घटना दिखा सकती है कि बातचीत शुरू हो गई है, जबकि आप जिस कंसोल संदेश को देख रहे हैं वह पहले ही पुराना हो चुका है।

अगर टनल कुछ इकट्ठा करने से पहले ही ठीक हो जाए, तो यह बताएँ। अनिर्धारित कारण असंबद्ध पंक्तियों से बनी आत्मविश्वासी कहानी से बेहतर रिकॉर्ड है।

अगला कदम हमेशा एक ही आकार का होता है: एक ऑब्जेक्ट, एक विंडो, एक चरण। इससे भी चौड़ा जो कुछ है वह सारांश है, निदान नहीं।