কেন Client VPN সার্টিফিকেট পুনরায় আমদানি করতে নতুন এন্ডপয়েন্ট প্রয়োজন

একটি Client VPN সংযোগ ভেঙে যায়, ACM-এর সার্টিফিকেট প্রতিস্থাপিত হয়, আর কিছুই বদলায় না। সার্টিফিকেট অবজেক্টটি কখনোই সেই জিনিস ছিল না যা এন্ডপয়েন্ট ব্যবহার করছিল। এন্ডপয়েন্ট তৈরি হওয়ার সময় একটি সার্টিফিকেটের সঙ্গে সংযোগ সংরক্ষণ করে, সঙ্গে যে ক্লায়েন্ট CA-এর বিপরীতে যাচাই করবে, প্রমাণীকরণের ধরন, সাবনেটগুলো এবং অনুমোদন নিয়মগুলো — আর এই সংযোগগুলোর কোনোটিতেই প্রতিস্থাপন সার্টিফিকেট গ্রহণ করে এমন পরিবর্তন কল নেই। ARN-এর পেছনের বাইট প্রতিস্থাপন করা সার্টিফিকেটের পরিবর্তন, যে এন্ডপয়েন্ট এটি ধরেছিল তার নয়।

এন্ডপয়েন্ট সার্টিফিকেট নয়, রেফারেন্স সংরক্ষণ করে

মেকানিজমটি নির্ভুলভাবে বলা দরকার, কারণ এটি পুরো ব্যর্থতাটাই ব্যাখ্যা করে। create-client-vpn-endpoint সার্ভার সার্টিফিকেট ARN ও ক্লায়েন্ট রুট সার্টিফিকেট চেইন ARN নেয়, এবং ফলস্বরূপ এন্ডপয়েন্ট সেই রেফারেন্সগুলো প্রমাণীকরণ অপশনসহ স্থির বৈশিষ্ট্য হিসেবে রাখে। API-তে এমন কোনো অপারেশন নেই যা বিদ্যমান এন্ডপয়েন্টে সার্ভার সার্টিফিকেট বদলায়।

অনুমান না করেই বাইন্ডিংটি যাচাই করতে পারেন। aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 সার্টিফিকেট ARN, ক্লায়েন্ট রুট চেইন ARN, প্রমাণীকরণের ধরন, ক্লায়েন্ট CIDR এবং সংশ্লিষ্ট সাবনেটগুলো প্রিন্ট করে — যা আপনাকে পুনরুৎপাদন করতে হবে সেই বৈশিষ্ট্যের সম্পূর্ণ সেট। পুনরায় আমদানির আগে ও পরে এটি চালান, আউটপুট নড়বে না। এটাই প্রমাণ যে পুনরায় আমদানি কখনোই সাহায্য করত না।

কেন পুনরায় আমদানি এন্ডপয়েন্ট পর্যন্ত পৌঁছাতে পারে না

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

এই কারণেই উপসর্গটি নেটওয়ার্ক ত্রুটির মতো শোনায়। অনুমোদন কখনো মূল্যায়িত হওয়ার আগেই TLS হ্যান্ডশেক ব্যর্থ হয় বা রিসেট হয়, তাই সিকিউরিটি গ্রুপ, রুট ও অনুমোদন নিয়ম সবই নির্দোষ দেখায় — এবং তারা নির্দোষই।

চেইনটি ক্লায়েন্ট সার্টিফিকেটের অংশ

ব্যর্থতার দ্বিতীয় অর্ধেকটি ক্লায়েন্ট সার্টিফিকেটে, এবং এটি এড়িয়ে যাওয়া সহজ। ক্লায়েন্ট সার্টিফিকেট অবশ্যই যে চেইন এটি ইস্যু করেছে তার সঙ্গে আমদানি করতে হবে, যদিও আমদানি ফর্মটি ওই ফিল্ডকে ঐচ্ছিক হিসেবে দেখায়। চেইন ছাড়া এন্ডপয়েন্ট ক্লায়েন্ট সার্টিফিকেট থেকে যে ক্লায়েন্ট রুট CA দিয়ে এটি কনফিগার হয়েছিল সেখানে পথ তৈরি করতে পারে না, এবং সংযোগটি নরম রিসেটে শেষ হয় যা প্যাকেট ফেলে দেওয়া ফায়ারওয়ালের মতো শোনায়। openssl verify -CAfile root-ca.pem client.crt সেই প্রশ্নের উত্তর লোকালি এক সেকেন্ডে দেয়, এবং এটিই আপনার চালানো প্রথম কমান্ড হওয়া উচিত।

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

এন্ডপয়েন্ট পুনর্নির্মাণ একটি মাইগ্রেশন

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

এটি নিরাপদ রাখার ক্রমটি ছোট: একই CIDR, সাবনেট ও অনুমোদন নিয়ম দিয়ে নতুন এন্ডপয়েন্ট তৈরি করুন, aws ec2 export-client-vpn-client-configuration দিয়ে নতুন প্রোফাইল এক্সপোর্ট করুন, এবং একজন ব্যবহারকারী দিয়ে যাচাই করুন। এরপরেই পুরোনো এন্ডপয়েন্ট নামানো হয়।

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

রোগনির্ণয়ের ক্রম সাজান

কোনো কনফিগারেশন বদলানোর আগে তিনটি ব্যর্থতা আলাদা করুন। ক্লায়েন্ট TLS সম্পূর্ণ করতে পারে না, ক্লায়েন্ট TLS সম্পূর্ণ করে কিন্তু অনুমোদিত নয়, অথবা ক্লায়েন্ট সংযোগ করে কিন্তু গন্তব্যে পৌঁছাতে পারে না। সার্টিফিকেট সংযোগ প্রথমটির, ক্লায়েন্ট ঠিকানা ঢেকে না রাখা অনুমোদন নিয়ম দ্বিতীয়টির, আর রুট বা সিকিউরিটি গ্রুপ তৃতীয়টির — যেখানে এন্ডপয়েন্ট পুনর্নির্মাণ প্রায় সবসময়ই ভুল পদক্ষেপ।

একটি এন্ডপয়েন্ট যা মাসের পর মাস কাজ করে তারপর থেমে গেছে, কোনো সার্টিফিকেট বা নীতির পরিবর্তন ছাড়াই, আলাদা ঘটনা। একই সেটিংসে এটি পুনর্নির্মাণ পরিষেবা ফিরিয়ে দিতে পারে, কিন্তু সেটি কনফিগারেশন পুনরুৎপাদনযোগ্য রাখার কারণ, প্রতিটি ঘটনায় পুনর্নির্মাণের কারণ নয়।

চারটি জিনিস সংস্করণ নিয়ন্ত্রণে রাখুন যাতে পরের পুনর্নির্মাণটি তাৎক্ষণিক উদ্ভাবন নয়, একটি diff হয়: এন্ডপয়েন্ট প্যারামিটার, সার্টিফিকেট ও চেইন ARN, অনুমোদন নিয়ম এবং ক্লায়েন্ট CIDR। Client VPN প্রমাণীকরণ ডকুমেন্টেশন বলে কোন সার্টিফিকেট কোন ভূমিকা পালন করে, আর সার্টিফিকেটকেই সমস্যা ধরে নেওয়ার আগে তা দেখা উচিত। যদি পুনরায় আমদানি কিছুই না বদলায় এবং এন্ডপয়েন্ট এখনো রিসেট হয়, তবে সন্দেহভাজন সংযোগটিই, এবং উত্তর হলো রেকর্ড করা প্যারামিটার থেকে নির্মিত নতুন এন্ডপয়েন্ট। যদি এন্ডপয়েন্ট সত্যিই নতুন অবজেক্টটি গ্রহণ করে, তবে সংযোগ আগেই সঠিক ছিল এবং ত্রুটি ক্লায়েন্ট চেইনে বা অনুমোদন স্তরে।