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 হিসেবে দাঁড় করানো গেস্টের পথ বা অনুপস্থিত শংসাপত্র কোনোটিই মেরামত করে না।