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 کے طور پر کھڑا کرنا نہ مہمان کا راستہ ٹھیک کرتا ہے نہ غائب اسناد۔