Подгответе път за серийно възстановяване преди промяна на 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 услуга участва и как се извършва връщане назад. От работеща сесия заснемете текущите маршрути, правила и състояние на услугата.

Точно този запис превръща канала за възстановяване в ремонт, защото конзолата ви дава само подкана. Запишете го преди промяната, а не по памет след това. Връщане назад, копирано от wiki, не е връщане назад. То е предположение с номер на версия.

Стъпка 6: проверете след промяната

Съществуваща SSH сесия може да преживее политика, която блокира нови, затова тествайте с нова нормална административна сесия. След това тествайте отделно VPN поведението, което сте променили.

Дръжте канала за възстановяване отворен, докато и двете проверки минат, и след това го затворете според политиката за достъп. Ако SSH вече е загубен и не е подготвен вход през конзолата, спрете да третирате серийния достъп като предпазна мрежа и започнете разрешения работен процес за възстановяване на акаунт или ремонт на екземпляра. Издигането на друга VM като jump host не поправя нито пътя на госта, нито липсващите идентификационни данни.