הכינו נתיב שחזור סריאלי לפני שינוי VPN ב-GCE

חלון SSH שני באותו ממשק אינו נתיב שחזור. הוא חולק את המסלול, את כלל חומת האש ואת הדמון שאתם עומדים לשנות, ולכן הוא נכשל בדיוק ברגע שבו אתם זקוקים לו. לפני עריכת מסלולי VPN במכונת Compute Engine, הוכיחו שלושה דברים נפרדים: שאתם רשאים להשתמש בקונסולה הסריאלית, שאתם יכולים לקרוא את הפלט שלה, ושהאורח אכן ייתן לכם התחברות. הבדיקות שלהלן מתבצעות בסדר הזה, הזולה ראשונה, כדי שהרשאה חסרה תתגלה לפני שהיא חשובה.

שלב 1: אשרו את ההרשאה בצד הענן

ציינו את המכונה, הפרויקט והאזור המדויקים, ואז בדקו את מדיניות הגישה הסריאלית שאושרה בארגון. למנהל המערכת נדרשת ההרשאה הרלוונטית, וגישה סריאלית אינטראקטיבית חייבת להיות מופעלת עבור אותה מכונה תחת בקרות הפרויקט והארגון החלות.

אל תחלישו מדיניות ארגונית ואל תפעילו גישה לקונסולה בכל הפרויקט כדי להכין מכונה אחת. בקשו מהבעלים לארגן את המנגנון המותר לפני הניסוי, לא בזמן התקלה.

שלב 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 כבר אבד ולא הוכנה התחברות קונסולה, הפסיקו להתייחס לגישה סריאלית כרשת ביטחון והתחילו את זרימת שחזור החשבון או תיקון המכונה המאושרת. הקמת מכונה נוספת כ jump host אינה מתקנת לא את נתיב האורח ולא את פרטי ההתחברות החסרים.