Azure NVA পরিদর্শন: উত্তরটি কেন আরেকটি ফায়ারওয়াল দিয়ে যায়
Route Server দুটি সমান পথ দেয়, আর কিছুই না। উত্তর যখন ভিন্ন অ্যাপ্লায়েন্স বেছে নেয়, সেই সেশনের সেখানে কোনো স্টেট থাকে না এবং ফ্লোটি মারা যায়।
শাখা থেকে Azure-এ একটি ফ্লো দুই দিকেই সঠিকভাবে রাউট হতে পারে এবং তবুও ব্যর্থ হতে পারে, কারণ দুই দিক ভিন্ন অ্যাপ্লায়েন্স নেয়। অনুরোধটি VPN-এর ওপর দিয়ে শাখা ছাড়ে, NVA A-তে পৌঁছে ওয়ারকলোডে পৌঁছায়। উত্তরটি ওয়ারকলোড ছাড়ে, NVA B-এর দিকে নির্দেশ করা একটি রুটের সঙ্গে মিলে এবং সেখানেই মারা যায়। সেই চিত্রের প্রতিটি রুট বৈধ, আর TCP সেশনটি তবুও ভাংা।
Request: branch -> VPN gateway -> NVA A -> workload
Reply: workload -> NVA B -> VPN gateway -> branch
এই ফাঁকই এখানে পুরো বিষয়: রাউটিং কনভার্জেন্স এবং সেশন-স্টেটের মালিকানা ভিন্ন সমস্যা, যা ডায়াগ্রামে একই রকম দেখায়।
Route Server আসলে কী প্রোগ্রাম করে
Azure Route Server সমর্থিত BGP স্পিকারদের সঙ্গে পিয়ার করে, তাদের রুট শেখে এবং সেগুলো ভার্চুয়াল নেটওয়ার্কের কার্য়কর রুটে প্রোগ্রাম করে। এটি একটি কন্ট্রোল-প্লেন কাজ। এটি কোনো ভেন্ডর ফায়ারওয়ালের সেশন টেবিল পড়ে না, এবং কোন অ্যাপ্লায়েন্স একটি নির্দিষ্ট সংযোগ গ্রহণ করেছে তা জানে না। দুটি সমান-খরচের নেক্সট হপ এই ফ্যাব্রিকের কাছে একই প্রিফিক্সে পৌঁছানোর মাত্র দুটি উপায়, এবং এটি যেকোনটি ব্যবহার করবে।
তাই একটি রুট শেখা পৌঁছানোর ক্ষমতা প্রমাণ করে। অন্য প্রান্তের ডিভাইসটি আগে এই ফ্লো দেখেছে কিনা, সে বিষয়ে এটি কিছুই প্রমাণ করে না।
নকশা করার আগে দুই দিক পড়ুন
প্রতিটি দিকে আপনার প্রকৃত স্টিয়ারিং লিখে শুরু করুন, আপনি যা চেয়েছিলেন তা নয়। আরও নির্দিষ্ট BGP রুট, ব্যবহারকারী-নির্ধারিত রুট এবং গেটওয়ে আচরণ সবই প্রতিযোগিতা করে, এবং বিজয়ী নির্ধারিত হয় প্রতি গন্তব্যে, প্রতি সেশনে নয়। NVA-তে একটি ডিফল্ট রুট এর অর্থ নয় যে প্রতিটি ব্যক্তিগত প্রিফিক্স তার মধ্য দিয়ে যায়।
একটি কার্যকর যাচাই হলো একটি নির্দিষ্ট ওয়ারকলোড IP-এর জন্য জিজ্ঞাসা করা, প্রতিটি দিক কোন নেক্সট হপে সমাধান হয়। উত্তর যদি দুটি ভিন্ন অ্যাপ্লায়েন্স হয়, তাহলে আপনার অসমতা সমস্যা আছে, তা ইতিমধ্যে প্রকাশ পেয়েছে কিনা তা নির্বিশেষে।
স্টেট কোথায় থাকে
একটি স্টেটফুল ফায়ারওয়াল একটি সংযোগ গ্রহণ করে এবং পাঁচ-টুপল দিয়ে কী করা একটি টেবিল এন্ট্রি রাখে। উত্তরটিকে সেই এন্ট্রি ধারণকারী ডিভাইসে পৌঁছতে হবে, নয়তো সেই ডিভাইসকে অন্য উপায়ে স্টেট পেতে হবে। Azure ডেটা প্লেনে কিছুই এন্ট্রিটি অ্যাপ্লায়েন্সগুলোর মধ্যে ফরওয়ার্ড করে না। হয় ট্রাফিক মালিকের কাছে ফিরিয়ে স্টিয়ার করা হয়, নয়তো অ্যাপ্লায়েন্সগুলো ভেন্ডর প্রক্রিয়ার মাধ্যমে স্টেট শেয়ার করে, নয়তো নকশাটি কাজ করে না।
এজন্যই দুটি সুস্থ NVA পরিদর্শনের জন্য স্বাস্থ্য-যাচাই নয়। স্বাস্থ্য পৌঁছানোর ক্ষমতা নিয়ে; পরিদর্শন কোন ইনস্ট্যান্স সেশনটি ধরে আছে তা নিয়ে।
সমর্থিত HA মডেল এবং প্রত্যেকটি কী প্রতিশ্রুতি দেয়
Microsoft's guidance on Virtual WAN রাউটিং ইনটেন্ট নিয়ে Microsoft-ের নির্দেশনা দ্বৈত-ভূমিকা সংযোগ এবং ফায়ারওয়াল NVA-র জন্য সীমিত আচরণ বর্ণনা করে, যেখানে সরাসরি রাউটিং হাবের স্বাভাবিক সিমেট্রিক প্রয়োগ বাইপাস করতে পারে। সেই নোটগুলোকে আপনার বেছে নেয়া টপোলজির উপর সীমাবদ্ধতা হিসেবে পড়ুন, সক্রিয়-সক্রিয় নকশার নিষেধাজ্ঞা হিসেবে নয়। যে ভেন্ডর জোড়া স্টেট সিঙ্ক্রোনাইজ করে বা প্রতি ফ্লোতে স্টিয়ার করে, তা সমর্থিত হতে পারে। যে সমান-খরচের জোড়া কোনোটিই করে না, তা নয়।
তারপর নির্ধার্ণ করুন নোড ব্যর্থ হলে বিদ্যমান সেশনগুলোর কী হয়। রুট কনভার্জেন্স কয়েক সেকেন্ডের মধ্যে নতুন ফ্লোর জন্য পৌঁছানোর ক্ষমতা ফিরিয়ে দেয়, আর পুরোন ফায়ারওয়াল স্টেট কেবল চলে যায়। ক্লায়েন্ট পুনঃসংযোগ নথিভুক্ত ফলাফল হতে পারে, এবং এটি ঘটনার আগে নেয়া সিদ্ধান্ত, ঘটনার সময়ে নয়।
আস্থা রাখার আগে কী পরীক্ষা করবেন
Test with inspection enabled and ওয়ারকলোডের অ্যাক্সেস নীতি জায়গায় রেখে পরীক্ষা করুন, কারণ দুটির যেকোনটি অসমতা লুকাতে পারে। দুই দিকে একটি নতুন অনুমোদিত ফ্লো পাঠান এবং নিশ্চিত করুন একই অ্যাপ্লায়েন্স দুই অর্ধেকই দেখেছে। তারপর অবিরাম ট্রাফিক চালান এবং অনুমোদিত ফেইলওভার ট্রিগার করুন, প্রতিষ্ঠিত সেশনগুলো টিকে থাকে নাকি পুনঃসংযোগ করে তা লক্ষ্য করুন।
প্রতিটি ফ্লোকে যে অ্যাপ্লায়েন্স এটি পরিচালনা করেছে তার সঙ্গে সম্পর্কিত করুন। একটি NVA-তে প্যাকেট ক্যাপচার প্রায় কিছুই বলে না যদি উত্তর কদোনো সেখানে ফিরে না আসে।
শেষে, পরিকল্পনাটি তিনটি আলাদা লাইনে লিখুন: রুটের মালিকানা, ট্রাফিক স্টিয়ারিং এবং সেশন-স্টেটের মালিকানা। প্রথম দুটি সমাধান হয়ে গেলে এবং তৃতীয়টি ধরে নেয়া হলে নকশা ভেঙে যায়।