Падрыхтуйце шлях аварыйнага аднаўлення праз серыйную кансоль перад змяненнем 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 не рамантуе ні шлях госця, ні адсутныя ўліковыя даныя.