পিয়ারড VPC-তে পৌঁছাতে AWS Client VPN নাকি bastion

একটি Client VPN এন্ডপয়েন্ট এমন একটি VPC-তে পৌঁছাতে পারে যা তার সংশ্লিষ্ট VPC-র সঙ্গে peered, এবং এটি বৈধ করতে আপনার bastion লাগে না। যে সিদ্ধান্তটি নেওয়া মূল্যবান তা হলো ট্রাফিক কোথায় হাত বদলায়: এন্ডপয়েন্ট রুট যা অ্যাসোসিয়েশন সাবনেটে পৌঁছে peering সংযোগ পার হয়, নাকি peered VPC-র একটি হোস্ট যা সেশন শেষ করে। দুটি পথই কাজ করে এবং ভিন্ন জায়গায় ব্যর্থ হয়, তাই সিদ্ধান্তটি মালিকানা ও অডিট নিয়ে, AWS কী অনুমোদন দেয় তা নিয়ে নয়। এখানে আমি কীভাবে দুটির মধ্যে বাছি, এবং যে চারটি এন্ট্রি রাউটেড পথটিকে কাজ করায়।

দুটি পথ, একটি এন্ডপয়েন্ট, ভিন্ন মালিক

রাউটেড পথে ক্লায়েন্ট ট্রাফিক এন্ডপয়েন্টে পৌঁছায়, অ্যাসোসিয়েশন সাবনেটে Client VPN নেটওয়ার্ক ইন্টারফেসের ঠিকানায় রূপান্তরিত হয় এবং সেই সাবনেট ছেড়ে A থেকে B-তে peering সংযোগ পার হয়। VPC B কোনো VPN সেশন শেষ করে না; এটি VPC A থেকে আসা সাধারণ ট্রাফিক দেখে, তাই এর রিটার্ন রুট ক্লায়েন্ট পুলে নয়, VPC A-তে নির্দেশ করে।

bastion পথে ক্লায়েন্ট প্রথমে একটি হোস্টে পৌঁছায়। A-তে bastion শেষ হপটিকে এখনও peering সংযোগ পার করায়, তাই peering-এর কাজ থেকে যায় এবং একটি সেশন যোগ হয়। B-তে bastion-এরও ক্লায়েন্ট থেকে পথ দরকার, আর যখন সেই পথটি একই এন্ডপয়েন্ট রুট, তখন আপনার কাছে রাউটেড নকশা প্লাস একটি হপ থাকে। bastion কেবল তখনই কাজ কমায় যখন এটি আগে থেকেই আছে, আগে থেকেই অনুমোদিত, এবং এর পেছনের জিনিসটির নেটওয়ার্ক সীমার বদলে সেশন সীমা দরকার।

চারটি এন্ট্রি রাউটেড পথ কাজ করায়

AWS এই দৃশ্যটি Client VPN how-it-works পাতায় নথিভুক্ত করেছে, এবং বাস্তবে বিষয়টি দুই বা তিনটি দলের মালিকানাধীন চারটি এন্ট্রিতে নেমে আসে। রেঞ্জগুলো উদাহরণের জন্য; peered রেঞ্জটি অনন্য হতে হবে এবং রিটার্ন রেঞ্জটি আপনার পরিকল্পনার সঙ্গে মিলতে হবে।

রুট ও অনুমতি আলাদা নিয়ন্ত্রণ। সঠিক এন্ডপয়েন্ট রুট কিন্তু মিলযুক্ত অনুমোদন নিয়ম না থাকলে ক্লায়েন্ট কিছুই পায় না; এমন গন্তব্যের জন্য অনুমোদন নিয়ম যা এন্ডপয়েন্ট রাউট করতে পারে না, তাকে কেবল কালো গর্ত দেয়। দুটিকেই একই রেঞ্জ উল্লেখ করতে হবে।

এন্ডপয়েন্ট রুট এন্ডপয়েন্টের নিজের VPC-র একটি সাবনেটে নির্দেশ করে, কখনও peering সংযোগে নয়। VPC রুট টেবিল peering সংযোগে নির্দেশ করে, কখনও ইনস্ট্যান্স বা ইন্টারফেসে নয়। দুটির মধ্যে একটি মান কপি করলে কোনো অভিযোগ ছাড়াই সংরক্ষিত হয় এবং কিছুই রাউট হয় না।

যেহেতু অ্যাসোসিয়েশন সাবনেট ক্লায়েন্টের উৎস রূপান্তর করে, B-কে ক্লায়েন্ট পুলে নয়, VPC A-তে ফিরতি রুট দিতে হবে। peering সংযোগের ওপর দিয়ে ক্লায়েন্ট রেঞ্জ পাঠানো প্রতিসম দেখায়, পর্যালোচনা পার হয় এবং নীরবে ব্যর্থ হয়, কারণ B কখনও ক্লায়েন্ট উৎসযুক্ত প্যাকেট দেখে না।

সিকিউরিটি গ্রুপ এবং অনুমতির শেষ মিটার

রাউটিং প্যাকেট B-তে পৌঁছায়; সিদ্ধান্ত নেয় B-ই। একই অঞ্চলে সক্রিয় peering সংযোগের জন্য B-তে একটি সিকিউরিটি গ্রুপ Client VPN অ্যাসোসিয়েশনে প্রয়োগ করা গ্রুপকে রেফারেন্স করতে পারে, যা নিয়মটি সংকীর্ণ রাখে এবং ঠিকানা পরিবর্তনে টিকে থাকে। যেখানে গ্রুপ রেফারেন্স কাজ করে না, সেখানে 0.0.0.0/0 পর্যন্ত প্রশস্ত না করে অ্যাসোসিয়েশন সাবনেট রেঞ্জ স্পষ্টভাবে অনুমোদন করুন, কারণ এটি রাউটিং ভুলকে অস্পষ্ট টাইমআউটে পরিণত করে।

তারপর দেখুন রাউটিং কখনও যা স্পর্শ করে না: দুই সাবনেটের নেটওয়ার্ক ACL, অ্যাপ্লিকেশনের allow-list বা টোকেন দর্শক, এবং DNS। peering প্রাইভেট হোস্টেড জোন কপি করে না, তাই ল্যাপটপ এমন ঠিকানায় কাজ করা রুট ধরে রাখতে পারে যা সে রিজলভ করতে পারে না, আর peering সংযোগ সার্টিফিকেটে কোনো বিশ্বাস যোগ করে না। এন্ডপয়েন্টকে এমন রিজলভারের দিকে নির্দেশ করুন যা B-র জন্য উত্তর দেয়, তারপর নিশ্চিত করুন প্রাইভেট নাম ও সার্টিফিকেট মিলে।

কখন bastion সৎ উত্তর

ইচ্ছাকৃতভাবে bastion বেছে নেওয়ার জন্য আমি তিনটি ট্রিগার রাখি। peered VPC এমন দলের, যে আপনার রেঞ্জের জন্য রিটার্ন রুট যোগ করবে না বা গ্রুপ রেফারেন্স গ্রহণ করবে না। অথবা অ্যাক্সেস প্রতি সেশনে অনুমোদিত বা রেকর্ডকৃত হতে হবে এবং অ্যাপ্লিকেশন তা নিজে বহন করতে পারে না। অথবা শেষ হপ B-র ভেতরেই থাকতে হবে, কারণ সার্ভিসটি কেবল সেখানেই রিজলভ হয় এবং এর TLS পরিচয় একটি অভ্যন্তরীণ নামে পিন করা।

এর কোনোটিই peering-এর অ-ট্রানজিটিভতার বিকল্প পথ নয়। অ-ট্রানজিটিভতা B-র রিসোর্স কী করতে পারে তা সীমিত করে: তারা A-কে তৃতীয় VPC-তে ট্রানজিট হিসেবে ব্যবহার করতে পারে না যার সঙ্গে A peered। এর অর্থ কখনও ছিল না যে VPN ব্যবহারকারী সরাসরি peered VPC-তে পৌঁছাতে পারে না, আর সেই ভুল পাঠ এড়াতে তৈরি bastion হলো অকারণে প্যাচ করার হোস্ট।

উল্টো ভুলটি সময়ের সঙ্গে বেশি খরচ করে: প্রতিটি দলকে ইতিমধ্যে থাকা একমাত্র bastion দিয়ে চালান, তারপর দেখুন তার সিকিউরিটি গ্রুপ, রুট টেবিল ও প্যাচ উইন্ডোই প্রোডাকশন নির্ভরতা। হোস্টটি কোন ট্রিগারে সেবা দেয় তা লিখে রাখুন, এবং ট্রিগার চলে গেলে এটি অবসর দিন।

Transit Gateway ও একাধিক অ্যাসোসিয়েশন হিসাব বদলায়

এন্ডপয়েন্ট সাবনেটে নয়, সরাসরি Transit Gateway-তে সংযুক্ত হলে মডেল বদলায়: ক্লায়েন্ট আর অ্যাসোসিয়েশন সাবনেটের ইন্টারফেস ঠিকানায় রূপান্তরিত হয় না, এবং গেটওয়ে রুট টেবিলে ক্লায়েন্ট রেঞ্জের সঙ্গে peered VPC-তে নেওয়া সংযুক্তিও থাকতে হবে। স্কেলে এটি পরিচ্ছন্নতর, কিন্তু কাজটি চারটি এন্ট্রি থেকে গেটওয়ে রুট টেবিলে সরে যায়।

একাধিক অ্যাসোসিয়েশন পরীক্ষা গুণ করে। এন্ডপয়েন্ট রুট এন্ডপয়েন্টের, তবু প্রতিটি অ্যাসোসিয়েশন সাবনেটের প্রকৃত peering নেক্সট হপযুক্ত রুট টেবিল দরকার। একটি অ্যাসোসিয়েশন দিয়ে সেশন সফল হতে পারে যখন অন্যটির ফিরতি পথ নেই, তাই প্রত্যেকটি পরীক্ষা করুন।

যে যাচাইয়ের ক্রম ভাঙন দ্রুত খুঁজে পায়

এগুলো ক্রমে চালান; প্রতিটি ধাপ পাস করতে পারে যখন পরেরটি ব্যর্থ হয়, আর ক্লায়েন্ট টাইমআউট প্রায় কখনও বলে না কোনটি ভেঙেছে।

1. ক্লায়েন্ট থেকে অ্যাপ্লিকেশনের নাম রিজলভ করুন এবং ঠিকানাটি peered রেঞ্জের ভেতরে কি না দেখুন।
2. সংযোগ করুন, তারপর যে অ্যাসোসিয়েশন সেশন শেষ করেছে তার এন্ডপয়েন্ট সংযোগ লগ পড়ুন।
3. সেই অ্যাসোসিয়েশন সাবনেটে নিশ্চিত করুন রুট টেবিল peered রেঞ্জকে সক্রিয় peering সংযোগে নির্দেশ করে।
4. B-র রিসোর্স সাবনেটে ইন্টারফেস রেঞ্জের ফিরতি এন্ট্রি ও মিলযুক্ত গ্রুপ নিয়ম নিশ্চিত করুন।
5. একটি অনুমোদিত কাজ ও একটি রিসোর্স পরীক্ষা করুন যা অগম্য থাকা উচিত; দ্বিতীয়টি ডিবাগিংয়ের অবশিষ্টাংশ ধরে।
6. যেকোনো split-tunnel রুট পরিবর্তনের পর পুনঃসংযোগ করুন, কারণ চলমান টানেল নতুন রুট সেট নেবে না।

দুটি লক্ষণ মনে রাখা মূল্যবান। B-তে পৌঁছে উত্তরহীন SYN প্রায় সবসময়ই অনুপস্থিত রিটার্ন রুট। সংযোগ সম্পন্ন হয়ে তারপর রিসেট হলে সাধারণত গ্রুপ, ACL বা অ্যাপ্লিকেশন। কোনোটিই এন্ডপয়েন্ট লগে কারণ হিসেবে দেখা যায় না, তাই চারটি এন্ট্রি প্রতিটির পাশে মালিক রেখে সংরক্ষণ করুন।

তিনটি ট্রিগারের কোনোটিই প্রযোজ্য না হলে রাউটেড পথ শেষ করুন এবং সেই চারটি এন্ট্রি রেকর্ড করুন। একটি প্রযোজ্য হলে কেবল সেই সীমার জন্য bastion রাখুন এবং যে সার্ভিসের সামনে সেশন দরকার নেই তাদের জন্য এন্ডপয়েন্ট রুট রেখে দিন।