একটি AWS NAT গেটওয়ে VPN-এর দিকে কোন সোর্স IP ব্যবহার করে?
একটি পাবলিক NAT গেটওয়ের Elastic IP হলো ইন্টারনেট পরিচয়, VPN পিয়ার যা দেখে তা নয়। প্রকৃত সোর্স জানতে সাবনেট থেকে গেটওয়ে পর্যন্ত রুটটি অনুসরণ করুন।
আপনি VPC কনসোল খুলছেন কারণ একজন পার্টনার জানতে চেয়েছে সাইট-টু-সাইট VPN দিয়ে কোন সোর্স রেঞ্জ আসবে। NAT গেটওয়ে পেজটি Elastic IP যুক্ত একটি পাবলিক গেটওয়ে দেখায়, এবং প্রলোভন হলো সেই ঠিকানাটি পাঠিয়ে এগিয়ে যাওয়া। ইন্টারনেট পথের জন্য এটি সঠিক উত্তর আর VPN পথের জন্য ভুল উত্তর, এবং পার্থক্যটি হলো রুট টেবিল কোন গেটওয়ের দিকে ইশারা করে। অনুমোদিত তালিকা লেখার আগে রুটটি ধরে হাঁটুন।
অনুমোদিত তালিকা নয়, NAT গেটওয়ে পেজ থেকেই শুরু করুন
NAT গেটওয়ে পেজ আপনাকে সাবনেট, ধরন এবং Elastic IP জানায়, আর এই তিনটি ক্ষেত্র শুরু করার জন্য যথেষ্ট। এটি যা জানায় না তা হলো এরপর ট্রাফিক কোন পথে যায়। সেটি NAT গেটওয়ের সাবনেটের সঙ্গে যুক্ত রুট টেবিল থেকে আসে।
প্রথমে ধরনটি পড়ুন, কারণ পাবলিক না প্রাইভেট তা ঠিক করে পরে চেইনে একটি ইন্টারনেট গেটওয়ে আসবে কি না। তারপর সাবনেটটি পড়ুন, কারণ দ্বিতীয় রুটটি সেখানেই থাকে।
দুটি রূপান্তর অনুসরণ করুন
পাবলিক ও প্রাইভেট উভয় NAT গেটওয়েই ওয়ার্কলোডের প্রাইভেট IPv4 সোর্সকে NAT গেটওয়ের নিজের প্রাইভেট IPv4 ঠিকানায় রূপান্তর করে। প্রথম রূপান্তরটি ধরন নির্বিশেষে ঘটে। দ্বিতীয় রূপান্তরটি মানুষ ভুলে যায়: একটি পাবলিক NAT গেটওয়ে ট্রাফিক ইন্টারনেট গেটওয়ের হাতে দেয়, যা ঠিকানাটিকে যুক্ত Elastic IP-তে ম্যাপ করে।
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10
প্রাইভেট পথে চেইনে কোনো ইন্টারনেট গেটওয়ে থাকে না। যখন ট্রাফিক একটি ট্রানজিট গেটওয়ে বা ভার্চুয়াল প্রাইভেট গেটওয়ে দিয়ে বেরোয়, তখন NAT গেটওয়ে গাইড NAT গেটওয়ের প্রাইভেট ঠিকানাকে সেই সোর্স হিসেবে নথিভুক্ত করে যা দূরপ্রান্ত পায়। পার্টনারকে এই ঠিকানাটিই অনুমোদন করতে হবে, Elastic IP নয়।
VPN পথ সাধারণত প্রাইভেট ঠিকানাটি দেখায়
10.20.1.0/24-এ থাকা একটি ওয়ার্কলোড যখন পার্টনার প্রিফিক্সে পৌঁছায়, তখন ওয়ার্কলোড সাবনেটের রুট টেবিল NAT গেটওয়ের দিকে এবং NAT গেটওয়ের সাবনেটের রুট টেবিল প্রাইভেট গেটওয়ে পথের দিকে ইশারা করে। দুটি হপই গুরুত্বপূর্ণ, এবং কেবল দ্বিতীয়টি ঠিক করে পার্টনার কী দেখবে। NAT সাবনেটের VPN পথে কোনো রুট না থাকলে প্যাকেট কখনোই পৌঁছায় না, আর এটি ভুল সোর্স ঠিকানার চেয়ে আলাদা ব্যর্থতা।
ঠিকানা নিয়ে আদৌ কথা বলার আগে সেই দ্বিতীয় রুটটি যাচাই করুন। শুধু কোনো ট্রাফিক দেখতে না পাওয়া পার্টনারের কাছে অনুপস্থিত রুট আর ভুলভাবে জানানো সোর্স একই রকম দেখায়।
যখন দ্বিতীয় রূপান্তর উত্তরটি বদলে দেয়
AWS একটি ট্রানজিট গেটওয়ে সংযুক্তিতে স্পষ্ট, মিলে যাওয়া এক-থেকে-এক NAT ম্যাপিংও দেয়। সেই ম্যাপিং দূরবর্তী সেবা দেখার আগে সোর্সকে আবার রূপান্তর করতে পারে, এবং এটি কেবল রাউটিং করা ডিফল্ট আচরণ নয়। যেহেতু এটি ইচ্ছাকৃতভাবে কনফিগার করতে হয়, তাই এটিকে দুর্ঘটনাক্রমে উত্তরাধিকার পাওয়া কিছু নয়, বরং একটি ডিজাইন ব্যতিক্রম হিসেবে ধরুন। আপনার দলের কেউ যদি মনে না রাখে যে এটি চালু করা হয়েছিল, তাহলে সংযুক্তিটি পড়া পর্যন্ত এটিকে অনুপস্থিত ধরে নিন।
আপনার ডিজাইন এটি ব্যবহার করলে অনুমোদিত তালিকায় NAT গেটওয়ের ঠিকানা নয়, চূড়ান্ত ম্যাপিং বর্ণনা করতে হবে। একই সতর্কতা প্রযোজ্য প্রাপ্যতার পথেও: একাধিক গেটওয়ে ঠিকানা অংশ নিলে প্রত্যাশিত সোর্স সেট হলো সংযোগ, কোনো একটি প্রতিনিধি ঠিকানা নয়। প্রতিটি ঠিকানা কোন রূপান্তরের তা লিখে রাখুন, কারণ উৎসহীন তালিকা পরে নিরীক্ষা করা অসম্ভব।
একটি প্রাইভেট NAT গেটওয়েকে ইন্টারনেট গেটওয়ের দিকে নির্দেশ করে ইন্টারনেট সেবা দেওয়া যায় না; AWS নথিভুক্ত করে যে এমন ট্রাফিক ফেলে দেওয়া হয়। ধরনটি সম্পূর্ণ পথ থেকে বেছে নিন, প্রয়োজনীয়তার ভেতরের VPN শব্দ থেকে নয়।
আপনার পার্টনার যে চুক্তি নিয়ে কাজ করতে পারে তা লিখুন
ব্যবহারযোগ্য চুক্তির চারটি অংশ থাকে: প্রবাহ কোন দিক থেকে শুরু হয়, পার্টনার যে রূপান্তরিত পরিচয় দেখবে, সেই পরিচয়ের ফেরার রুট, এবং যে সুরক্ষা পরিধি প্রযোজ্য। NAT গেটওয়ের প্রবাহ সমর্থিত উৎস দিক থেকে শুরু হয়, তাই এটি প্রাইভেট ওয়ার্কলোড উন্মুক্ত করার জন্য আগত পোর্ট ফরওয়ার্ডিং সেবা নয়। এটি আগেভাগে জোরে বলা এমন একটি ডিজাইন পর্যালোচনা ঠেকায় যেখানে প্রতিটি পক্ষ ধরে নিয়েছিল অন্য পক্ষই শুরু করছে।
রূপান্তর ঠিকানা-ওভারল্যাপ থেকে স্বস্তি এবং পূর্বানুমেয় সোর্স নীতি কিনে দেয়, আর পার্টনারের লগে আলাদা ওয়ার্কলোড পরিচয় হারায়। নিরীক্ষার জন্য প্রতি ওয়ার্কলোডের অ্যাট্রিবিউশন দরকার হলে সেই পরিচয়টি রূপান্তরিত সোর্স ঠিকানা থেকে উদ্ধার করার চেষ্টা না করে অ্যাপ্লিকেশন স্তরে রাখুন।
তারপর যেকোনো পরিবর্তনের পরে দুই রুট টেবিলই আবার যাচাই করুন, কারণ নতুন সংযুক্তি বা পুনঃসংযুক্ত সাবনেট নিঃশব্দে উত্তরটি নতুন করে লেখে।