Site-to-Site VPN আর CloudHub

এই লেসন শেষে তুমি পারবে

• কখন অফিস বা data centre-কে AWS-এর সাথে জোড়ার ঠিক উপায় Site-to-Site VPN, আর কখন Direct Connect, Client VPN বা transit gateway বেশি মানানসই, বলতে।
• একটা VPN-এর তিনটা resource (customer gateway, virtual private gateway, VPN connection) চিনতে, আর কোনটায় কী থাকে বলতে: public IP, BGP ASN, certificate, tunnel।
• Tunnel-এর ভেতর দিয়ে internet-এ আসলে কী যায় বোঝাতে: UDP 500-এ IKE, ESP, আর router NAT-এর পেছনে থাকলে UDP 4500-এ NAT traversal।
• প্রতিটা VPN connection-এ কেন দুই AZ-এ দুটো tunnel থাকে, সেটা কী বাঁচায় আর কী বাঁচায় না, বোঝাতে, আর দুটো customer gateway ও চারটা tunnel দিয়ে সর্বোচ্চ availability-র design করতে।
• Static না dynamic (BGP) routing বেছে নিতে, route propagation চালু করতে, ICMP-র জন্য security group খুলতে, আর tunnel up অথচ ping যাচ্ছে না, এমন VPN-এর সমস্যা খুঁজে বের করতে।
• VPN কোথায় শেষ হবে (virtual private gateway, transit gateway, Cloud WAN) ঠিক করতে, কখন Accelerated Site-to-Site VPN লাগে বলতে, আর ২০২৫-এর নতুন feature (large bandwidth tunnel, VPN Concentrator) কী বদলায় জানতে।
• AWS VPN CloudHub দিয়ে ব্রাঞ্চ অফিসগুলোর মধ্যে hub and spoke বানাতে, আর এর তিনটা শর্ত মনে রাখতে।
• Site-to-Site VPN আর AWS Client VPN আলাদা করে চিনতে, আর দুটোরই মাসিক bill আন্দাজ করতে।

#Internet-এর ওপর দিয়ে নিজের network AWS-এ জোড়া কেন

অধ্যায় ৩-এ আমরা এমন একটা VPC বানিয়েছিলাম যেটা internet-এর সাথে কথা বলে। লেসন ২২.১ থেকে ২২.৩-এ VPC-কে VPC-র সাথে আর AWS-এর service-এর সাথে জুড়েছি। এবার hybrid cloud-এর বাকি অর্ধেক: তোমার নিজের network, মানে একটা অফিস, একটা ফ্যাক্টরি বা একটা data centre, এমনভাবে VPC-র ভেতরের private IP-তে পৌঁছাবে যেন পাশের ঘরেই আছে।

তোমার বিল্ডিং থেকে AWS-এ ঢোকার রাস্তা দুটো:

• AWS Site-to-Site VPN (এই লেসন): যে পাবলিক internet-এর বিল তুমি এমনিতেই দাও, তার ওপর দিয়ে একটা encrypted IPsec connection। কয়েক মিনিটে চালু, প্রতি connection-এ ঘণ্টায় মোটামুটি $০.০৫, আর এর গতি আর latency চলে internet-এর মেজাজ বুঝে।
• AWS Direct Connect (লেসন ২২.৫): AWS পর্যন্ত একটা নিজস্ব physical line। Bandwidth আর latency স্থির, internet কখনো না, কিন্তু অর্ডার দিয়ে হাতে পেতে প্রায়ই এক মাসের বেশি লাগে, খরচও বেশি।

দুটোর সাথেই লেসন ১০.১০-এ S3-তে যাওয়ার রাস্তা হিসেবে পরিচয় হয়েছে। এখানে VPN-টা সত্যি সত্যি বানাব।

#তিনটা অংশ: customer gateway, virtual private gateway, VPN connection

Site-to-Site VPN-এর জন্য দুই দিকে দুটো প্রান্ত লাগে, আর লাগে এদের মাঝের একটা connection। AWS-এ এটা তিনটা resource।

#Virtual private gateway: AWS-এর প্রান্ত

Virtual private gateway (VGW) হলো AWS-এর দিকের VPN concentrator।

• তুমি এটা বানিয়ে যে VPC-তে পৌঁছাতে চাও, সেই VPC-তে attach করো। একটা VGW একবারে একটাই VPC-তে লাগে; কখনো একসাথে কয়েকটা VPC-র কাজ করতে পারে না। অনেকগুলো VPC হলে VPN-টা বরং transit gateway-তে শেষ করো (লেসন ২২.৬)।
• Amazon-এর দিকের জন্য এর একটা BGP ASN থাকে। তুমি কিছু না বললে এটা পায় Amazon-এর default 64512; বানানোর সময় নিজের পছন্দের private ASN (64512–65534, বা ৩২-bit-এর private ASN) দিতে পারো। পরে আর বদলানো যায় না: নতুন VGW বানাতে হয়।
• এটা নিজে থেকেই highly available: AWS এটাকে আলাদা আলাদা AZ-এ redundant endpoint-এ চালায়। তোমাকে size ঠিক করতে বা patch দিতে হয় না।
• কয়েকটা quota জেনে রাখো: default হিসেবে Region-এ ৫টা VGW আর প্রতি VGW-তে ১০টা VPN connection (দুটোই বাড়ানো যায়)। VGW শুধু IPv4 বয়; IPv6 VPN লাগলে transit gateway বা Cloud WAN লাগবে।

#Customer gateway: তোমার প্রান্ত, AWS-কে চিনিয়ে দেওয়া

এখানে শব্দগুলো গুলিয়ে ফেলা খুব সহজ:

• Customer gateway device হলো অফিসে তোমার আসল router বা firewall: একটা physical box (Cisco, Fortinet, Palo Alto…) বা একটা software appliance। AWS কিছু device-এর তালিকা দেয় যেগুলো তারা পরীক্ষা করে দেখেছে, তবে যে device standard IPsec পারে, আর সম্ভব হলে BGP-ও, সেটাই চলবে।
• Customer gateway (CGW) resource হলো AWS-এ তোমার বানানো একটা রেকর্ড, যেটা ওই device-এর বর্ণনা দেয়। এটা device-কে configure করে না; সেটা তুমি নিজে করো, তোমার vendor-এর জন্য AWS-এর বানিয়ে দেওয়া configuration file দেখে।

Customer gateway resource-এ যা দিতে হয়:

• Device-এর public IP address, যেটা static হতে হবে। Device যদি NAT traversal (NAT-T) সমর্থন করা একটা NAT device-এর পেছনে থাকে, তাহলে দাও NAT device-এর public IP, কারণ AWS ওই address-টাই দেখবে।
• তার BGP ASN (dynamic routing-এর জন্য): তোমার নিজের public ASN থাকলে সেটা, নইলে 65010-এর মতো একটা private ASN।
• চাইলে pre-shared key-র বদলে certificate দিয়ে পরিচয় যাচাইয়ের জন্য AWS Private Certificate Authority-র (ACM দিয়ে দেওয়া) একটা private certificate। Certificate থাকলে customer gateway-র fixed IP-ও লাগে না।

তোমার অফিসের firewall-কে tunnel যেতে দিতে হবে: তোমার public IP আর AWS-এর দুটো tunnel IP-র মধ্যে UDP 500 (IKE), UDP 4500 (NAT-T) আর ESP (IP protocol 50)।

#অফিসের public IP বদলে গেলে

Customer gateway resource edit করা যায় না: এর IP address আর ASN স্থির। ISP যদি router-কে নতুন public IP দেয়:

1. নতুন IP দিয়ে একটা নতুন customer gateway বানাও।
2. আগের VPN connection-টা modify করে নতুন customer gateway-র দিকে দেখাও (aws ec2 modify-vpn-connection --customer-gateway-id), অথবা নতুন একটা VPN connection বানাও। AWS যতক্ষণ বদলাচ্ছে, connection অল্প সময় বন্ধ থাকে; configuration আবার download করে router-এ বসাও।
3. পুরোনো customer gateway মুছে দাও।

#VPN connection: দুটো tunnel

VPN connection একটা customer gateway-কে একটা virtual private gateway (বা transit gateway)-এর সাথে জোড়ে। এটা বানালেই AWS নিজে থেকে দুটো IPsec tunnel বানায়, প্রত্যেকটা AWS-এর আলাদা একটা public IP-তে, দুটো আলাদা Availability Zone-এ। সাথে তোমার device-এর জন্য একটা configuration file-ও বানিয়ে দেয় (দুটো tunnel, তাদের pre-shared key আর ভেতরের address), যেটা তুমি download করে বসাও।

#Tunnel কীভাবে কাজ করে: IKE, ESP আর NAT traversal

একটা IPsec tunnel দুই ধাপে তৈরি হয়:

1. IKE (Internet Key Exchange, UDP 500)। দুই প্রান্ত নিজেদের পরিচয় প্রমাণ করে, প্রতি tunnel-এর একটা pre-shared key দিয়ে বা certificate দিয়ে, আর encryption-এর key ঠিক করে নেয়। AWS IKE version 1 আর IKEv2 দুটোই নেয়; IKEv2-ই ভালো।
2. ESP (Encapsulating Security Payload)। প্রতিটা আসল packet, তার private address-সহ পুরোটা, encrypt (AES) করা হয়, একটা integrity check লাগানো হয়, তারপর দুই public address-এর মধ্যে একটা নতুন IP header দিয়ে মুড়ে দেওয়া হয়। মাঝখানের ISP শুধু দেখে “203.0.113.10 একটা AWS address-এর সাথে কথা বলছে”।

তোমার router যদি NAT device-এর পেছনে থাকে, সাধারণ ESP তখন ঝামেলা করে: এতে port নেই, তাই NAT একে চিনে রাখতে পারে না। IKE টের পায় পথে NAT আছে, আর দুই প্রান্তই NAT-T-তে চলে যায়: ESP মোড়ানো হয় UDP 4500-এর ভেতরে, যেটাকে NAT আর দশটা flow-এর মতোই সামলায়।

#Tunnel-এর যে option-গুলো তুমি বদলাতে পারো

AWS নিরাপদ default দেয়, তবে প্রতিটা tunnel-এর জন্য তুমি নিজে বাছতে পারো:

Production-এ দুটো সংখ্যা অনেককে চমকে দেয়: tunnel দিয়ে সর্বোচ্চ MTU হলো ১৪৪৬ byte (MSS ১৪০৬), কারণ IPsec header-গুলো জায়গা খায়; আর jumbo frame বা Path MTU Discovery চলে না। Router-এ MSS ঠিক করে দাও, নইলে ছোট ping ঠিকঠাক গেলেও বড় transfer আটকে থাকতে পারে।

#Tunnel আর high availability

দুটো tunnel কেন? কারণ AWS একটা বন্ধ করবেই। Maintenance-এর জন্য AWS মাঝে মাঝে tunnel endpoint বদলায়, আর যেকোনো hardware-ই নষ্ট হতে পারে। দুই AZ-এ দুটো tunnel থাকলে একটা দূরে থাকলেও অন্যটা traffic বয়ে নেয়।

দুটো tunnel কী করে আর কী করে না:

• তোমার অফিস থেকে AWS-এর দিকে তোমার router দুটো tunnel-ই ব্যবহার করতে পারে।
• AWS থেকে তোমার অফিসের দিকে AWS একটা tunnel-কে active পথ হিসেবে বেছে নেয়। VGW-তে এটা হলো ওই gateway-র সব VPN connection মিলিয়ে একটাই tunnel; বাকিগুলো standby। তাই VGW-তে connection বাড়ালে redundancy বাড়ে, bandwidth না। কয়েকটা tunnel জুড়ে traffic ছড়িয়ে দেওয়া (ECMP) transit gateway-র feature (লেসন ২২.৬)।
• Failover নিজে থেকে হয় কেবল তখনই, যখন তোমার device-এ দুটো tunnel-ই সাজানো আছে। যে router-এ শুধু tunnel 1 বসানো, প্রথম maintenance-এই সেটা অন্ধকারে চলে যায়।
• দুটো tunnel-ই শেষ হয় তোমার একটা router-এ। ওই router মরে গেলে দুটো tunnel-ও তার সাথে মরে।

#Routing: static না dynamic

Packet-এর route লাগে দুই দিকেই, আর দুই অভিমুখেই। দেওয়ার উপায় দুটো:

• Dynamic routing (BGP): তোমার router আর AWS প্রতিটা tunnel-এর ভেতরে একটা BGP session চালায়। তোমার router অফিসের range জানায়; AWS জানায় VPC-র range। অফিসে নতুন subnet হলে AWS-এ কাউকে কিছু ছুঁতে হয় না, নিজেই শেখা হয়ে যায়। BGP মরা tunnel-ও তাড়াতাড়ি ধরে ফেলে আর তার route তুলে নেয়, ফলে failover পরিষ্কার হয়। Device BGP পারলে এটাই best practice।
• Static routing: অফিসের prefix-গুলো তুমি VPN connection-এ নিজে লিখে দাও (১০০টা পর্যন্ত), আর router-এ VPC-র range-এর route-ও নিজেই বসাও। সস্তা router-ওয়ালা ছোট site-এর জন্য চলে; range বদলালে ঝামেলা, আর failover নির্ভর করে device-এর নিজের health check-এর ওপর।

বড় network-এ কয়েকটা সীমা কাজে লাগে: VGW-তে একটা VPN connection-এ customer gateway সর্বোচ্চ ১০০টা route জানাতে পারে (transit gateway-তে ১,০০০), আর এই quota বাড়ানো যায় না। অফিসের range-গুলো গুছিয়ে বড় করে জানাও (যেমন ৩০০টা ছোট prefix-এর বদলে একটা 10.0.0.0/8), নয়তো transit gateway-তে চলে যাও।

#AWS কীভাবে route-এর মধ্যে বাছে

VPC route table-এ যে route সবচেয়ে নির্দিষ্ট, সে জেতে (longest prefix match, লেসন ৩.৩)। হুবহু একই prefix হলে local route সবসময় জেতে, আর তোমার যোগ করা static route একটা propagate হওয়া route-কে হারায়।

VGW-এর ভেতরে একই prefix কয়েক জায়গা থেকে এলে পছন্দের ক্রম এরকম:

1. Direct Connect থেকে BGP দিয়ে শেখা route,
2. VPN connection-এর static route,
3. VPN connection থেকে BGP দিয়ে শেখা route,
4. BGP-র VPN route-গুলোর মধ্যে সবচেয়ে ছোট AS path, তারপর সবচেয়ে কম multi-exit discriminator।

প্রথম লাইনটার জন্যই VPN হলো Direct Connect-এর ভালো backup: দুটো একই prefix বইলে AWS Direct Connect-কে বেশি পছন্দ করে (লেসন ২২.৫)। আর এসবের আগে আসে tunnel-এর health: বন্ধ tunnel কখনো বাছা হয় না।

#Route propagation আর security group: দুটো চিরচেনা ফাঁদ

দুটো ধাপ ভুলে যাওয়া খুব সহজ, আর পরীক্ষা দুটোই খুব পছন্দ করে:

• Route propagation। VPN বানালে VPC-র কোনো route table নিজে থেকে বদলায় না। যে যে subnet অফিসের সাথে কথা বলে, তাদের প্রতিটা route table-এ হয় VGW-এর route propagation চালু করতে হবে, নয়তো অফিসের range-এর একটা static route দিতে হবে, target হিসেবে VGW। Propagation VGW যা জানে (BGP route বা connection-এর static route) সেটা table-এ কপি করে, আর হালনাগাদ রাখে।
• Security group। VPN traffic-কে instance পর্যন্ত পৌঁছে দেয়, কিন্তু শেষ কথা বলে instance-এর security group। অফিস থেকে ping দিয়ে পরীক্ষা করতে চাইলে অফিসের range থেকে ICMP-র একটা inbound rule যোগ করো। নইলে tunnel up, routing একদম ঠিক, তবুও ping time out।

Propagation-এর ফাঁদটা হলো, ভেতরে আসা traffic ঠিকঠাক পৌঁছে যায় (তার শুধু VPC-র local route লাগে), তাই tunnel-কে সুস্থই মনে হয়। ফেরার পথ নেই reply-এর।

Animation-এর private subnet-এর route table, propagation চালুর আগে আর পরে:

নিজে চালিয়ে দেখো: route propagation ছাড়া বাকি সব করা একটা VPN দিয়ে শুরু করো, তারপর অন্য ধাপগুলো একটা একটা করে ভাঙো আর ঠিক করো।

#Bandwidth, সীমা আর দাম

• Bandwidth: প্রতি tunnel-এ ১.২৫ Gbps পর্যন্ত আর সেকেন্ডে প্রায় ১,৪০,০০০ packet। আসল throughput নির্ভর করে internet-এর পথ, packet-এর আকার আর তোমার device-এর ওপর। VGW-তে AWS থেকে তোমার দিকে traffic একটা tunnel-এই যায়, তাই প্রতি VGW-তে ১.২৫ Gbps ধরে পরিকল্পনা করো।
• আরও bandwidth: transit gateway-তে ECMP অনেকগুলো tunnel-এ flow ছড়িয়ে দেয় (দুটো connection = চারটা tunnel ≈ ৫ Gbps), কিন্তু একটা flow তবুও একটা tunnel-ই ব্যবহার করে (লেসন ২২.৬)।
• দাম: বেশিরভাগ Region-এ প্রতি VPN connection-ঘণ্টায় প্রায় $০.০৫, সাথে AWS থেকে তোমার network-এ যাওয়া ডেটার সাধারণ data transfer out (AWS-এ ঢোকা ডেটা ফ্রি)। Tunnel-গুলো public IPv4 address-ও ব্যবহার করে, যেটার দাম AWS তার public IPv4 pricing অনুযায়ী নেয়; নিজের Region-এর জন্য VPN-এর pricing page দেখে নিও।

গাজীপুরের ফ্যাক্টরির হিসাব: ৭৩০ ঘণ্টার এক মাসে একটা connection মানে ৭৩০ × $০.০৫ = $৩৬.৫০; ফ্যাক্টরিতে ২০০ GB report আর backup ফেরত পাঠালে internet egress-এর প্রথম ধাপের হারে আরও প্রায় ২০০ × $০.০৯ = $১৮ (ফ্রি সীমা বাদ দিলে আরও কম)। দুটো connection-ওয়ালা highly available design-এ connection-এর অংশ দ্বিগুণ হয়ে $৭৩।

#VPN কোথায় শেষ হয়: VGW, transit gateway না Cloud WAN

অফিসের প্রান্ত সবসময় তোমার customer gateway। AWS-এর প্রান্ত হতে পারে:

• Virtual private gateway: একটা VPN পৌঁছায় একটা VPC-তে। সহজ, আর বেশিরভাগ পরীক্ষার প্রশ্ন এই design-ই বলে।
• Transit gateway: VPN একটা regional hub-এর attachment হয়ে যায়, আর transit gateway-র route table যতগুলো VPC (আর account)-তে যেতে দেয়, সবখানে পৌঁছায়। ECMP, IPv6 VPN, large bandwidth tunnel আর Accelerated VPN-এর জন্য এটাই লাগে (লেসন ২২.৬)।
• AWS Cloud WAN: একই ধারণা, তবে global আর policy দিয়ে চালানো network-এ; আপাতত পাশের কথা।

চালু থাকা একটা VPN connection-কে modify-vpn-connection দিয়ে VGW থেকে transit gateway-তে (বা আরেকটা VGW-তে) সরানো যায়; AWS নতুন endpoint বানানোর সময় connection অল্পক্ষণ বন্ধ থাকে, তারপর route table হালনাগাদ করে নাও।

#Accelerated Site-to-Site VPN

Acceleration চালু করলে AWS তোমার হয়ে দুটো Global Accelerator accelerator বানায়, প্রতি tunnel-এ একটা (লেসন ১১.৪)। তোমার tunnel-গুলো অফিসের সবচেয়ে কাছের edge location-এ AWS-এর network-এ ঢোকে, তারপর AWS-এর backbone ধরে Region-এ যায়, ভিড়ে ঠাসা অনেকগুলো internet hop পার হতে হয় না। দূরের বা দুর্বল সংযোগের site-এর জন্য latency অনেক স্থির হয়।

নিয়মগুলো:

• শুধু transit gateway-তে attach করা VPN connection-এর জন্য। VGW accelerated VPN সমর্থন করে না।
• চালু থাকা connection-এ চালু বা বন্ধ করা যায় না: নতুন connection বানাতে হয়।
• NAT-T লাগবেই (default-এ চালু), আর IKE শুরু করতে হবে তোমার device-কে।
• VPN-এর ঘণ্টার সাথে accelerator-এর খরচও দিতে হয়।

#AWS VPN CloudHub: AWS হয়ে ব্রাঞ্চ অফিসের কথাবার্তা

এটাই AWS VPN CloudHub: internet-এর ওপর দিয়ে সহজ আর কম খরচের একটা hub-and-spoke network, তোমার site-গুলোর মধ্যে মূল বা backup সংযোগের জন্য, VPC-তে কিছু থাকুক বা না থাকুক।

কীভাবে কাজ করে:

1. একটা VGW বানাও (VPC-তে attach করা থাকুক বা না থাকুক)।
2. প্রতিটা site-এর জন্য একটা customer gateway বানাও, প্রত্যেকের নিজের public IP আর আলাদা BGP ASN দিয়ে।
3. প্রতিটা customer gateway থেকে একই VGW-তে একটা dynamic routing-এর VPN connection বানাও।
4. প্রতিটা site BGP দিয়ে শুধু নিজের prefix জানায়। VGW যা শেখে, প্রতিটা route বাকি সব site-কে আবার জানিয়ে দেয়, ফলে প্রতিটা ব্রাঞ্চ বাকি সব ব্রাঞ্চকে চেনে, next hop হিসেবে VGW।
5. VPC-র instance-গুলোরও site-গুলোতে পৌঁছানো দরকার হলে route propagation চালু করো (সেখানে 10.0.0.0/8-এর মতো একটা বড় range দিলেও চলে)।

তিনটা শর্ত:

• প্রতিটা site-এ dynamic routing (BGP)।
• প্রতিটা customer gateway-র আলাদা BGP ASN। দুটো site-এর ASN এক হলে BGP-র loop ঠেকানোর নিয়মে একে অপরের route ফেলে দেয়, কারণ AS path-এ নিজের ASN দেখে।
• IP range-এ overlap চলবে না। দুই site-এর range এক হলে VGW-এর কাছে হুবহু দুটো route থাকে; এক অফিসের traffic গিয়ে পড়ে আরেক অফিসে।

খরচ: প্রতিটা site-এর সাধারণ VPN connection-ঘণ্টা (চারটা site = ৪ × ৭৩০ × $০.০৫ = মাসে $১৪৬), সাথে VGW থেকে কোনো site-এ নামা traffic-এর data transfer out। Site থেকে VGW-তে ওঠা ডেটা ফ্রি।

#AWS Client VPN: একটা site না, একটা laptop

Site-to-Site VPN জোড়ে network। কিন্তু মাঝে মাঝে জুড়তে হয় একজন মানুষকে: বাসায় বসা একজন developer, ক্লায়েন্টের অফিসে বসা একজন auditor। এর জন্য AWS Client VPN, একটা managed point-to-site VPN।

কীভাবে কাজ করে: endpoint-টা এক বা একাধিক subnet-এর সাথে associate করা থাকে (availability-র জন্য প্রতি AZ-এ একটা)। User connect করলে তোমার ঠিক করা একটা client CIDR range থেকে address পায়, আর তার traffic subnet-এ endpoint-এর network interface দিয়ে বের হয়, source হিসেবে ওই interface-এর address নিয়ে। Authorization rule ঠিক করে কোন group কোন range-এ যেতে পারবে, আর split tunnel ঠিক করে শুধু VPC-র traffic tunnel-এ যাবে, নাকি সবকিছু।

ওপরের team-এর এক মাসের খরচ: দুটো subnet association × ৭৩০ ঘণ্টা × $০.১০ = $১৪৬, সাথে ৬ জন × দিনে ৮ ঘণ্টা × ২২ দিন × $০.০৫ = $৫২.৮০। কেউ connect না থাকলেও association-এর অংশটা চার্জ হয়, তাই দরকার ফুরোলে endpoint মুছে দিও।

#কোথায় কোথায় গোলমাল হয়

• Tunnel up, কিছুই চলে না: subnet-গুলোর route table-এ route propagation (বা static route) নেই। Request পৌঁছায়, reply যায় NAT gateway-তে বা কোথাওই না।
• Ping যায় না, application চলে: security group (বা network ACL, লেসন ৩.৫) অফিসের range থেকে ICMP allow করে না।
• শুরু থেকেই দুটো tunnel down: router NAT-এর পেছনে থাকা সত্ত্বেও customer gateway-তে তার private IP দেওয়া; firewall UDP 500, UDP 4500 বা ESP আটকায়; pre-shared key, IKE version বা cryptography-র setting download করা configuration-এর সাথে মেলে না।
• AWS-এর maintenance-এর সময় সব বন্ধ: router-এ শুধু একটা tunnel সাজানো ছিল। দুটোই সাজাও আর নজরে রাখো (CloudWatch metric TunnelState, আর tunnel-এর কাজকর্মের log, যেটা AWS CloudWatch Logs-এ পাঠাতে পারে)।
• দুটো tunnel একসাথে পড়ে যায়: অফিসের একমাত্র router বা তার internet line গেছে। দ্বিতীয় line-এ দ্বিতীয় একটা customer gateway যোগ করো।
• বড় transfer আটকে যায়, ছোট request চলে: MTU আর MSS। Tunnel-এর MTU ১৪৪৬ byte; router-এ MSS ১৪০৬ বা তার কমে বেঁধে দাও।
• অফিসের কিছু subnet-এ পৌঁছানো যায় না: static routing-এ অফিসের নতুন range VPN connection-এ যোগ করা হয়নি; BGP-তে customer gateway VGW-কে ১০০-র বেশি prefix জানাচ্ছে, বাড়তিগুলো নেওয়া হচ্ছে না।
• অফিস VPC A-তে পৌঁছায়, peered VPC B-তে না: peering VPN-এর traffic সামনে নিয়ে যায় না (edge-to-edge routing নেই, লেসন ২২.১)। Transit gateway ব্যবহার করো।
• CloudHub-এর একটা ব্রাঞ্চে পৌঁছানো যায় না: কোনো site static routing-এ, কোনো BGP ASN দুইবার, বা কোনো range overlap করছে।
• VGW-তে যত connection-ই যোগ করো, throughput ১.২৫ Gbps-এর কাছে আটকে: VGW তোমার দিকে একটা tunnel-ই ব্যবহার করে। ECMP বা large bandwidth tunnel-ওয়ালা transit gateway-তে যাও।

#System design-এ এটা কীভাবে কাজে লাগে

• Migration-এর প্রথম ধাপ: VPN একই দিনে চালু হয়ে যায়, তাই server AWS-এ চলে গেলেও on-premises-এ থেকে যাওয়া system-এর সাথে কথা বলতে পারে; traffic বাড়লে পরে Direct Connect আসে (migration আর disaster recovery অধ্যায় ২৩-এ)।
• Direct Connect-এর backup: সবচেয়ে সস্তা দ্বিতীয় পথ। একই prefix-এ AWS Direct Connect-কে বেশি পছন্দ করে; তোমার দিকে BGP local preference বা AS path prepending দিয়ে Direct Connect-কে এগিয়ে রাখো (লেসন ২২.৫)।
• Hybrid DNS: on-premises server Route 53 Resolver endpoint দিয়ে private hosted zone resolve করে, আর সেই query-গুলো এই VPN দিয়েই যায় (লেসন ৮.৫)।
• অফিস থেকে AWS service-এ private পথে যাওয়া: VPN traffic-কে VPC-র ভেতর পর্যন্ত আনে; সেখান থেকে একটা interface endpoint S3 বা অন্য service-এ নিয়ে যায়। On-premises থেকে gateway endpoint ব্যবহার করা যায় না (লেসন ১০.১০ আর ২২.২)।
• অনেক VPC আর account: সব VPN একটা network account-এর একটা transit gateway-তে শেষ করো, আর RAM দিয়ে share করো (লেসন ২০.১, লেসন ২২.৬)।
• ব্রাঞ্চের network: হাতে গোনা কয়েকটা অফিস হলে একটা VGW-তে CloudHub; অনেক হলে transit gateway (বা নতুন VPN Concentrator)।
• দূরে বসা মানুষ: কর্মী আর contractor-দের জন্য SAML আর MFA-সহ Client VPN, group ধরে authorization rule।

#নিজে করে দেখো

# ১. AWS-কে অফিসের router চিনিয়ে দাও (dynamic routing, private ASN)
aws ec2 create-customer-gateway --type ipsec.1 \
  --public-ip 203.0.113.10 --bgp-asn 65010 \
  --tag-specifications 'ResourceType=customer-gateway,Tags=[{Key=Name,Value=gazipur-fw}]'
# { "CustomerGateway": { "CustomerGatewayId": "cgw-0c1d2e3f4a5b6c7d8", "BgpAsn": "65010",
#   "IpAddress": "203.0.113.10", "State": "available", "Type": "ipsec.1" } }

# ২. Virtual private gateway বানাও (Amazon-এর দিকের ASN) আর VPC-তে attach করো
aws ec2 create-vpn-gateway --type ipsec.1 --amazon-side-asn 64512
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-0a1b2c3d4e5f67890 \
  --vpc-id vpc-0a1b2c3d4e5f67890

# ৩. Dynamic routing আর শুধু IKEv2 দিয়ে VPN connection বানাও
aws ec2 create-vpn-connection --type ipsec.1 \
  --customer-gateway-id cgw-0c1d2e3f4a5b6c7d8 --vpn-gateway-id vgw-0a1b2c3d4e5f67890 \
  --options '{"StaticRoutesOnly":false,
    "TunnelOptions":[{"IKEVersions":[{"Value":"ikev2"}],"DPDTimeoutSeconds":40},
                     {"IKEVersions":[{"Value":"ikev2"}],"DPDTimeoutSeconds":40}]}'

# ৪. যে ধাপ সবাই ভুলে যায়: private subnet-এর route table-এ route propagation
aws ec2 enable-vgw-route-propagation \
  --route-table-id rtb-0d1e2f3a4b5c6d7e8 --gateway-id vgw-0a1b2c3d4e5f67890

# ৫. Instance-এর security group-এ অফিস থেকে ping allow করো
aws ec2 authorize-security-group-ingress --group-id sg-0e1f2a3b4c5d6e7f8 \
  --ip-permissions 'IpProtocol=icmp,FromPort=-1,ToPort=-1,IpRanges=[{CidrIp=192.168.0.0/16}]'

# ৬. Tunnel দেখো (download করা file দিয়ে router সাজানোর পর)
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0f1e2d3c4b5a69788 \
  --query "VpnConnections[].VgwTelemetry[].[OutsideIpAddress,Status,AcceptedRouteCount]" --output table
# |  198.51.100.21 |  UP   |  2 |
# |  198.51.100.87 |  UP   |  2 |

# ৭. Router-এর public IP বদলেছে: নতুন customer gateway, তারপর connection-কে সেদিকে দেখাও
aws ec2 create-customer-gateway --type ipsec.1 --public-ip 203.0.113.44 --bgp-asn 65010
aws ec2 modify-vpn-connection --vpn-connection-id vpn-0f1e2d3c4b5a69788 \
  --customer-gateway-id cgw-0a9b8c7d6e5f43210

তোমার device-এর configuration file পাবে console-এ VPN connection-এর ভেতর Download configuration-এ, অথবা aws ec2 get-vpn-connection-device-sample-configuration দিয়ে। এতে দুটো tunnel-এর <pre-shared-key> থাকে: গোপন জিনিসের মতো সামলাও। তারপর অফিসের একটা PC থেকে:

ping -c 3 10.0.1.20          # ৫ নম্বর ধাপের ICMP rule লাগবে
traceroute -n 10.0.1.20      # প্রথম hop তোমার router, তারপর tunnel: internet-এর hop-গুলো দেখা যায় না

#সারসংক্ষেপ

মূল কথা

• Site-to-Site VPN = পাবলিক internet-এর ওপর IPsec: encrypted, কয়েক মিনিটে চালু, প্রতি connection-ঘণ্টায় প্রায় $০.০৫ + data out, কিন্তু performance ওঠানামা করে। Direct Connect হলো private, স্থির, অর্ডার দিয়ে পেতে দেরি হওয়া বিকল্প।
• তিনটা resource: customer gateway (তোমার router-এর বর্ণনা: static public IP, বা NAT-T-সহ NAT device-এর IP; BGP ASN; চাইলে certificate), virtual private gateway (AWS-এর দিক, একটা VPC-তে attach করা, Amazon ASN default 64512 বা নিজের পছন্দের), আর VPN connection (দুটো tunnel)।
• Customer gateway edit করা যায় না: নতুন IP → নতুন customer gateway, তারপর VPN connection modify করো (বা নতুন বানাও)।
• Tunnel: UDP 500-এ IKE (pre-shared key বা certificate), encrypt করা packet বয়ে নেয় ESP, NAT-T থাকলে UDP 4500। MTU ১৪৪৬ byte।
• দুই AZ-এ দুটো tunnel AWS-এর দিকের সমস্যা আর maintenance সামলায়; দুটোই সাজাও। সর্বোচ্চ availability: দ্বিতীয় customer gateway + দ্বিতীয় VPN connection = ৪টা tunnel।
• Dynamic routing (BGP) best practice; static মানে দুই দিকে prefix হাতে লেখা। Subnet-এর route table-এ route propagation চালু করো আর ping-এর জন্য security group-এ ICMP allow করো: চিরচেনা দুই ফাঁদ।
• প্রতি tunnel-এ ১.২৫ Gbps; VGW তোমার দিকে একটা tunnel ব্যবহার করে। বেশি bandwidth: ECMP-ওয়ালা transit gateway, বা (২০২৫-এর শেষ থেকে) transit gateway বা Cloud WAN-এ ৫ Gbps-এর large bandwidth tunnel।
• VPN শেষ করো VGW-তে (একটা VPC) বা transit gateway-তে (অনেক VPC, ECMP, Accelerated VPN)। Accelerated VPN Global Accelerator-এর edge location ব্যবহার করে আর চলে শুধু transit gateway-তে।
• VPN CloudHub: অনেকগুলো site, একটা VGW, site-গুলো এর ভেতর দিয়ে একে অপরের সাথে কথা বলে; লাগে BGP, আলাদা ASN আর overlap ছাড়া range; সস্তা hub and spoke। সাথে অনেক VPC-ও থাকলে → Transit Gateway।
• Client VPN জোড়ে মানুষকে, network না: TLS/OpenVPN client, AD, certificate বা SAML দিয়ে পরিচয় যাচাই, authorization rule, split tunnel।

নিজেকে যাচাই করো: Site-to-Site VPN আর CloudHub৩০টি প্রশ্ন