EC2-তে strongSwan: VPC-কে কাজের ভার রুট করতে দিন

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

প্রথমে চারটি ঠিকানা লিখে রাখুন

নিচের প্রতিটি ধাপ এগুলোকে নির্দেশ করে, তাই রাউটিং টেবিল স্পর্শ করার আগে নিজের অ্যাকাউন্টের জন্য এগুলো পূরণ করুন।

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

উদাহরণটি একটি অনুমোদিত, কার্যকর নীতি-ভিত্তিক IPsec সংযোগ এবং উৎস-সংরক্ষণকারী প্রবাহ ধরে নেয়। এটি NAT-যুক্ত রিমোট অ্যাক্সেস ক্লায়েন্ট নয় যা একটি নির্ধারিত ঠিকানা ধার করে, এবং এই পার্থক্যই ঠিক করে সিলেক্টরগুলো পরিবর্তন করতে হবে কি না।

ধাপ 1: কাজের ভারের সাবনেটকে একটি রুট দিন

কাজের ভারের সাবনেটের সাথে প্রকৃতপক্ষে সংযুক্ত রাউটিং টেবিলের দূরবর্তী প্রিফিক্সের জন্য এমন একটি পথ দরকার যা গেটওয়ের নেটওয়ার্ক ইন্টারফেসের দিকে ইঙ্গিত করে। ইনস্ট্যান্সের ভিতরে ইনস্টল করা গেস্ট রুট সেই AWS রাউটিং টেবিলে কোনো এন্ট্রি নয়, এবং কোনো পরিমাণ strongSwan কনফিগারেশন এটি তৈরি করবে না।

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

একটি অনুমোদিত নেটওয়ার্কের জন্য জায়গা করতে VPC-র লোকাল রুট বা প্রতিটি বিদ্যমান এন্ট্রি প্রতিস্থাপন করবেন না। কী সংযুক্ত ও সক্রিয় তা পরীক্ষা করুন, কনসোল পৃষ্ঠা এমন একটি রাউটিং টেবিলের জন্য কী দেখায় তা নয় যা কেউ ব্যবহার করে না। একই রকম দেখতে দুটি টেবিলের সংযোগ ভিন্ন হতে পারে। গুরুত্বপূর্ণটি হলো যেটির সাথে কাজের ভারের সাবনেট সংযুক্ত।

ধাপ 2: গেস্টে ফরওয়ার্ডিং চালু করুন

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

সিকিউরিটি গ্রুপ হলো সেই জায়গা যেখানে এই ধাপ সাধারণত আটকে যায়। একটি মিডলবক্স সরাসরি ইনস্ট্যান্স যোগাযোগের সিকিউরিটি গ্রুপ রেফারেন্স আচরণ উত্তরাধিকার করে না, তাই ম্যানেজড Client VPN উদাহরণ থেকে কপি করা একটি নিয়ম কখনও মিলতে নাও পারে। প্রকৃত পথে উভয় দিকে সিকিউরিটি গ্রুপ ও সাবনেট ACL পরীক্ষা করুন।

ধাপ 3: সিলেক্টরগুলোকে প্রকৃত উৎস পর্যন্ত প্রসারিত করুন

AWS পাশে কেবল 10.60.1.10/32 কভার করা একটি নীতি গেটওয়ে থেকে শুরু হওয়া সাফল্য ব্যাখ্যা করে 10.60.2.20 কভার না করেই। দূরবর্তী গন্তব্যের দিকে রুট কোনো ট্র্যাফিক সিলেক্টর প্রসারিত করে না, এবং সেটিই একই বিস্ময়ের দ্বিতীয় অর্ধেক।

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

যদি সম্মত নকশা সমগ্র VPC রক্ষা করে, তবে উভয় পক্ষকে 10.60.0.0/16 ও 10.90.0.0/24 গ্রহণ করতে হবে। যদি এটি একটি কাজের ভার রক্ষা করে, তবে সচেতনভাবে সেই সংকীর্ণ প্রিফিক্স ব্যবহার করুন। যেভাবেই হোক, ইনস্টল করা CHILD-SA নীতি পরীক্ষা করুন, কারণ আপনি যে কনফিগারেশন সম্পাদনা করেছেন এবং যে পক্ষ এটি ভিন্নভাবে সংকুচিত করেছে তারা একই চুক্তি নয়।

দূরবর্তী সাইটকেও সংরক্ষিত VPC উৎসের উত্তরগুলো অভীষ্ট IPsec গেটওয়ে দিয়ে ফিরিয়ে রুট করতে হবে। যেখানে অন্যান্য সোর্স NAT নিয়ম আছে সেখানে সুরক্ষিত ট্র্যাফিকের জন্য সমর্থিত NAT ছাড় সংরক্ষণ করুন; একটি অননুমোদিত কাজের ভারকে অনুমোদিত হোস্ট ঠিকানায় অনুবাদ করা ভিন্ন একটি পরিচয় চুক্তি, আপনার কাঙ্ক্ষিত অ্যাক্সেসের শর্টকাট নয়।

ধাপ 4: যাচাই করুন, প্রয়োজনে ফিরিয়ে নিন

কাজের ভার থেকেই একটি নতুন অনুমোদিত অ্যাপ্লিকেশন অপারেশন দিয়ে পরীক্ষা করুন, তারপর এমন গন্তব্য দিয়ে পুনরাবৃত্তি করুন যা বাদ দেওয়া উচিত। দূরবর্তী সেবা যে সোর্স ঠিকানা দেখে এবং যে ফিরতি পথ ব্যবহার করে তা লিখে রাখুন। গেটওয়েতে পিং বা সবুজ IKE স্ট্যাটাস সেই পরীক্ষা নয়।

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

ফিরিয়ে আনা একই ক্রম উল্টে দেয়। কাজের ভারের সাবনেটের রুটটি সবার শেষে সরান, পূর্ববর্তী সিলেক্টরগুলো পুনরুদ্ধারের পরে, যাতে এমন সাবনেট না রেখে যান যা এমন একটি গেটওয়ের দিকে ইঙ্গিত করে যা আর তার উৎস রক্ষা করে না। এই চুক্তিগুলো বহাল থাকলে স্ব-হোস্টিং গেটওয়ে হোস্টের চেয়ে বেশি সেবা দিতে পারে, এবং AWS-পরিচালিত Site-to-Site VPN হলো ভিন্ন একটি পরিচালন মডেল যেখানে strongSwan বরং গ্রাহক গেটওয়ের প্রান্তে বসতে পারে।