AWS Client VPN-এ অনিয়মিত অ্যাক্সেস: প্রতিটি সংযুক্ত সাবনেট যাচাই করুন

একজন ব্যবহারকারী সংযোগ করেন, অভ্যন্তরীণ অ্যাপ খোলেন এবং উত্তর পান; একই এন্ডপয়েন্টে থাকা সহকর্মী একই Wi-Fi-তে একই রকম ল্যাপটপ থেকে টাইমআউট পান। এই ধরনটি একাধিক সংযুক্ত সাবনেটযুক্ত client VPN এন্ডপয়েন্টের চিহ্ন, যেখানে পথগুলো সমতুল্য নয়। আমি এটি কনসোল থেকে বাইরের দিকে অনুসরণ করি, কারণ দুটি ট্যাব ঠিক করে বাকি তদন্তটা করার মতো কিনা। ক্লায়েন্ট কনফিগারেশনে এর কোনো ব্যাখ্যা নেই।

এন্ডপয়েন্ট থেকে শুরু করুন এবং অ্যাসোসিয়েশনগুলো তালিকাভুক্ত করুন

VPC কনসোলে Client VPN endpoints খুলুন, এন্ডপয়েন্ট বেছে নিন এবং Associations ট্যাব পড়ুন। প্রতিটি অ্যাসোসিয়েশন একটি অ্যাভেইলেবিলিটি জোনের সাবনেট, এবং সংযোগ তৈরির সময় সার্ভিস যেটি বেছে নেয় ক্লায়েন্ট সেখানেই পড়ে। সাবনেট আইডি এবং প্রতিটি আসলে যে রুট টেবিল ব্যবহার করে তা লিখে রাখুন, কারণ এই দুটি তালিকাই আপনার আসন্ন তুলনা।

এন্ডপয়েন্ট যদি কেবল একটি অ্যাসোসিয়েশন দেখায়, তবে এই তত্ত্বটি ভুল এবং ক্লায়েন্টই বেশি সন্দেহভাজন।

এন্ডপয়েন্ট রুট টেবিল প্রতিটি অ্যাসোসিয়েশনের সঙ্গে তুলনা করুন

একই এন্ডপয়েন্টে Route table ট্যাব খুলুন। সেখানকার প্রতিটি গন্তব্য CIDR-এর একটি লক্ষ্য আছে, এবং client VPN-এ লক্ষ্য হলো অ্যাসোসিয়েশন, গেটওয়ে নয়। AWS প্রতিটি সংযুক্ত সাবনেটের জন্য গন্তব্য এন্ট্রি দাবি করে, তাই কেবল একটিকে লক্ষ্য করা রুট অ্যাক্সেসকে সেশনের অবস্থানের উপর নির্ভরশীল করে তোলে। আপনার আসলে প্রয়োজনীয় গন্তব্যটি দেখুন, তারপর তার অনুমোদন নিয়মটি দেখুন, কারণ রুট পথ দেয় আর নিয়ম ঠিক করে কে এটি ব্যবহার করতে পারবে।

দুই স্তরকেই টেবিলে সাজালে ব্যর্থতাটি এড়ানো কঠিন।

দ্বিতীয় সারিটাই বেশিরভাগ টিকিটের পুরো বাগ। এন্ডপয়েন্ট রুট আছে, তাই কেউ আরও দেখে না, এবং প্যাকেট এক হপ পরে VPC-র ভিতরে মারা যায়।

প্রতিটি সাবনেটকে তার কার্যকর রুট টেবিল পর্যন্ত অনুসরণ করুন

স্পষ্ট রুট টেবিল অ্যাসোসিয়েশন নেই এমন সাবনেট VPC-র মূল টেবিল উত্তরাধিকার পায়। যে টেবিলটি আসলে কার্যকর তা পড়ুন, যার নাম ঠিক দেখায় সেটি নয়, এবং সারির লেবেল নয়, গন্তব্য ও লক্ষ্য তুলনা করুন।

AWS-এর অনিয়মিত অ্যাক্সেস নির্দেশিকা এটিকে অ্যাসোসিয়েশনজুড়ে রুট কভারেজ হিসেবে বর্ণনা করে, যা সঠিক মডেল। এন্ডপয়েন্ট প্যাকেটকে একটি সাবনেটে পৌঁছায়, এবং সেই সাবনেটের টেবিলকে এখনও জানতে হয় অ্যাপ্লিকেশন নেটওয়ার্ক কোথায় থাকে।

যে টেবিলের মালিকানা, সেখানেই অনুপস্থিত সারিটি ঠিক করুন। একটি কাজ করা সাবনেট থেকে পুরো রুট টেবিল কপি করলে ইন্টারনেট, অ্যাপ্লায়েন্স ও আইসোলেশনের সিদ্ধান্তও কপি হয় যা কখনো এই সাবনেটের জন্য বোঝানো হয়নি, এবং এই বিনিময় সাধারণত আপনি যে বিভ্রাট দিয়ে শুরু করেছিলেন তার চেয়ে খারাপ।

অনুমোদন নিয়ম, তারপর ফেরার পথ দেখুন

অনুমোদন নিয়ম গন্তব্য ও গ্রুপভিত্তিক, এবং রুট থেকে আলাদাভাবে মূল্যায়িত হয়। সর্বত্র রুট থাকা কিন্তু ব্যবহারকারীর গ্রুপের জন্য নিয়ম না থাকা গন্তব্য সুস্থ দেখতে রুট টেবিলসহ একটি ব্ল্যাক হোলের মতো আচরণ করে।

ফেরার পথও একই মনোযোগ দাবি করে। একটি peering সংযোগের জন্য অ্যাপ্লিকেশন VPC-তে ক্লায়েন্ট CIDR-এর দিকে ফিরে যাওয়া রুট, দুই প্রান্তেই ট্রাফিক অনুমোদন করে এমন সিকিউরিটি গ্রুপ নিয়ম এবং তা ফেলে না দেওয়া নেটওয়ার্ক ACL দরকার। একমুখী পৌঁছানোযোগ্যতা, যেখানে ping কাজ করে কিন্তু TCP হ্যান্ডশেক করে না, সাধারণত VPN নয়, ACL বা সিকিউরিটি গ্রুপের দিকে ইঙ্গিত করে।

এন্ডপয়েন্টের নিজের সিকিউরিটি গ্রুপগুলো অ্যাসোসিয়েশনের ইলাস্টিক নেটওয়ার্ক ইন্টারফেসে থাকে, তাই ক্লায়েন্ট CIDR থেকে অ্যাপ্লিকেশন পোর্ট অনুমোদন করা নিয়মটি কেবল ইনস্ট্যান্সে নয়, অ্যাসোসিয়েশনে সংযুক্ত করতে হবে।

একটি ভাগ্যবান অনুরোধ নয়, পুনঃসংযোগ দিয়ে যাচাই করুন

split tunnel-এ সংযোগ স্থাপনের সময় এন্ডপয়েন্ট রুট পাঠানো হয়, তাই বদলে যাওয়া রুট সেট সংযুক্ত থাকা ক্লায়েন্টের কাছে কখনো পৌঁছায় না। সমর্থিত ক্লায়েন্ট দিয়ে সংযোগ বিচ্ছিন্ন করে আবার সংযোগ করুন, তারপর মেশিনে নতুন রুটগুলো আছে কিনা নিশ্চিত করুন।

সবশেষে, ক্লায়েন্ট যে ঠিকানা পেয়েছে তার সঙ্গে সংযোগ লগ মিলিয়ে দেখুন, এবং একাধিক অ্যাসোসিয়েশনে পৌঁছানোর মতো যথেষ্ট বার পরীক্ষাটি পুনরাবৃত্তি করুন। সংশোধনের পর একটি সফল অনুরোধ প্রমাণ করে একটি পথ কাজ করছে, আর টিকিটটি ছিল অন্যটি নিয়ে।