AWS Transit Gateway-তে একাধিক VPC-এর জন্য একটি সাইট-থেকে-সাইট VPN

এই প্রান্তিকে দুটি VPC-এর অফিস নেটওয়ার্ক দরকার, আর দ্বিতীয় টানেলেই হিসাব ভেঙে পড়ে। AWS Transit Gateway একটি ভাগ করা রাউটিং হাব হিসেবে কাজ করতে পারে: VPN একবার সংযুক্ত হয়, এবং প্রতিটি VPC একই হাবে সংযুক্ত হয়। এরপর অন-প্রিমাইজ নেটওয়ার্ক একটি সংযোগ দিয়েই সব সংযুক্ত VPC-তে পৌঁছায়। এটি বদলে দেয় রাউটিং সিদ্ধান্ত কার, আর বেশিরভাগ ডিজাইন ভুল করে ঠিক এই জায়গাতেই।

VPN অ্যাটাচমেন্ট আর VPC অ্যাটাচমেন্টগুলো একই গেটওয়ের আলাদা অবজেক্ট, তাই রাউটিং সম্পর্কগুলো পরে গড়ে তুলতে হয়।

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

কেন পিয়ারিং মানুষ যে শর্টকাট আশা করে তা নয়

প্রলুব্ধকর বিকল্পটি হলো VPC A-তে VPN শেষ করে VPC B-কে তার সঙ্গে পিয়ার করা। সাধারণ VPC পিয়ারিং A-এর VPN সংযোগের মধ্য দিয়ে এজ-টু-এজ ট্রানজিট দেয় না। পিয়ার শুধু সেই ঠিকানাগুলোতে পৌঁছায় যা পিয়ারিং নিজেই দেয়, আর VPN এজ সেগুলোর একটি নয়। ট্রানজিট আসে হাব থেকে; পিয়ারিং আপনাকে দেয় একটি জোড়া।

এই সীমাবদ্ধতা পিয়ারিংয়ের বৈশিষ্ট্য, এমন কোটা নয় যা আপনি বাড়াতে পারবেন।

অ্যাসোসিয়েশন ও প্রোপাগেশন ভিন্ন কাজ করে

ট্রানজিট গেটওয়ের ভেতরে অ্যাসোসিয়েশন ঠিক করে কোন রুট টেবিল দিয়ে অ্যাটাচমেন্ট থেকে আসা ট্রাফিক খোঁজা হবে। প্রোপাগেশন ঠিক করে কোন টেবিলগুলো কোনো অ্যাটাচমেন্টের শেখা বা সংযুক্ত প্রিফিক্স পাবে। একটি অ্যাটাচমেন্ট একটি টেবিলের সঙ্গে অ্যাসোসিয়েট হয়ে একাধিক টেবিলে প্রোপাগেট করতে পারে। দুটিকে গুলিয়ে ফেলাই এমন নাগাল তৈরি করে যা কেউ পরিকল্পনা করেনি।

সম্পূর্ণ সংযুক্ত ছোট হাব সহজ কেস।

প্রতিটি অ্যাটাচমেন্ট একটি টেবিলে রাখুন, তাহলে VPN আর দুই VPC প্রিফিক্স পরিষ্কারভাবে সমাধান হয়। এটি VPC-থেকে-VPC নাগালও অনুমোদন করে যা প্রতিষ্ঠান হয়তো কখনো চায়নি, কারণ ভাগ করা টেবিলের স্পোকের ধারণা নেই।

ওয়ার্কলোড রুট থাকে অন্য জায়গায়

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

ডাইনামিক বা স্ট্যাটিক রাউটিং সচেতনভাবে বেছে নিন; পিয়ারিং কোনোটিই দেয় না।

অন-প্রিমাইজ অ্যাক্সেস না হারিয়ে স্পোক আলাদা করুন

যখন A আর B দুটোই অফিসে পৌঁছাতে পারে কিন্তু একে অপরের দিকে রাউট হতে পারবে না, তখন টেবিল ভাগ করুন। VPN অ্যাটাচমেন্টের অ্যাসোসিয়েটেড টেবিলে থাকে VPC প্রিফিক্স। VPC অ্যাটাচমেন্টগুলোর অ্যাসোসিয়েটেড টেবিলে থাকে অন-প্রিমাইজ প্রিফিক্স, আর A-কে B-এর সঙ্গে জোড়া দেওয়া কোনো রুট নেই। প্রোপাগেশনই ওই সম্পর্ক তৈরি করে, তাই সব ডিফল্ট অ্যাসোসিয়েশন আপনাকে গ্রহণ করতে হয় না।

এটি রাউটিং বিচ্ছিন্নতা, আর এটি অ্যাপ্লিকেশন অনুমোদন নয়।

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

হাব যা ঠিক করে না

অ্যাড্রেস প্ল্যান এখনও ওভারল্যাপ-মুক্ত থাকতে হবে, কারণ হাব এক প্রিফিক্সকে দুটি ওয়ার্কলোড চিহ্নিত করতে দেয় না। প্রতিটি VPC অ্যাটাচমেন্টের তার ওয়ার্কলোড যে Availability Zone কভারেজ আশা করে তা দরকার। BGP-র সঙ্গে, কাস্টমার ডিভাইসের প্রতিটি প্রয়োজনীয় প্রিফিক্সে ফেরার রুট ডিজাইন ও তার ইমপোর্ট পলিসির সঙ্গে মিলতে হবে। অনুপস্থিত বিজ্ঞাপন দেখতে ঠিক ভাঙা টানেলের মতো।

VPN সংযোগ আর ট্রানজিট গেটওয়ে এখন ভাগ করা অবকাঠামো।

টানেল রিডান্ডেন্সি পরিকল্পনা করুন, ডিভাইস ক্ষমতা, মনিটরিং ও রক্ষণাবেক্ষণ সব নির্ভরশীল VPC-কে ঘিরে, প্রতিটিকে স্বতন্ত্রভাবে সংযুক্ত ভাবার বদলে।

বিদ্যমান virtual private gateway ব্যবস্থা থেকে মাইগ্রেশনও একই স্পষ্ট পরিকল্পনা দাবি করে। অ্যাটাচমেন্ট আর পলিসি গড়ুন, একটি নিয়ন্ত্রিত ওয়ার্কলোড পথ সরান, এবং পুরোনো পথ অবসর দেওয়ার আগে অনুমোদিত ও অস্বীকৃত সম্পর্ক নিশ্চিত করুন। কেন্দ্রীকরণ সাহায্য করে যখন নেটওয়ার্ক দলকে ভাগ করা সংযোগ পরিচালনার এক জায়গা দেয়, আর ক্ষতি করে যখন একটি বড় টেবিলের পেছনে কে কার কাছে পৌঁছাতে পারে তা লুকিয়ে রাখে।