দুটি সক্রিয় IPsec টানেলের এখনও ফেরত পথের পরিকল্পনা দরকার

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

রাউট আঁকার আগে চারটি গেটওয়ে আঁকুন

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

সেই টেবিলই নকশা। এর পরে সবকিছুই এই প্রশ্ন যে ডিভাইসগুলো টেবিলের সাথে একমত কি না।

সামনের পথ কীভাবে বেছে নেওয়া হয়

সমান-খরচের মাল্টিপাথ রাউটিং স্তর হেডার ফিল্ড হ্যাশ করে প্রবাহগুলোকে পরবর্তী হপে বিতরণ করে, যা RFC 2992 বিস্তারিত বর্ণনা করে। সেই নির্বাচন সম্পূর্ণ স্টেটহীন হতে পারে: এর কোনো সংযোগ-ট্র্যাকিং এন্ট্রি দরকার নেই, কেবল অপরিবর্তিত ফিল্ডের উপর একটি স্থির হ্যাশ দরকার। পথের সেট ও হ্যাশের ইনপুট স্থির রাখুন, তাহলে প্রবাহের প্রতিটি প্যাকেট একই পরবর্তী হপ বেছে নেবে।

প্রতি-প্রবাহ নির্বাচন ভিন্ন বিলম্বযুক্ত লিংকে প্যাকেট-বাই-প্যাকেট ব্যালান্সিংয়ের যে পুনর্বিন্যাস ঘটত তা এড়ায়। এটি প্রতিশ্রুতি দেয় না যে সমান রাউটিং খরচ মানে সমান পরিমাপকৃত বিলম্ব, কারণ তা নয়। আর পথের সদস্যতা বদলালে প্রবাহগুলো পুনরায় ম্যাপ হয়, তাই ব্যর্থতার সময় সংযোগ টিকে থাকা পথ নির্বাচন থেকে আলাদা একটি প্রয়োজন।

ফেরত পথের আসলে কী দরকার

এখানে হাঁটাপথটি আর প্রতিসম থাকে না। একটি স্থির সামনের হ্যাশ দূরবর্তী সাইট উত্তর নিয়ে কী করবে সে সম্পর্কে কিছুই বলে না। যদি একটি স্বাধীন ফায়ারওয়ালকে কার্যকর স্টেট রাখতে সংযোগের উভয় দিক দেখতে হয়, তাহলে তাকে এড়িয়ে যাওয়া একটি ফেরত রুট ট্রাফিককে কিছুর সাথেই মেলায় না। একই রকম নিয়মের দুটি বাক্স ভাগ করা স্টেট নয়।

বাস্তবায়িত দ্বিমুখী আচরণ নিশ্চিত করুন, অথবা প্রয়োজনীয় সীমাগুলো সামঞ্জস্যপূর্ণ রাখে এমন স্পষ্ট নীতি লিখুন। এখানে একটি অনুমান বিভ্রাটের সময়েই ধরা পড়ে, এমন মানুষের হাতে যারা এটি উপভোগ করছে না।

যেখানে অনুবাদ আপনার জন্য সিদ্ধান্ত নেয়

NAT হল অন্য লিভার, এবং এটি বাধ্যতামূলক নয় বরং ঐচ্ছিক। পথ-নির্দিষ্ট অনূদিত পরিচয় উত্তরগুলোকে স্টেট ধরে রাখা গেটওয়ের দিকে ফিরিয়ে দিতে পারে, যা একটি বৈধ নকশা। তারা ম্যাপিং, ফেরত রুট এবং সেই স্টেটের একজন মালিকও যোগ করে, তাই ভারটি কেবল এমন একটি প্রয়োজনের জন্য গ্রহণ করুন যা আপনি উচ্চস্বরে বলতে পারেন।

যদি প্রয়োজন কেবল এই হয় যে দুটি পথই ট্রাফিক বহন করবে এবং যেকোনো একটি ISP হারানো সত্ত্বেও টিকে থাকবে, তাহলে সামঞ্জস্যপূর্ণ ফেরত রাউটিংসহ সাধারণ প্রতি-প্রবাহ মাল্টিপাথই সাধারণত ছোট নকশা।

গ্রহণযোগ্যতা ধারাবাহিকভাবে হেঁটে দেখুন

এই ক্রমে পরীক্ষা করুন এবং প্রতিটি ধাপে ঠিকানাগুলো লিপিবদ্ধ করুন: পথ A-তে একটি নতুন সংযোগ ও তার ফেরত পথ, পথ B-তে একই, তারপর একটি ISP হারানো, তারপর পুনরুদ্ধার। প্রতিটি ফলাফলের জন্য লক্ষ্য করুন কোন প্রতিষ্ঠিত প্রবাহ সরে গেছে, কোনগুলোকে পুনরায় সংযোগ করতে হয়েছে এবং নতুন প্রবাহগুলো পরে কোথায় গেছে। প্রত্যাশিত মানটি আগে লিখে রাখুন, তারপর ক্যাপচারের সাথে মিলিয়ে দেখুন। দুটি প্রতিষ্ঠিত টানেল এর কিছুই প্রমাণ করে না।

আপনি লেখা টেবিলটি ক্যাপচার যা দেখায় তার সাথে মিললে নকশা সম্পূর্ণ, দুটি টানেল চালু থাকলেই নয়।