AWS Client VPN সংযুক্ত, তবুও EC2 সাড়া দেয় না

আমার ল্যাপটপ দেখাচ্ছিল সংযুক্ত। AWS Client VPN ক্লায়েন্ট তার সবুজ অবস্থা দেখাল, endpoint একটি সেশন লগ করল, তবুও আমি একটি প্রাইভেট সাবনেটে EC2 ইনস্ট্যান্সে MongoDB পোর্ট খুলতে পারলাম না। আপাতদৃষ্টিতে কিছুই ভাঙা ছিল না: সার্টিফিকেট বৈধ ছিল, প্রোফাইল কনসোল থেকে এসেছিল, আর টানেল ট্রাফিক বহন করছিল। ভুলটা আমারই ছিল, কারণ আমি সংযুক্ত-কে অনুমোদিত হিসেবে পড়ছিলাম।

লগইন ঠিক একটি প্রশ্নের উত্তর দেয়: এই পরিচয় কি একটি সেশন প্রতিষ্ঠা করতে পারে? এর পরের সবকিছু আলাদা নিয়মে ঠিক হয়, যারা আপনার সার্টিফিকেট কখনও দেখে না। যে সেশন প্রমাণীকরণ পাস করে আর যে প্যাকেট পৌঁছায় — এ দুটি আলাদা সাফল্য, এবং এদের মধ্যের ফাঁকেই বেশিরভাগ VPN চালু কিন্তু হোস্টে পৌঁছনো যায় না ধরনের অভিযোগ বাস করে।

নিচের পরীক্ষাগুলোই এখন আমি যে ক্রমে ব্যবহার করি।

একটি সংযুক্ত সেশন আসলে কী প্রমাণ করে

হ্যান্ডশেকের সময় endpoint ক্লায়েন্ট সার্টিফিকেট তার trust store-এর বিপরীতে যাচাই করে, অথবা SAML কনফিগার করা থাকলে ব্রাউজারকে আপনার identity provider-এ পাঠায়। সেটি পাস হলে ক্লায়েন্ট endpoint-এর ক্লায়েন্ট CIDR থেকে একটি ঠিকানা পায় এবং কনসোল সক্রিয় সংযোগ দেখায়। ওই বিনিময়ের কোনো পর্যায়েই জিজ্ঞাসা করা হয় না যে আপনি 10.0.4.17-এ 27017 পোর্টে পৌঁছাতে পারবেন কি না।

গন্তব্যের অনুমতি endpoint-এ আলাদা একটি বস্তু। প্রতিটি ফ্লো অনুমোদন নিয়মের সঙ্গে মেলানো হয়, এবং প্রতিটি নিয়ম একটি গন্তব্য CIDR-কে সেই গ্রুপের সঙ্গে জোড়া দেয় যাকে নিয়মটি দেওয়া হয়েছে। যখন কোনো নিয়মই গন্তব্য ঢেকে দেয় না, endpoint সেশনটি গ্রহণ করে এবং ট্রাফিক ফেলে দেয়। কোনো ব্যানার নেই, পুনঃসংযোগের লুপ নেই, ক্লায়েন্ট UI-তে প্রত্যাখ্যাত বলে কিছু নেই।

অনুমোদন নিয়মটি VPC-র সঙ্গে নয়, রিসোর্সের সঙ্গে মেলান

নিয়মগুলো তালিকাভুক্ত করুন এবং ইনস্ট্যান্সের প্রকৃত ঠিকানার পাশে রাখুন:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

আউটপুট প্রতি নিয়মে একটি গন্তব্য CIDR এবং একটি গ্রুপ আইডি দেখায়। এর মধ্যে দুটি ব্যর্থতা লুকিয়ে থাকে। নিয়মটি 10.0.0.0/16 অনুমোদন করতে পারে, অথচ ইনস্ট্যান্সটি 10.1.0.0/16-এর পিয়ার করা VPC-তে আছে; পিয়ারিং রুট আছে, কিন্তু দ্বিতীয় রেঞ্জের জন্য কেউ অনুমোদন নিয়ম লেখেনি। অথবা নিয়মটি এমন একটি ডিরেক্টরি গ্রুপের দিকে ইঙ্গিত করে যেখানে ব্যবহারকারী ডিরেক্টরিতে যোগ দেয়, কিন্তু endpoint যে গ্রুপ মূল্যায়ন করে সেখানে নয়।

গন্তব্য ঢেকে দেয় এমন সবচেয়ে সংকীর্ণ নিয়ম লিখুন, এবং দ্বিতীয় CIDR সত্যিই প্রয়োজন হলে তবেই দ্বিতীয় নিয়ম যোগ করুন। দ্রুত শুরু থেকে আসা বিস্তৃত 0.0.0.0/0 নিয়ম কাজ করে, তাই-ই এটি প্রোডাকশন পর্যন্ত টিকে থাকে এবং মডেলটিকে লুকিয়ে রাখে।

দুটি রুট টেবিল ঠিক করে প্যাকেট এগোবে কি না

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

এমন রুট খুঁজুন যার গন্তব্য রিসোর্স CIDR-এর সঙ্গে মেলে এবং যার টার্গেট একটি যুক্ত সাবনেট। রুটটি না থাকলে যোগ করুন। যদি থাকে আর হোস্টটি তখনও নীরব থাকে, ফাঁকটি VPC-র দিকে, তাই অ্যাসোসিয়েশন সাবনেটের রুট টেবিলের সঙ্গে মেলান।

ক্লায়েন্ট পাশের একটি সেটিং টানেল না ভেঙেই রাউটিং ভাঙে: route-nopull ধারণকারী একটি প্রোফাইল। নির্দেশিকাটি OpenVPN-ভিত্তিক ক্লায়েন্টকে সার্ভার যে রুট পাঠায় তা উপেক্ষা করতে বলে, ফলে ইন্টারফেস কেবল endpoint-এর নিজের ঠিকানা নিয়ে ওঠে এবং গন্তব্যের কোনো রুটই থাকে না। Linux-এ ip route show বা macOS-এ netstat -rn দিয়ে দেখুন tun ইন্টারফেস দিয়ে কোনো রুট আছে কি না। না থাকলে রপ্তানি করা প্রোফাইল থেকে route-nopull সরান এবং পুনঃসংযোগ করুন যাতে পাঠানো রুটগুলো প্রয়োগ হয়।

সিকিউরিটি গ্রুপ আপনার ক্লায়েন্ট ঠিকানা দেখে না

এই অংশটিই আমি এক বিকেল ধরে ভুল করেছিলাম। একটি সাবনেটের সঙ্গে যুক্ত IPv4 endpoint-এর জন্য, সার্ভিসটি ক্লায়েন্টের উৎস ঠিকানাকে সেই সাবনেটে endpoint-এর নেটওয়ার্ক ইন্টারফেসের ঠিকানায় রূপান্তর করে. ইনস্ট্যান্সে পৌঁছানো প্যাকেটটি আপনার ক্লায়েন্ট যে ঠিকানা দেখিয়েছিল তা বহন করে না, তাই ক্লায়েন্ট পুল, ধরুন 172.16.0.0/22, অনুমোদন করা সিকিউরিটি গ্রুপ নিয়ম কিছুর সঙ্গেই মেলে না।

পোর্টটি ক্লায়েন্ট CIDR থেকে নয়, endpoint-এর সিকিউরিটি গ্রুপ থেকে অনুমোদন করুন, যা অ্যাসোসিয়েশনের ইন্টারফেসে সংযুক্ত। গ্রুপের রেফারেন্স দেওয়া ঠিকানা হার্ডকোড করার চেয়ে টেকসই, কারণ ইন্টারফেসের ঠিকানা আপনার নিয়ন্ত্রণে নয়। নেটওয়ার্ক ACL স্টেটলেস, তাই যেখানে কাস্টম এন্ট্রি আছে, সেখানে ইনবাউন্ড ও আউটবাউন্ড দুই দিককেই ফ্লো অনুমোদন করতে হবে।

ইনস্ট্যান্সের প্রাইভেট ঠিকানাতেও সংযোগ করুন। পাবলিক IP প্যাকেটটিকে VPC-র বাইরে নিয়ে ভিন্ন নিয়মে ভিন্ন পথে ফিরিয়ে আনে, তাই পাবলিক ঠিকানায় পরীক্ষা প্রাইভেট পথ সম্পর্কে কিছুই বলে না।

প্রথম ব্যর্থতায় থেমে যাওয়া একটি আইসোলেশন ক্রম

এগুলো ক্রমানুসারে দেখুন এবং যেখানে একটি ব্যর্থ হয় সেখানেই থামুন। প্রতিটি ধাপ সব স্তর নয়, একটি স্তর বাদ দেয়।

1. নিশ্চিত করুন সেশনটি কোন পরিচয় ব্যবহার করেছে এবং endpoint কোন গ্রুপ মূল্যায়ন করে। একটি trust store-এর সার্টিফিকেট ডিরেক্টরি থেকে আসা SAML দাবির মতো একই প্রিন্সিপাল নয়।
2. নিশ্চিত করুন একটি অনুমোদন নিয়ম সেই গ্রুপের জন্য রিসোর্স CIDR ঢেকে রাখে।
3. নিশ্চিত করুন একটি endpoint রুট আছে এবং তা একটি যুক্ত সাবনেট লক্ষ্য করে, তারপর নিশ্চিত করুন সাবনেট রুট টেবিল আরও সামনে পৌঁছাতে পারে।
4. নিশ্চিত করুন সিকিউরিটি গ্রুপ পোর্টটি ক্লায়েন্ট পুল থেকে নয়, endpoint ইন্টারফেস থেকে অনুমোদন করে।
5. অ্যাপ্লিকেশন সমস্যাকে ক্লায়েন্ট-পথের সমস্যা থেকে আলাদা করতে VPC-র ভিতর থেকে, একই সাবনেটের অন্য ইনস্ট্যান্সে SSM সেশনে পরীক্ষা করুন।

ধাপগুলো নির্ণায়ক না হলে আমি এই টেবিলেই ফিরে যাই:

অ্যাকাউন্টের দুটি বিবরণ এমন উপসর্গ তৈরি করে যা অনুমতির ব্যর্থতার মতো দেখায়। প্রতিটি ব্যবহারকারীর আলাদা ক্লায়েন্ট সার্টিফিকেট দরকার; একটি সার্টিফিকেট দুই মেশিনে ভাগ করলে সেশনগুলো একে অপরকে সরিয়ে দেয়, আর ফলাফল প্রত্যাখ্যান নয়, পুনঃসংযোগের লুপ। নতুন endpoint তৈরি হলে কনসোল এমন একটি DNS নাম দেখায় যা কিছু ক্লায়েন্ট সংস্করণ কেবল endpoint পৃষ্ঠায় দেখানো এলোমেলো প্রিফিক্সসহ গ্রহণ করে, তাই নামটি পুনর্গঠন না করে পুরোটা কপি করুন।

পঞ্চম ধাপে আটকে গেলে কিছু বদলানোর আগে endpoint-এর সংযোগ লগ নামিয়ে অনুমোদন এন্ট্রিগুলো পড়ুন। লগটি যাচাই করা গন্তব্য এবং যে নিয়ম মিলেছে বা মেলেনি তা নাম বলে দেয়, যা চার স্তরের প্রশ্নটিকে একটি উত্তরে নামিয়ে আনে।