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 के रूप में खड़ा करना न गेस्ट का रास्ता ठीक करता है न गायब क्रेडेंशियल।