پیش از تغییر VPN در GCE یک مسیر بازیابی سریال آماده کنید

پنجره دوم SSH روی همان رابط، مسیر بازیابی نیست. این پنجره همان مسیر، همان قاعده فایروال و همان دیمنی را که می‌خواهید تغییر دهید به اشتراک می‌گذارد، پس دقیقاً در همان لحظه‌ای که به آن نیاز دارید از کار می‌افتد. پیش از ویرایش مسیرهای VPN روی یک VM در Compute Engine، سه چیز جداگانه را اثبات کنید: اینکه می‌توانید از کنسول سریال استفاده کنید، اینکه می‌توانید خروجی آن را بخوانید و اینکه مهمان واقعاً ورود به شما می‌دهد. بررسی‌های زیر به همین ترتیب، از ارزان‌ترین آغاز می‌شوند تا مجوز گمشده پیش از اهمیت یافتن کشف شود.

گام 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: اعتبارنامه‌هایی آماده کنید که مهمان بپذیرد

تصاویر Linux که Google ارائه می‌دهد به‌طور پیش‌فرض ورود محلی با گذرواژه را فعال نمی‌کنند. بنابراین یک نشست سریال می‌تواند به اعلان ورود برسد و همان‌جا بایستد و منتظر اعتبارنامه‌ای باشد که هیچ‌کس تنظیم نکرده است.

یک حساب بازیابی مصوب، یا هر روش مستند ورود مهمان که استقرار شما استفاده می‌کند، باید وجود داشته باشد و آزمایش شود. کلید SSH که روی شبکه کار می‌کند به‌طور خودکار اعلان گذرواژه کنسول را برآورده نمی‌کند، پس چیدمان واقعی OS Login و کلیدها را بررسی کنید نه اینکه فرض کنید این مورد را پوشش می‌دهد.

اعتبارنامه‌های بازیابی را خصوصی نگه دارید. گذرواژه root که در یک نمونه عمومی startup-script چسبانده می‌شود، حادثه دومی است که در انتظار رخ دادن است.

گام 5: مالک و بازگردانی را ثبت کنید

پیش از تغییر هر چیزی، پیکربندی شبکه سالم را حفظ کنید و بنویسید چه کسی آن را مدیریت می‌کند، کدام سرویس VPN دخیل است و بازگردانی چگونه انجام می‌شود. از یک نشست سالم، مسیرها، قواعد و وضعیت سرویس فعلی را ثبت کنید.

همین ثبت است که یک کانال بازیابی را به تعمیر تبدیل می‌کند، چون کنسول تنها یک اعلان به شما می‌دهد. آن را پیش از تغییر بنویسید، نه بعداً از حافظه. بازگردانی کپی‌شده از ویکی بازگردانی نیست. یک حدس با شماره نسخه است.

گام 6: پس از تغییر بررسی کنید

یک نشست SSH موجود می‌تواند از سیاستی که نشست‌های جدید را مسدود می‌کند جان سالم به در ببرد، پس با یک نشست مدیریتی عادی تازه آزمایش کنید. سپس رفتار VPN را که تغییر داده‌اید جداگانه آزمایش کنید.

کانال بازیابی را تا زمانی که هر دو بررسی موفق شوند باز نگه دارید و سپس آن را طبق سیاست دسترسی ببندید. اگر SSH از قبل از دست رفته و هیچ ورود کنسولی آماده نشده است، دست از رفتار با دسترسی سریال به‌عنوان تور ایمنی بردارید و گردش‌کار مجاز بازیابی حساب یا تعمیر نمونه را آغاز کنید. بالا آوردن یک VM دیگر به‌عنوان jump host نه مسیر مهمان را تعمیر می‌کند و نه اعتبارنامه‌های گمشده را.