მოამზადეთ სერიული აღდგენის გზა GCE-ში VPN-ის შეცვლამდე

მეორე SSH ფანჯარა იმავე ინტერფეისზე არ არის აღდგენის გზა. ის იზიარებს მარშრუტს, firewall-ის წესს და დემონს, რომლის შეცვლასაც აპირებთ, ამიტომ ის ვარდება ზუსტად იმ მომენტში, როცა გჭირდებათ. 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-ად აწევა არც სტუმრის გზას არ არეგულირებს და არც დაკარგულ სერთიფიკატებს.