SaaS ট্রাফিক কীভাবে সঠিক গ্রাহক VPN-এ রুট করবেন
ওভারল্যাপিং গ্রাহক সাবনেট শেয়ার করা রাউটিং ভেঙে দেয়। একটি আইসোলেশন মডেল বাছুন, প্রতিটি কাজকে যাচাইকৃত টেন্যান্টের সাথে বেঁধে দিন এবং চালুর আগে ক্রস-টেন্যান্ট পথ পরীক্ষা করুন।
একটি SaaS প্ল্যাটফর্ম এক ডজন গ্রাহক নেটওয়ার্কের সাথে সংযুক্ত হয়, এবং সেই গ্রাহকদের মধ্যে দুটি তাদের প্রাথমিক ডেটাবেসের জন্য 10.20.0.10 ব্যবহার করে। যে ওয়ার্কার কাজের মধ্যে সেই ঠিকানাটি পায়, তার কাছে বোঝার উপায় নেই যে কাজটি কোন ডেটাবেস বোঝাচ্ছে, আর একটি শেয়ার করা রাউটিং টেবিল প্রিফিক্স যে টানেলের দিকে ইশারা করছে সেখানেই এটি আনন্দের সাথে পাঠিয়ে দেবে। সমাধান আরও টানেল নয়; সমাধান হলো টেন্যান্ট পরিচয় পথে কোথায় ঢোকে এবং ঠিকানা পরিকল্পনার জন্য কোন আইসোলেশন মডেল দরকার তা ঠিক করা। তিনটি শর্ত এই পছন্দ নির্ধারণ করে: গ্রাহক প্রিফিক্স ওভারল্যাপ করে কি না, একটি ভুল কতদূর ছড়াতে পারে এবং কে কানেক্টর চালায়।
দুটি গ্রাহক ডেটাবেস, একটি গন্তব্য ঠিকানা
একটি IP ঠিকানা একটি অবস্থান, পরিচয় নয়। অনুরোধটিকে অবশ্যই এমন একটি টেন্যান্ট বহন করতে হবে যা সার্ভার যাচাই করেছে, এবং গন্তব্য নির্ধারিত হওয়ার আগে সেই টেন্যান্টকে নেটওয়ার্ক প্রসঙ্গ বাছতে হবে।
যখন তা হয় না, ব্যর্থতা নিঃশব্দ। সংযোগ সফল হয়, কোয়েরি চলে, আর উত্তর আসে ভুল গ্রাহকের ডেটাবেস থেকে, কারণ রাউটিং টেবিলে 10.20.0.10-এর জন্য একটি এন্ট্রি ছিল। DNS আরও খারাপ করে: টেন্যান্ট A-এর প্রসঙ্গে নির্ধারিত একটি ক্যাশ করা নাম টেন্যান্ট B-এর জন্য চলা একটি কাজ পুনরায় ব্যবহার করতে পারে। প্যাকেটে কিছুই দুটির মধ্যে পার্থক্য করে না, তাই কোনো পুনরায় চেষ্টার যুক্তি এটি সারায় না।
প্রথমে আইসোলেশন মডেল ঠিক করুন
পণ্য তুলনা করার আগে তিনটি শর্ত লিখে রাখুন। ওভারল্যাপ ঠিক করে একটি ঠিকানা স্থান আদৌ শেয়ার করা যায় কি না; বিস্ফোরণ ব্যাসার্ধ ঠিক করে রাউটিং ভুল একটি সাপোর্ট টিকিট না লঙ্ঘন; পরিচালন মালিকানা ঠিক করে আপনি প্রতি টেন্যান্টে একটি কানেক্টর ফ্লিট চালাতে পারেন কি না।
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
প্রিফিক্স যদি আলাদা হয় এবং নীতি একটি নিয়ন্ত্রিত হাব অনুমোদন করে, তাহলে প্রতি টেন্যান্ট রাউট টেবিলসহ একটি Transit Gateway কাজ করে। অ্যাটাচমেন্ট অ্যাসোসিয়েশন সেই অ্যাটাচমেন্ট থেকে আসা ট্রাফিকের জন্য ব্যবহৃত রাউট টেবিল বাছাই করে, আর প্রোপাগেশন বাছাই করে কোন রুটগুলো একটি টেবিলে দেখা যায়। যে টেন্যান্ট অ্যাটাচমেন্ট কেবল নিজের টেবিলের সাথে সংযুক্ত এবং কেবল নিজের প্রিফিক্স প্রচার করে, সেটি হাবে পৌঁছায় এবং আর কোথাও নয়। এটি একটি রাউটিং সিদ্ধান্ত, এবং এটি ততক্ষণ সঠিক থাকে যতক্ষণ কেউ শেয়ার করা টেবিলে একটি ডিফল্ট রুট যোগ না করে।
প্রিফিক্স ওভারল্যাপ করলে কেবল রাউটিং তাদের আলাদা করতে পারে না। আপনার হয় প্রতি টেন্যান্টে আলাদা নেটওয়ার্ক প্রসঙ্গ দরকার, নাহয় এমন একটি অনুবাদ পরিকল্পনা দরকার যা প্রতিটি গ্রাহকের স্থানকে দ্ব্যর্থহীন অর্থ দেয়।
Transit Gateway আইসোলেশন আসলে কী বোঝায়
অ্যাসোসিয়েশন ও প্রোপাগেশন হলো দুটি গুরুত্বপূর্ণ নব, এবং এগুলো গুলিয়ে ফেলা সহজ। অ্যাসোসিয়েশন উত্তর দেয় এই অ্যাটাচমেন্ট থেকে আসা প্যাকেট কোন টেবিলে খোঁজা হয়; প্রোপাগেশন উত্তর দেয় কোন টেবিলগুলো এই অ্যাটাচমেন্টের রুট শেখে। আইসোলেশন আসে দুটিকেই টেন্যান্ট-নির্দিষ্ট করার মাধ্যমে, আরও অ্যাটাচমেন্ট তৈরি করার মাধ্যমে নয়।
ডিফল্ট সব-থেকে-সব সেটআপ সুবিধাজনক এবং এটি আইসোলেশন নয়। আলাদা রাউট টেবিল সংযোগ সীমিত করে, কিন্তু একই রাউটিং প্রসঙ্গে একটি অপরিবর্তিত গন্তব্য ঠিকানাকে দুটি অর্থ দেয় না। যদি অ্যাপ্লিকেশন টেন্যান্ট জানার আগে 10.20.0.10 নির্ধারণ করে, রাউটিং স্তর ইতিমধ্যে যে তথ্য দরকার ছিল তা হারিয়ে ফেলেছে।
AWS 23 অক্টোবর 2026-এ Transit Gateway ও Cloud WAN-এর জন্য অ্যাটাচমেন্ট-স্তরের 1:1 NAT যোগ করেছে, যা সমর্থিত অ্যাটাচমেন্টের জন্য ওভারল্যাপের উত্তর বদলে দেয়। Transit Gateway NAT ডকুমেন্টেশন হোস্ট বিট সংরক্ষিত রেখে স্থির, অবস্থাহীন, সমান-প্রিফিক্স IPv4 ম্যাপিং বর্ণনা করে। এর চারপাশে নকশা করার আগে সমর্থিত অ্যাটাচমেন্টের ধরন ও আঞ্চলিক সীমাবদ্ধতা যাচাই করুন।
কাজটিকে যাচাইকৃত টেন্যান্টের সাথে বেঁধে দিন
প্রতিটি কাজে সার্ভার-যাচাইকৃত টেন্যান্ট পরিচয় থাকা উচিত, এবং সেই পরিচয়ের উচিত প্রশাসক-মালিকানাধীন একটি সংযোগ রেকর্ড বাছাই করা। রেকর্ডটি অনুমোদিত নেটওয়ার্ক প্রসঙ্গ, পরিষেবার ঠিকানা, ক্রেডেনশিয়াল রেফারেন্স এবং সেখানে অনুমোদিত ক্রিয়াকলাপের নাম দেয়। একটি অবিশ্বস্ত অনুরোধ কখনও নিজের VPN শনাক্তকারী, গেটওয়ে বা ব্যক্তিগত লক্ষ্য সরবরাহ করতে পারে না, কারণ বৈধ লগইন প্রতিটি সংযুক্ত গ্রাহকের ঠিকানা স্থান অনুসন্ধান করার অনুমতি নয়।
আইসোলেটেড কানেক্টর নকশায় টেন্যান্ট A-এর কাজ যায় A-নির্দিষ্ট কানেক্টরে, যা A-এর VPC-তে চলে এবং কেবল A-এর অনুমোদিত সম্পদে পৌঁছাতে পারে। একই হোস্টে আলাদা কন্টেইনার নিজে থেকে সেই পৃথকীকরণ তৈরি করে না; নেটওয়ার্ক নেমস্পেস, রুট ও ইগ্রেস নীতিকে তা বাস্তবায়ন করতে হয়। কানেক্টরের টেন্যান্ট-সীমিত ক্রেডেনশিয়াল ও কিউও দরকার, কারণ একটি ব্যক্তিগত রুট একটি শেয়ার করা গোপন বা শেয়ার করা কাজের আইটেমকে সীমিত করে না। পুল করা অ্যাপ্লিকেশন ওয়ার্কার ঠিক আছে, যতক্ষণ নেটওয়ার্ক প্রসঙ্গ ও ক্রেডেনশিয়াল প্রতি হোস্টে নয়, প্রতি টেন্যান্টে বাছাই করা হয়।
স্বাস্থ্য পরীক্ষায় টেন্যান্ট ও পর্যায়ের নাম থাকা উচিত: টানেল প্রতিষ্ঠিত, রুট উপস্থিত এবং একটি বাস্তব পরিষেবা অনুরোধ সফল—এগুলো তিনটি ভিন্ন সংকেত। চালু থাকা টানেলের একটি সমষ্টিগত গণনা সেই একমাত্র গ্রাহককে লুকিয়ে রাখবে যার কানেক্টর নষ্ট।
যে পথগুলো ব্যর্থ হতে হবে সেগুলো পরীক্ষা করুন
চালুর আগে তিনটি পরীক্ষা চালান। একটি অনুমোদিত A ক্রিয়াকলাপ সফল হতে হবে, একটি অনুমোদিত B ক্রিয়াকলাপ সফল হতে হবে, এবং ইচ্ছাকৃতভাবে B-এর কানেক্টর বা অনূদিত উপনামের দিকে লক্ষ্য করা একটি A কাজ বন্ধভাবে ব্যর্থ হতে হবে। তারপর একটি টানেল ভেঙে দিন এবং নিশ্চিত করুন যে কাজটি কেবল সেই টেন্যান্টের জন্য ব্যর্থ হয়, অন্য গ্রাহকের একই-সংখ্যাযুক্ত সাবনেটে ফিরে না গিয়ে। পুনরুদ্ধারও পরীক্ষা করা উচিত, কারণ একটি পুরনো রুট বা ক্যাশ করা ক্রেডেনশিয়াল বিভ্রাটকে ছাড়িয়ে যেতে পারে।
আর্কিটেকচার হতে পারে আইসোলেটেড কানেক্টরসহ পুল করা ওয়ার্কার, বা সম্পূর্ণ পৃথক টেন্যান্ট সম্পদ। অপরিবর্তনীয় বিষয় একই: যাচাইকৃত টেন্যান্ট প্রসঙ্গ রুট ও ক্রেডেনশিয়াল বাছাই করে, এবং কোনো রুট পরিবর্তন কখনও টেন্যান্টজুড়ে অ্যাপ্লিকেশন অনুমতি দেয় না।