جهّز مسار استرداد تسلسلي قبل تغيير VPN على GCE

نافذة SSH ثانية على الواجهة نفسها ليست مسار استرداد. فهي تشترك في المسار وقاعدة جدار الحماية والخدمة الخفية التي أنت على وشك تغييرها، لذلك تفشل في اللحظة نفسها التي تحتاجها فيها. قبل تعديل مسارات VPN على جهاز Compute Engine افتراضي، أثبت ثلاثة أمور منفصلة: أنك تستطيع استخدام وحدة التحكم التسلسلية، وأنك تستطيع قراءة إخراجها، وأن الضيف سيمنحك تسجيل دخول فعليًا. تجري الفحوص أدناه بهذا الترتيب، من الأرخص أولًا، حتى يُكتشف الإذن الناقص قبل أن يصبح مهمًا.

الخطوة 1: تأكيد الإذن من جانب السحابة

حدّد الجهاز الافتراضي والمشروع والمنطقة بدقة، ثم تحقق من سياسة الوصول التسلسلي المعتمدة في المؤسسة. يحتاج المسؤول إلى الإذن ذي الصلة، ويجب تمكين الوصول التسلسلي التفاعلي لذلك المثيل ضمن ضوابط المشروع والمؤسسة السارية.

لا تضعف سياسة مؤسسة ولا تشغّل الوصول إلى وحدة التحكم على مستوى مشروع كامل لتجهيز جهاز واحد. اطلب من المالك ترتيب الآلية المسموح بها قبل التجربة، لا أثناء الانقطاع.

الخطوة 2: إثبات قدرتك على قراءة الإخراج

قراءة الإخراج التسلسلي هي الفحص الأرخص، وهي تختبر النقل دون مساس بتسجيل دخول الضيف:

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

استبدل المعرّفات واستخدم المنفذ المسموح به. تخبرك رسائل الإقلاع وثرثرة وحدة التحكم أن القناة تعمل. وهي لا تثبت أنك تستطيع الحصول على صدفة. لهذا السبب تُفصل هذه الخطوة عن التالية.

الخطوة 3: إثبات إمكانية الحصول على تسجيل دخول تفاعلي

يفتح أمر الاتصال جلسة حقيقية، لا معاينة:

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

تعامل معها كوحدة تحكم حية. تأكد من نقطة النهاية قبل كتابة بيانات الاعتماد، لأن كل ضغطة مفتاح تهبط على المثيل.

هنا ينهار خطط بدا كاملًا. إذن السحابة حدّ واحد ومطالبة تسجيل الدخول في Linux حدّ آخر، واجتياز الأول لا يقول شيئًا عن الثاني.

الخطوة 4: تجهيز بيانات اعتماد يقبلها الضيف

لا تمكّن صور Linux التي توفرها Google تسجيل الدخول المحلي بكلمة المرور افتراضيًا. لذلك قد تصل جلسة تسلسلية إلى مطالبة تسجيل الدخول وتتوقف هناك، في انتظار بيانات اعتماد لم يضبطها أحد.

يجب أن يوجد حساب استرداد معتمد، أو أي طريقة موثقة لتسجيل دخول الضيف يستخدمها نشرك، وأن يُختبر. مفتاح SSH يعمل عبر الشبكة لا يلبي تلقائيًا مطالبة كلمة مرور وحدة التحكم، لذا تحقق من ترتيب OS Login والمفاتيح الفعلي بدلًا من افتراض أنه يغطي هذه الحالة.

احتفظ ببيانات اعتماد الاسترداد خاصة. كلمة مرور root تُلصق في مثال startup-script عام هي حادثة ثانية تنتظر الحدوث.

الخطوة 5: تسجيل المالك وطريقة التراجع

قبل تغيير أي شيء، احفظ إعدادات الشبكة العاملة واكتب من يديرها وأي خدمة VPN معنية وكيف يُنفذ التراجع. من جلسة عاملة، التقط المسارات والقواعد وحالة الخدمة الحالية.

هذا السجل هو ما يحوّل قناة استرداد إلى إصلاح، لأن وحدة التحكم لا تمنحك سوى مطالبة. اكتبه قبل التغيير، لا من الذاكرة بعده. التراجع المنسوخ من ويكي ليس تراجعًا. إنه تخمين مع رقم إصدار.

الخطوة 6: التحقق بعد التغيير

يمكن لجلسة SSH قائمة أن تنجو من سياسة تحظر الجلسات الجديدة، لذا اختبر بجلسة إدارة عادية جديدة. ثم اختبر سلوك VPN الذي غيّرته، بشكل منفصل.

أبقِ قناة الاسترداد مفتوحة حتى ينجح الفحصان، ثم أغلقها وفق سياسة الوصول. إذا فُقد SSH بالفعل ولم تُجهّز أي عملية تسجيل دخول عبر وحدة التحكم، فتوقف عن اعتبار الوصول التسلسلي شبكة أمان وابدأ سير عمل استرداد الحساب أو إصلاح المثيل المعتمد. إنشاء جهاز افتراضي آخر كمضيف قفز لا يصلح مسار الضيف ولا بيانات الاعتماد الناقصة.