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 घटनाले वार्ता सुरु भएको देखाउन सक्छ, जबकि तपाईं हेरिरहनुभएको कन्सोल सन्देश पहिले नै पुरानो भइसकेको हुन्छ।

यदि तपाईंले केही संकलन गर्नुअघि नै टनेल सुधारियो भने, त्यो भन्नुहोस्। अनिर्धारित कारण असम्बन्धित लाइनहरूबाट बनेको आत्मविश्वासी कथाभन्दा राम्रो अभिलेख हो।

अर्को कदम सधैं एउटै आकारको हुन्छ: एउटा वस्तु, एउटा विन्डो, एउटा चरण। यसभन्दा फराकिलो जे पनि सारांश हो, निदान होइन।