দুটি IPsec গেটওয়ে, কোনো সাধারণ IP নেই: ফেলওভার আসলে কী করে

মিটিংয়ের মাঝে গেটওয়ে A বন্ধ করুন এবং এক মিনিট পরে টানেলটি B দিয়ে ফিরে আসতে দেখুন; সংযোগ কাজ করে, ভিডিও কল নাও করতে পারে। স্বাধীন ঠিকানার দুটি IPsec গেটওয়ের মধ্যে কোল্ড ফেলওভারের এটাই সৎ রূপ। ক্লায়েন্ট একটি এন্ডপয়েন্ট আবার বেছে নেয় এবং নতুন সম্পর্ক তৈরি করে, যা পুরোনো সেশনের ক্রিপ্টোগ্রাফিক অবস্থা না সরিয়েও পৌঁছানোর ক্ষমতা ফিরিয়ে দেয়। ক্রমটি অনুসরণ করলে স্পষ্ট হয় ডিজাইন কোন প্রতিশ্রুতি রাখতে পারে।

দৃশ্যপট তৈরি করুন: দুটি ঠিকানা, কোনো ফ্লোটিং IP নেই

গেটওয়ে A একটি পৌঁছানো যায় এমন ঠিকানায় উত্তর দেয় এবং গেটওয়ে B অন্য একটিতে। A চলে গেলে B বেছে নেওয়ার একটি অনুমোদিত উপায় ক্লায়েন্টের আছে, এবং দুটি গেটওয়ে দাবি করে এমন কোনো সাধারণ বাইরের ঠিকানা নেই। এই ডিজাইনে ভার্চুয়াল IP বলতে সেই সাধারণ প্রবেশ বিন্দুকে বোঝায়, রিমোট-অ্যাক্সেস ক্লায়েন্টকে দেওয়া ভেতরের ঠিকানা নয়।

এই সংজ্ঞাটি গুরুত্বপূর্ণ কারণ দুটি ধারণা টিকিটে মিশে যায়, আর একটির সমাধান অন্যটির সমাধান নয়। সাধারণ প্রবেশ বিন্দু গেটওয়ে অনুসরণ করেনি — এমন প্রতিবেদন একটি ডিজাইন বর্ণনা করে। ল্যাপটপ তার ভেতরের ঠিকানা হারিয়েছে — এমন প্রতিবেদন ক্লায়েন্টের লিজ বর্ণনা করে। আলাদা মালিক, আলাদা লগ, আলাদা মেরামত।

ব্যর্থতা অনুসরণ করুন: শনাক্ত করুন, তারপর আবার বাছুন

প্রথমে কিছু একটা লক্ষ্য করে যে A উত্তর দেওয়া বন্ধ করেছে। এটি টানেল স্তরে ডেড পিয়ার ডিটেকশন হতে পারে, কোনো রাউটিং প্রোটোকল পথ প্রত্যাহার করতে পারে, বা কোনো অ্যাপ্লিকেশন টাইমআউট শেষে পুনঃসংযোগে বাধ্য করতে পারে। প্রতিটির সময়পরিমাপ আলাদা, এবং সবচেয়ে ধীরটি সাধারণত ঠিক করে ব্যবহারকারীরা কতক্ষণ অপেক্ষা করবে।

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

B কী উত্তরাধিকার পায় আর কী পায় না

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

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

নতুন সম্পর্ক প্রতিষ্ঠা করা

B নির্বাচিত হলে ক্লায়েন্ট নতুন IKE বিনিময় করে: নতুন nonce, নতুন Diffie-Hellman মান, ফলাফল সংযুক্তির জন্য নতুন শনাক্তকারী। B-তে আবার প্রমাণীকরণ হয়। ডিজাইন যদি মেশিন ক্রেডেনশিয়ালের উপর নির্ভর করে, পুনঃসংযোগ মনুষ্য-নিরীক্ষণহীন হতে পারে; যদি মানব উপাদান প্রয়োজন হয়, ফেলওভার সম্পূর্ণ করতে কাউকে উপস্থিত থাকতে হবে।

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

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

সমান্তরালে দুটি টানেল ভিন্ন ডিজাইন

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

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

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