GCE VPN ફેરફાર પહેલાં સિરિયલ રિકવરી માર્ગ તૈયાર કરો

એ જ ઇન્ટરફેસ પરની બીજી SSH વિન્ડો રિકવરી માર્ગ નથી. તે તમે બદલવા જઈ રહ્યા છો તે રૂટ, ફાયરવૉલ નિયમ અને ડિમન વહેંચે છે, તેથી તે બરાબર તે જ ક્ષણે નિષ્ફળ જાય છે જ્યારે તમને તેની જરૂર હોય. 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 તરીકે ઊભી કરવાથી ન તો ગેસ્ટનો માર્ગ સુધરે છે ન તો ખૂટતા ઓળખપત્રો.