Сол интерфейстегі екінші 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 ретінде көтеру қонақ жолын да, жетіспейтін тіркелгі деректерін де жөндемейді.

Қатысты мақалалар