AWS Site-to-Site VPN থেকে NAT Gateway: VGW বনাম Transit Gateway

প্রথমবার সবাই একই ডায়াগ্রাম আঁকে: VPC-তে VPN, তারপর NAT gateway দিয়ে ইন্টারনেটে, শেষ। কিন্তু VPN যখন virtual private gateway-তে শেষ হয়, AWS ওই পথ সমর্থন করে না, আর ব্যর্থতাটি এতটাই নীরব যে দলগুলো একাধিকবার এটি নতুন করে বানায়। যে ডিজাইন কাজ করে তার জন্য transit gateway দরকার, যা দুই পাশেই gateway ও রুট টেবিল বদলে দেয়। কিছু আঁকার আগে দুই ধরনের গঠন মিলিয়ে দেখুন।

যে টপোলজি দেখতে স্পষ্ট, কিন্তু সমর্থিত নয়

AWS-এর NAT gateway ডকুমেন্টেশন এমন একটি রেখা টানে যা শুধু একক VPC ডিজাইন বানানো যে কাউকে অবাক করে: Site-to-Site VPN সংযোগের ট্রাফিক virtual private gateway হয়ে NAT gateway-তে রুট করা যায় না। VPN কোন ধরনের gateway-তে শেষ হচ্ছে সেটাই ঠিক করে আদৌ কোনো অনুবাদ-পথ আছে কি না। ভুলটি টিকে থাকে কারণ টানেলের অবস্থা UP এবং একই subnet-এর একটি EC2 ইনস্ট্যান্স অনায়াসে ইন্টারনেটে পৌঁছায়। এই দুটি পর্যবেক্ষণের কোনোটিই ভাঙা দিকটি পরীক্ষা করে না।

বাস্তবে প্যাকেটটি on-premises সোর্স ঠিকানা নিয়ে আসে এবং তাকে অনুবাদ করার মতো কোনো সমর্থিত পরবর্তী hop পায় না। টেবিলের উপর নির্ভর করে এটি egress সীমানায় ফেলে দেওয়া হয়, আর টানেল UP থাকায় এবং একই subnet-এর ইনস্ট্যান্স ইন্টারনেটে পৌঁছানোয় ব্যর্থতাটি on-premises firewall সমস্যা হিসেবে রিপোর্ট হয়।

Virtual private gateway বনাম transit gateway

একটি virtual private gateway একটি VPC-র অধীন। এটি VPN শেষ করে, ওই VPC-র রুট টেবিলে রুট বসায় এবং সেখানেই থামে। এর কোনো attachment মডেল নেই, তাই এটি অন্য VPC বা শেয়ার করা egress সেগমেন্টে ট্রাফিক দিতে পারে না। এই একক-VPC পরিধিই পুরো সীমাবদ্ধতা, আর VPC-র ভেতরে যোগ করা কোনো রুট তা বদলায় না।

Transit gateway একটি আঞ্চলিক হাব, যেখানে VPN, প্রতিটি spoke VPC এবং একটি শেয়ার্ড সার্ভিস VPC—সবই attachment হিসেবে দেখা যায়। এর নিজস্ব রুট টেবিল আছে, যেগুলো ঠিক করে কোন attachment একটি নির্দিষ্ট prefix পাবে।

এই হাবই কেন্দ্রীভূত egress সম্ভব করে। VPN একটি attachment হিসেবে নামে, egress VPC আরেকটি হিসেবে নামে, আর transit gateway রুট টেবিল ইন্টারনেটমুখী prefix প্রথমটি থেকে দ্বিতীয়টিতে পাঠায়। virtual private gateway-এর ক্ষেত্রে পাঠানোর মতো দ্বিতীয় attachment নেই, তাই ডিজাইনটি পরে প্যাচ করে বানানো সম্ভব নয়।

সমর্থিত egress পথ, ধাপে ধাপে

রেফারেন্স ডিজাইনে পাঁচটি hop আছে, আর প্রতিটি তীর এমন একটি রাউটিং সিদ্ধান্ত যা আপনাকে কনফিগার করতে হবে। ট্রাফিক on-premises নেটওয়ার্ক ছেড়ে Site-to-Site VPN attachment-এ যায়। transit gateway রুট টেবিল এটি egress VPC attachment-এ পাঠায়, যেখানে subnet টেবিল এটি একটি public NAT gateway-তে পাঠায়। NAT gateway সোর্স অনুবাদ করে এবং internet gateway প্যাকেটটি বাইরে নিয়ে যায়।

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

শেষ hop-গুলো কাজ করবে কি না তা দুইটি বিষয় ঠিক করে। NAT gateway-কে public হতে হবে, elastic IP ও internet gateway-এর রুট থাকতে হবে, কারণ private NAT gateway নেটওয়ার্কের মধ্যে অনুবাদ করে এবং কখনোই ইন্টারনেট নির্গমনপথ হয় না।

আপনি যে প্রতিটি Availability Zone-এ সেবা দিতে চান, সেখানে একটি করে NAT gateway পরিকল্পনা করুন, আর প্রতিটি subnet টেবিল স্থানীয়টির দিকে নির্দেশ করুক। transit gateway টেবিল ও VPC টেবিলগুলো আপনার নোটে আলাদা বস্তু হিসেবে রাখুন, কারণ একটি attachment বেছে নেয়, অন্যটি VPC-র ভেতরের রিসোর্স বেছে নেয়। শুধু একটিতে default রুট থাকলে পথের অর্ধেক অনির্ধারিত থাকে এবং সবচেয়ে কষ্টে চিহ্নিতযোগ্য আংশিক ব্যর্থতা তৈরি হয়।

ফেরত পথেই এই ডিজাইনগুলো ব্যর্থ হয়

NAT gateway আগে দেখা flow-গুলোর জন্য stateful, তাই বহির্গামী সংযোগের উত্তর নতুন inbound নিয়ম ছাড়াই ফিরে আসে। এই ধর্ম on-premises সেবাকে ইন্টারনেটে প্রকাশ করে না, আর তাকে তা-ই ভাবা মানে একটি দল এমন সংযোগ ডিবাগ করতে দিন নষ্ট করে যা কখনোই তৈরি হতো না। ক্লায়েন্ট-উৎপন্ন ট্রাফিকের জন্য চারটি রুটকে একমত হতে হয়: on-premises নীতি, transit gateway টেবিল, egress subnet টেবিল ও NAT subnet টেবিল। শেষটি বাদ পড়লে অনুরোধ ভবন ছেড়ে যায়, অথচ উত্তর AWS-এর ভেতরেই মরে যায়।

VPN-এর পেছনে সত্যিকারের ক্লায়েন্ট দিয়ে যাচাই করুন এবং সে যে public সোর্স ঠিকানা দেখায় তা দেখুন। এটি NAT gateway-এর elastic IP হলে অনুবাদ হচ্ছে; অন্য কিছু হলে আপনি ভিন্ন egress মাপছেন।

এই ব্যর্থতার অপ্রতিসম রূপটি আগেভাগেই চেনা দরকার। যখন একটি Availability Zone-এর NAT subnet টেবিলে ক্লায়েন্ট prefix-এ ফেরার রুট থাকে আর অন্যটিতে থাকে না, তখন flow কোন zone-এ পড়ছে তার ভিত্তিতে নতুন সংযোগ সফল বা ব্যর্থ হয়, আর এই ধরনটিকে ভুলভাবে অস্থির ইন্টারনেট বলে পড়া হয়। টিকিট যেখানে খোলা হয়েছিল সেই zone ঠিক করার বদলে আপনি যে প্রতিটি zone-এ সেবা দেন তার subnet টেবিল মিলিয়ে দেখুন, কারণ অনুপস্থিত রুটই পুরো ত্রুটি এবং ওপাশে কিছুই বদলাতে হবে না।

কখন স্পষ্ট proxy-ই ভালো ডিজাইন

egress VPC-র একটি ইনস্ট্যান্সে HTTP proxy একটি বৈধ বিকল্প এবং প্রায়ই সস্তা। ক্লায়েন্টদের এটি ব্যবহার করতে কনফিগার করা হয়, proxy নিজের সংযোগ বাইরের দিকে খোলে, আর ফেরত পথটি প্রতিসম রাউটিংয়ের ধাঁধা নয়—proxy-র সমস্যা। অল্প কিছু অ্যাপ্লিকেশনের জন্য এটি transit gateway-র বেশিরভাগ কাজ সরিয়ে দেয়। এটি ব্যবহারকারী-ভিত্তিক লগও দেয়, যা NAT gateway দিতে পারে না।

তবে এটি স্বচ্ছ নয়। proxy সেটিংস উপেক্ষা করে এমন সবকিছু এবং HTTP নয় এমন প্রতিটি প্রোটোকল এই পথে যাবে না।

সিদ্ধান্ত নির্ভর করে আপনার অ্যাপ্লিকেশন আসলে কী ভাষায় কথা বলে এবং লগে কতটা পরিচয় দরকার তার উপর। যেখানে তারা HTTP বলে, সেখানে proxy-ই জায়গা পায়; যেখানে ইচ্ছামতো প্রোটোকলের জন্য সাধারণ egress দরকার, সেখানে AWS-সমর্থিত ডিজাইনটি transit gateway-র। আগে থেকে এটি ঠিক করা রুট টেবিল বানানোর পর আবিষ্কার করার চেয়ে সস্তা।