Cloud VPN স্ট্যাটাস: IKE লগের আগে রিসোর্সের অবস্থা পড়ুন

একটি Cloud VPN টানেল একসঙ্গে দুটি জীবনচক্র চালায়, আর সেগুলো একই ঘড়িতে নেই। রিসোর্সটি আগে বরাদ্দ ও কনফিগার হতে হয়, তারপরই এটি আলোচনা করতে পারে, আর প্রোটোকলের এরপর IKE বার্তার নিজস্ব ক্রম আছে। একটি স্ট্যাটাস ফিল্ড প্রথমটি জানাতে পারে, অথচ দ্বিতীয়টি সম্পর্কে কোনো কাজের কথা বলে না। দুটিকে এক জিনিস হিসেবে পড়াই হলো একটি কী-মিলহীনতাকে প্রভিশনিং বিলম্বের দোষ দেওয়ার উপায়।

একটি টানেল অবজেক্ট ও একটি সময়-জানালা দিয়ে শুরু করুন।

দুটি জীবনচক্র, একটি টানেল অবজেক্ট

রিসোর্স জীবনচক্র হলো প্রোভাইডারের টানেল প্রস্তুত করা: ঠিকানা, কনফিগারেশন, ধারণক্ষমতা। প্রোটোকল জীবনচক্র শুরু হয় যখন দুই পিয়ারের কাছে IKE_SA_INIT, তারপর IKE_AUTH, তারপর চাইল্ড সিকিউরিটি অ্যাসোসিয়েশন বিনিময়ের যথেষ্ট কনফিগারেশন থাকে। যে টানেল এখনো প্রথম পর্যায়ে আছে সেটি প্রমাণীকরণে ব্যর্থ হয়নি, কারণ প্রমাণীকরণ এখনো চেষ্টা করা হয়নি।

এই পার্থক্যটাই পুরো সমস্যা। বাকি সবকিছু হলো অসংশ্লিষ্ট বার্তা মিলিয়ে না দিয়ে এটি কীভাবে পর্যবেক্ষণ করা যায়।

অবজেক্টটি পড়ুন, কনসোলের সারসংক্ষেপ নয়

API-এর কাছে শুধু সেই দুটি ফিল্ড চান যেগুলো গুরুত্বপূর্ণ, আর কিছু নয়, যাতে উত্তরটি রাত তিনটায় পড়ার মতো যথেষ্ট ছোট থাকে: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status ফিল্ডটি জীবনচক্রের পর্যায়ের নাম বলে, আর detailedStatus তার সঙ্গে যুক্ত পাঠযোগ্য কারণ বহন করে। সম্পূর্ণ কনফিগারেশন ডাম্প অন্য প্রশ্নের উত্তর দেয় এবং টিকিটে পেস্ট করা কঠিন। এ ধরনের শুধু-পড়ার কল টানেল বদলাতে পারে না, যেটি ঘটনা এখনো চলমান থাকার সময় গুরুত্বপূর্ণ।

কলে করা সময়ের টাইমস্ট্যাম্প মানগুলোর পাশে লিখুন, কারণ দুটি ফিল্ডই বদলায়।

ALLOCATING_RESOURCES কোনো কী-মিলহীনতা নয়

যখন টানেল ALLOCATING_RESOURCES জানায়, প্রোভাইডার তখনো অবজেক্টটি জোড়া লাগাচ্ছে। ওই পর্যায়ে পূর্ব-শেয়ার করা কী-এর মিলহীনতা পর্যবেক্ষণ করা যায় না, আর পিয়ারের বন্ধ পোর্টও সমানভাবে অপ্রমাণিত। যা আপনি যাচাই করতে পারেন তা হলো বিস্তারিত বার্তা, প্রকল্প ও পরিষেবা সুস্থ দেখাচ্ছে কি না, এবং টানেল কনফিগারেশনটি পিয়ারের সঙ্গে আদৌ যোগাযোগের জন্য যথেষ্ট সম্পূর্ণ কি না। এখন গোপনটি বদলালে এমন একটি মান বদলায় যা কখনো পরীক্ষা করা হয়নি।

কনফিগারেশন সম্পর্কে সিদ্ধান্তে আসার আগে অবস্থার পরিবর্তনের জন্য অপেক্ষা করুন।

ESTABLISHED হলো অ্যাক্সেস যাচাইয়ের শুরু

প্রতিষ্ঠিত টানেল মানে IKE সম্পন্ন হয়েছে, ট্রাফিক বইছে নয়। টানেল যে রুটগুলো বহন করে তা নিশ্চিত করুন এবং যেখানে Cloud Router জড়িত, BGP সেশন ও এটি যে প্রিফিক্স শিখেছে তা নিশ্চিত করুন। তারপর একটি অনুমোদিত অ্যাপ্লিকেশন বিনিময় পরীক্ষা করুন, কারণ একটি ফায়ারওয়াল নিয়ম বা অনুপস্থিত রুট সম্পূর্ণ সুস্থ টানেলের মধ্য দিয়ে ট্রাফিক আটকে দিতে পারে। এগুলোর প্রতিটি আলাদা পর্যবেক্ষণ, আলাদা সমাধান।

স্ট্যাটাস আপনাকে বলে এরপর কোন প্রশ্নটি করতে হবে। এটি কখনো আপনার হয়ে অ্যাক্সেসের প্রশ্নের উত্তর দেয় না।

একটি অবজেক্ট ও একটি সময়-জানালা মিলিয়ে দেখুন

লগে থাকা পুরোনো প্রমাণীকরণ ব্যর্থতা আগের একটি চেষ্টার, যদি না তার টাইমস্ট্যাম্প আপনি যে জানালা তদন্ত করছেন তার ভিতরে পড়ে। আপনি যে স্ট্যাটাস লিখেছেন তার একই মিনিটগুলোর জন্য টানেল রিসোর্সের লগ টানুন, আর শনাক্তকারীগুলো একসঙ্গে রাখুন। পরের কোনো IKE ঘটনা দেখাতে পারে আলোচনা শুরু হয়েছে, অথচ আপনি যে কনসোল বার্তার দিকে তাকিয়ে আছেন সেটি ইতিমধ্যে পুরোনো।

কিছু সংগ্রহের আগেই টানেল সেরে উঠলে তা বলে দিন। অনির্ধারিত কারণ অসংশ্লিষ্ট লাইন জোড়া দিয়ে বানানো আত্মবিশ্বাসী গল্পের চেয়ে ভালো রেকর্ড।

পরের পদক্ষেপের আকৃতি সবসময় একই: একটি অবজেক্ট, একটি জানালা, একটি পর্যায়। এর চেয়ে প্রশস্ত কিছু সারসংক্ষেপ, রোগনির্ণয় নয়।