দ্বিতীয় WAN VPN এন্ট্রি ব্যর্থ হয়, প্রাথমিকটি এখনও কাজ করে

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

প্রতিটি WAN-এর নিজস্ব এন্ট্রি চুক্তি দরকার

প্রতি WAN-এ পাঁচটি ক্ষেত্র লিপিবদ্ধ করুন: পাবলিক নাম ও ঠিকানা, ট্রান্সপোর্ট ও পোর্ট, যে ইন্টারফেস বা কনটেক্সট এটি সমাপ্ত করে, যে পিয়ার পরিচয় এটি উপস্থাপন করবে, এবং উত্তর কোথা দিয়ে বেরোয়। দুটি সার্কিট মানে দুটি সম্পূর্ণ সেট। যদি দ্বিতীয় সেটে কোনো সমাপ্তকারী ইন্টারফেস বা ফেরত পথ না থাকে, তবে আপনার ব্যাকআপ এন্ট্রি নেই; আপনার আছে একটি DNS রেকর্ড যা একটি অভিপ্রায় বর্ণনা করে।

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

দ্বিতীয় WAN সত্যিই উত্তর দেয় কি না যাচাই করুন

দুটি সার্কিটের বাইরে থেকে পরীক্ষা করুন, গেটওয়ের পেছনের মেশিন থেকে নয়, এবং ক্লায়েন্ট প্রোফাইল যে সঠিক নাম ব্যবহার করে সেটিই পরীক্ষা করুন। TLS লিসেনারের জন্য দ্রুত যাচাই হলো openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts যা আপনার নেটওয়ার্কের বাইরের একটি হোস্ট থেকে চালানো হয়। আপনি চান একটি সম্পূর্ণ হ্যান্ডশেক যার চেইন প্রোফাইলের নামের সাথে মেলে, শুধু একটি TCP পোর্ট যা সংযোগ গ্রহণ করে তা নয়।

RFC 9525 ব্যাখ্যা করে ক্লায়েন্ট কী যাচাই করে: যে পরিচয়ে পৌঁছাতে চেয়েছিল, তার সঙ্গে সেবা যে সার্টিফিকেট উপস্থাপন করে তার তুলনা। দ্বিতীয় এন্ট্রি যা প্রাথমিক এন্ট্রির সার্টিফিকেট ফেরত দেয়, বা একটি ডিফল্ট সার্টিফিকেট যাতে কোনো নামই তালিকাভুক্ত নয়, এই পরীক্ষায় ব্যর্থ হয় যদিও পোর্ট খোলা এবং ফায়ারওয়াল তা অনুমোদন করে।

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

উত্তর অনুসরণ করুন, শুধু অনুরোধ নয়

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

দ্বিতীয় এন্ট্রি থেকে উৎপন্ন ট্রাফিকের রাউটিং সিদ্ধান্ত যাচাই করুন। উত্তরটি যে ইন্টারফেসে অনুরোধ এসেছে সেখান দিয়েই বেরোনো উচিত, বা অন্তত এমন ঠিকানা বহন করা উচিত যা দূর পক্ষ ওই পথের অংশ হিসেবে গ্রহণ করে। পলিসি-রাউটিং প্ল্যাটফর্মে এর মানে হলো ইনকামিং ইন্টারফেস বা ট্রান্সলেটেড সোর্সে বাঁধা একটি নিয়ম, সাথে প্রতিটি বাইরের ইন্টারফেসে বাঁধা একটি ট্রান্সলেশন স্টেটমেন্ট। ক্লায়েন্ট সংযোগ করার সময় একসাথে দুই ইন্টারফেসে ক্যাপচার করুন; ISP B-তে আসা SYN আর ISP A দিয়ে বেরোনো SYN-ACK এক চালাতেই প্রশ্নটির মীমাংসা করে।

ক্লায়েন্টকে দ্বিতীয় এন্ট্রি সম্পর্কে জানার উপায় দিন

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

প্রক্রিয়া যাই হোক, প্রাথমিক পথ হারানোর আগেই ক্লায়েন্টকে বিকল্প নামটি রিজলভ করতে সক্ষম হতে হবে। এই নির্ভরতাটিই মানুষ মিস করে: যদি ব্যাকআপ নামের উত্তর দেয় এমন রিজলভার কেবল সেই টানেল দিয়েই পৌঁছায় যা এইমাত্র ব্যর্থ হয়েছে, তবে ফলব্যাক শুরুই হতে পারে না। দ্বিতীয় নামটি এমন রিজলভারে প্রকাশ করুন যা স্থানীয়ভাবে বা ইন্টারনেট দিয়ে উত্তর দেয়। স্থানান্তরের পরে নতুন প্রমাণীকরণ ও নতুন অ্যাপ্লিকেশন সেশন আশা করুন, কারণ ক্লায়েন্ট ফেইলওভার স্টেটফুল ফেইলওভার নয় এবং দীর্ঘস্থায়ী সেশন এটি টিকে না।

দুই প্রোভাইডারে একটি ঠিকানা ভিন্ন একটি পণ্য

একটি পাবলিক ঠিকানা দুই সার্কিট দিয়েই পৌঁছানোর যোগ্য রাখা একটি রাউটিং সেবা, VPN-এর একটি চেকবক্স নয়। এর জন্য দুই প্রোভাইডার যে ঠিকানা স্থান বহনে রাজি, তা তাদের নেটওয়ার্ক যেভাবে গ্রহণ করে সেভাবে ঘোষণা করা দরকার, আর প্রোভাইডার-নিরপেক্ষ স্থান ও BGP নিয়ে মাল্টিহোমিং ঠিক তা-ই দেয়। ISP A-এর ঠিকানা ISP B-এর ইন্টারফেসে বসালে তা হয় না; প্যাকেটটি এমন নেটওয়ার্কে পৌঁছায় যা প্রিফিক্সটি কখনও ঘোষণা করেনি এবং আপস্ট্রিমে ফেলে দেওয়া হয়।

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

এরপর কী যাচাই করবেন

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

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