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 म्हणून उभे करणे गेस्टचा मार्ग किंवा गहाळ क्रेडेन्शियल्स यापैकी काहीही दुरुस्त करत नाही.