GCE VPN परिवर्तन गर्नु अघि सिरियल रिकभरी मार्ग तयार गर्नुहोस्

एउटै इन्टरफेसमा दोस्रो SSH विन्डो रिकभरी मार्ग होइन। यसले तपाईंले परिवर्तन गर्न लागेको रुट, फायरवाल नियम र डेमन साझा गर्छ, त्यसैले तपाईंलाई यसको आवश्यकता पर्ने ठीक त्यही क्षणमा यो असफल हुन्छ। Compute Engine VM मा VPN रुट सम्पादन गर्नु अघि तीन अलग कुरा प्रमाणित गर्नुहोस्: तपाईं सिरियल कन्सोल प्रयोग गर्न सक्नुहुन्छ, यसको आउटपुट पढ्न सक्नुहुन्छ, र अतिथिले तपाईंलाई साँच्चै लगइन दिन्छ। तलका जाँचहरू त्यही क्रममा, सबैभन्दा सस्तो पहिले चल्छन्, ताकि हराएको अनुमति महत्त्वपूर्ण हुनु अघि पत्ता लागोस्।

चरण 1: क्लाउड-पक्षीय अनुमति पुष्टि गर्नुहोस्

ठ्याक्कै VM, परियोजना र क्षेत्रको नाम दिनुहोस्, त्यसपछि संस्थाको स्वीकृत सिरियल-पहुँच नीति जाँच्नुहोस्। प्रशासकलाई सम्बन्धित अनुमति चाहिन्छ, र लागू परियोजना तथा संस्था नियन्त्रणअन्तर्गत त्यो इन्स्ट्यान्सका लागि अन्तरक्रियात्मक सिरियल पहुँच सक्षम हुनुपर्छ।

एउटा मेसिन तयार गर्न संस्थाको नीति कमजोर बनाउनु वा पूरै परियोजनामा कन्सोल पहुँच खोल्नु हुँदैन। प्रयोगअघि नै स्वीकृत संयन्त्र मिलाउन मालिकलाई भन्नुहोस्, अवरोधको समयमा होइन।

चरण 2: तपाईं आउटपुट पढ्न सक्नुहुन्छ भनी प्रमाणित गर्नुहोस्

सिरियल आउटपुट पढ्नु सबैभन्दा सस्तो जाँच हो, र यसले अतिथिको लगइन नछोई ढुवानीको अभ्यास गराउँछ:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

पहिचानकर्ताहरू बदल्नुहोस् र स्वीकृत पोर्ट प्रयोग गर्नुहोस्। बुट सन्देश र कन्सोलको गफले च्यानल काम गरिरहेको बताउँछ। तिनीहरूले तपाईं shell पाउन सक्नुहुन्छ भनी प्रमाणित गर्दैनन्। त्यसैले यो चरण अर्कोबाट अलग छ।

चरण 3: तपाईं अन्तरक्रियात्मक लगइन पाउन सक्नुहुन्छ भनी प्रमाणित गर्नुहोस्

जडान आदेशले पूर्वावलोकन होइन, वास्तविक सत्र खोल्छ:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

यसलाई जीवित कन्सोल मान्नुहोस्। प्रमाणहरू टाइप गर्नु अघि अन्त्य बिन्दु पुष्टि गर्नुहोस्, किनकि हरेक किस्ट्रोक इन्स्ट्यान्समा पर्छ।

यहीँ पूरा देखिने योजना भत्किन्छ। क्लाउड अनुमति एउटा सीमा हो र Linux लगइन प्रम्प्ट अर्को, र पहिलो पार गर्नाले दोस्रोबारे केही भन्दैन।

चरण 4: अतिथिले स्वीकार गर्ने प्रमाणहरू तयार गर्नुहोस्

Google ले दिने Linux इमेजहरूले पूर्वनिर्धारित रूपमा स्थानीय पासवर्ड-आधारित लगइन सक्षम गर्दैनन्। त्यसैले सिरियल सत्र लगइन प्रम्प्टसम्म पुगेर त्यहीँ रोकिन सक्छ, कसैले सेट नगरेको प्रमाणको प्रतीक्षामा।

स्वीकृत रिकभरी खाता, वा तपाईंको परिनियोजनले प्रयोग गर्ने कुनै पनि अभिलेखित अतिथि-लगइन विधि, अवस्थित हुनुपर्छ र परीक्षण गरिएको हुनुपर्छ। नेटवर्कमा काम गर्ने SSH कुञ्जीले स्वचालित रूपमा कन्सोल पासवर्ड प्रम्प्ट पूरा गर्दैन, त्यसैले यो अवस्था समेट्छ भनी मान्नुको सट्टा वास्तविक OS Login र कुञ्जी व्यवस्था जाँच्नुहोस्।

रिकभरी प्रमाणहरू निजी राख्नुहोस्। सार्वजनिक startup-script उदाहरणमा टाँसिएको root पासवर्ड हुन बाँकी दोस्रो घटना हो।

चरण 5: मालिक र रोलब्याक अभिलेख गर्नुहोस्

केही पनि परिवर्तन गर्नु अघि कार्यरत नेटवर्क कन्फिगरेसन सुरक्षित राख्नुहोस् र यसलाई कसले व्यवस्थापन गर्छ, कुन VPN सेवा संलग्न छ र रोलब्याक कसरी गरिन्छ लेख्नुहोस्। कार्यरत सत्रबाट वर्तमान रुट, नियम र सेवाको स्थिति कब्जा गर्नुहोस्।

त्यही अभिलेखले रिकभरी च्यानललाई मर्मतमा बदल्छ, किनकि कन्सोलले तपाईंलाई प्रम्प्ट मात्र दिन्छ। यसलाई परिवर्तन अघि लेख्नुहोस्, पछि सम्झनाबाट होइन। विकिबाट प्रतिलिपि गरिएको रोलब्याक रोलब्याक होइन। यो संस्करण नम्बर भएको अनुमान हो।

चरण 6: परिवर्तनपछि प्रमाणित गर्नुहोस्

अवस्थित SSH सत्र नयाँलाई रोक्ने नीतिबाट पनि बाँच्न सक्छ, त्यसैले नयाँ सामान्य प्रशासनिक सत्रले परीक्षण गर्नुहोस्। त्यसपछि तपाईंले परिवर्तन गरेको VPN व्यवहार अलगै परीक्षण गर्नुहोस्।

दुवै जाँच पास नहुँदासम्म रिकभरी च्यानल खुला राख्नुहोस्, र त्यसपछि पहुँच नीतिअनुसार बन्द गर्नुहोस्। यदि SSH पहिले नै गुमिसकेको छ र कुनै कन्सोल लगइन तयार गरिएको छैन भने, सिरियल पहुँचलाई सुरक्षा जाल मान्न छोड्नुहोस् र स्वीकृत खाता-रिकभरी वा इन्स्ट्यान्स-मर्मत कार्यप्रवाह सुरु गर्नुहोस्। अर्को VM लाई jump host का रूपमा उभ्याउनाले अतिथिको मार्ग वा हराएका प्रमाणमध्ये केही पनि मर्मत गर्दैन।