Припремите серијску путању опоравка пре промене 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-а не поправља ни пут госта ни акредитиве који недостају.