AWS থেকে Azure সাইট VPN: আগে ফেরত-রুট লিখুন
সংযুক্ত ক্রস-ক্লাউড টানেল কিছুই প্রমাণ করে না যতক্ষণ প্রতিটি ওয়ার্কলোড সাবনেট দূরের প্রিফিক্সে রুট না করে। পরিকল্পনা ক্রমে করুন, তারপর সার্ভিস পরীক্ষা করুন।
টানেল উঠবে। সাধারণত ওঠে, কারণ IKE-র শুধু মিলতে থাকা প্রস্তাব আর পৌঁছানো যায় এমন পিয়ার ঠিকানা দরকার। এরপর যা ব্যর্থ হয় তা হলো ফেরার পথ: AWS ওয়ার্কলোড টানেলে প্যাকেট পাঠায়, কিন্তু Azure দিকে কেউ জানে না 10.10.0.0/16-এ কীভাবে উত্তর দিতে হবে, অথবা Azure রুটটি এমন টেবিলে আছে যা ওয়ার্কলোড সাবনেট ব্যবহার করে না। কোনো কনসোল ছোঁয়ার আগেই রুট পরিকল্পনা লিখুন, তাহলে টানেল কাজের সবচেয়ে কম আকর্ষণীয় অংশ হয়ে যাবে।
ধাপ 1: ঠিকানা পরিকল্পনা স্থির করুন
নির্দিষ্ট মান নিয়ে কাজ করুন। একটি AWS ওয়ার্কলোড 10.10.0.0/16-এর ভিতরে 10.10.1.20-এ আছে এবং 10.20.0.0/16-এর ভিতরে 10.20.1.30-এ থাকা Azure সার্ভিসে TCP 443 দরকার। দুটি রেঞ্জ ওভারল্যাপ করা যাবে না, এবং গ্রহণযোগ্যতার পরীক্ষা টানেল নয়, সার্ভিস জোড়া।
এই চারটি তথ্য আগে লিখে রাখুন, কারণ পরে প্রতিটি ধাপ এর বিরুদ্ধে যাচাই হয়।
ধাপ 2: প্রতিটি প্রান্তের মালিক গেটওয়ের নাম দিন
AWS Site-to-Site VPN একটি ভার্চুয়াল প্রাইভেট গেটওয়ে বা ট্রানজিট গেটওয়েতে শেষ হতে পারে, আর এরা আলাদা রাউটিং মালিক। Azure তার ম্যানেজড VPN Gateway দেয় এবং আলাদাভাবে গ্রাহকদের নিজের চালানো VM-ভিত্তিক অ্যাপ্লায়েন্স। কোন জোড়া আছে তা লিখে রাখুন, কারণ প্রতিটি সমন্বয়ে পরের হপ আলাদা।
ম্যানেজড গেটওয়ের জন্য অনুমান করা প্রাইভেট অ্যাপ্লায়েন্স ঠিকানায় যাওয়া রুট কপি করবেন না। অ্যাপ্লায়েন্সের জন্য ধরে নেবেন না যে ক্লাউড রুট প্রোপাগেশন গেস্ট অপারেটিং সিস্টেম কনফিগার করে, কারণ তা করে না।
এখানে ভুল করলে এমন পরিকল্পনা হয় যা সম্পূর্ণ দেখায় এবং প্যাকেটকে এমন ঠিকানায় পাঠায় যা কখনো উত্তর দেয় না।
ধাপ 3: প্রতিটি ওয়ার্কলোড আসলে যে রুট ব্যবহার করে তা লিখুন
নিচের প্রতিটি সীমানা আলাদা লুকআপ, আর তার একটিতে থাকা রুট প্যাকেটের জন্য রুট নয়। টানেল চালু হওয়ার আগে টেবিলটি নিজের মান দিয়ে পূরণ করুন।
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS-এ ওয়ার্কলোড সাবনেটের রুট টেবিল আপনাকেই আপডেট করতে হয়, এমনকি BGP বা টানেল সুস্থ হওয়ার পরেও; রাউটিং ওভারভিউ এটিকে সংযোগের অংশ ধরে। Azure-এ ব্যবহারকারী-নির্ধারিত রুট টেবিল ভার্চুয়াল নেটওয়ার্কের সঙ্গে নয়, সাবনেটের সঙ্গে যুক্ত হয়, তাই VNet ব্লেডে নয়, ওয়ার্কলোড NIC-তে কার্যকর রুট দেখুন।
ম্যানেজড Azure গেটওয়ে গেটওয়ে প্রোপাগেশনের মাধ্যমে দূরের প্রিফিক্স শিখতে পারে, আর একটি UDR সেই সিদ্ধান্ত বাতিল করতে পারে। কারণ থাকলে UDR যোগ করুন, অভ্যাসবশত নয়। যোগ করলে অ্যাপ্লায়েন্স ঠিকানা বানানোর বদলে গেটওয়ে VPN পথের জন্য যে পরের হপ প্রকাশ করে সেদিকে নির্দেশ করুন। তারপর NIC-তে কার্যকর রুট আবার পড়ুন, কারণ সিদ্ধান্ত আসলে NIC-তেই হয়।
ধাপ 4: পরিধি মিলিয়ে নিন
BGP-র জন্য প্রতিটি পক্ষ কী ঘোষণা করে তা অন্য পক্ষ আসলে কী শিখেছে তার সঙ্গে প্রিফিক্স ধরে ধরে তুলনা করুন। স্ট্যাটিক রাউটিংয়ের জন্য কনফিগার করা দূরের রেঞ্জগুলো ধাপ 3-এ লেখা ওয়ার্কলোড রুটের সঙ্গে তুলনা করুন।
ক্রিপ্টোগ্রাফিতে একমত হওয়া IKE সম্পর্ক প্রমাণ নয় যে কোনো পক্ষ 10.10.0.0/16 বা 10.20.0.0/16 শিখেছে। দুটি টানেল চালু থাকতে পারে অথচ এক পক্ষ আপনার পরিকল্পিত /16-এর বদলে একটি /24 ঘোষণা করছে। প্রিফিক্স টানেল স্টেটাসে নয়, রাউটিং টেবিলে দেখুন। অমিল পরে একটি কাজ করা সাবনেট আর একটি কখনো উত্তর না দেওয়া সাবনেট হিসেবে দেখা যায়।
ধাপ 5: আসল উৎস থেকে সার্ভিস পরীক্ষা করুন
AWS সিকিউরিটি গ্রুপ ও নেটওয়ার্ক ACL-এ, Azure NSG-তে এবং পথের যেকোনো অ্যাপ্লায়েন্স ফিল্টারে অভিপ্রেত ফ্লো অনুমোদন করুন। তারপর 10.10.1.20 থেকে অনুমোদিত সার্ভিস ঠিকানা ও পোর্টে একটি সংযোগ খুলে নিশ্চিত করুন উত্তরটি সেই একই উৎসে ফিরে আসছে।
ক্লাউড সিকিউরিটি গ্রুপ আর NSG দুটোই stateful, তাই প্রত্যাখ্যাত ফেরত প্যাকেট রাউটিংয়ের লক্ষণ, বিপরীত দিকে লেখা ভুলে যাওয়া নিয়ম নয়।
যেকোনো গেটওয়ে থেকে ping কিছুই ঠিক করে না। গেটওয়ে ঠিকানায় ICMP কন্ট্রোল প্লেন পথ চালায়, ওয়ার্কলোডের দরকারি ফরওয়ার্ডেড TCP সার্ভিস নয়।
রোলব্যাক ও রেকর্ড
টানেল আইডেন্টিফায়ারের পাশে রুট মালিকদের লিখে রাখুন এবং পরিবর্তনের আগের রুট টেবিল সংরক্ষণ করুন। পরিবর্তন সরাতে হলে টানেল ভাঙার আগে ওয়ার্কলোড রুটগুলো সরান, যাতে কোনো সাবনেট আর বিদ্যমান নেই এমন পরের হপে না তাকিয়ে থাকে।
তখন পরে সাবনেট সরানো বা spoke সংযুক্তিতে আপডেট করার একটি নির্দিষ্ট জায়গা থাকে, যে রুটের মালিক সে কখনো ছিল না তার দোষ বহন করা একটি চালু টানেলের বদলে।