Check Point VSX VPN: লিঙ্ক সিলেকশন নাকি পিয়ার মিসম্যাচ?

Check Point সাইট-টু-সাইট টানেল আর ঠিকমতো না উঠলে দুটি ভিন্ন পরিবর্তন একই উপসর্গ তৈরি করে: পিয়ার হয় ভিন্ন একটি বাহ্যিক ঠিকানা দেখে, নয়তো এখন যে IKE পরিচয় পাচ্ছে তা প্রত্যাখ্যান করে। এক পাশ থেকে নেওয়া ক্যাপচারে দুটোই একই রকম দেখায়। কোনটি আপনার ক্ষেত্রে ঘটছে তা ঠিক করতে তিনটি পরীক্ষা লাগে, আর তার একটিও লিঙ্ক সিলেকশন প্যানেল নয়।

ক্রম ভুল হলে আপনি পরিচয়ের মিসম্যাচ ঠিক করতে সোর্স সিলেকশন টিউন করতে বসবেন। এভাবেই একই টানেল দুইবার ঠিক হয় আর পরের রুট পরিবর্তনের পরেই আবার ভেঙে পড়ে।

দুটি ঘটনাকে আলাদা করা তিনটি শর্ত

প্রথম শর্ত: পিয়ারের কনফিগার করা এন্ডপয়েন্ট কি সত্যিই যে ঠিকানা দিয়ে প্যাকেট আসছে তার সঙ্গে মেলে? যদি প্যাকেট দূরবর্তী গেটওয়েতে পৌঁছায় এমন একটি ঠিকানা থেকে যা পিয়ার আপনার পিয়ার-অবজেক্টের সঙ্গে সম্পর্কিত করে না, তবে কোনো পরিচয় বিনিময়ের আগেই নেগোশিয়েশন ব্যর্থ হয়। দ্বিতীয় শর্ত: প্রস্তাবের IKE পরিচয় কি পিয়ারের প্রত্যাশিত মানের সঙ্গে মেলে? এটি অথেন্টিকেশন, ট্রান্সপোর্ট নয়। তৃতীয় শর্ত: আপনি যে অপশনটি বদলাতে চান, তা কি এই রিলিজে এই ভার্চুয়াল সিস্টেমের জন্য সমর্থিত? দৃশ্যমান কোনো সেটিং এই প্রশ্নগুলোর একটিরও উত্তর দেয় না।

প্রথম শর্ত ব্যর্থ হলে আপনার রুটিং বা অনুবাদের সমস্যা। দ্বিতীয় শর্ত ব্যর্থ হলে আপনার পিয়ার-চুক্তির সমস্যা। তৃতীয় শর্ত অজানা থাকলে কনফিগার করা বন্ধ করুন।

প্রথমে বাহ্যিক-পিয়ার রেকর্ড তৈরি করুন

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

ভেতরের সুরক্ষিত প্রিফিক্সগুলো ওই রেকর্ডের আলাদা অংশে রাখুন। বাইরের সোর্স বদলানো আর সুরক্ষিত LAN ঠিকানা বদলানো দুটি ভিন্ন কাজ, যারা কেবল একই পলিসিতে একসঙ্গে থাকে।

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

লিঙ্ক সিলেকশন আসলে কী আলাদা করে তা পড়ুন

Check Point-এর R81.20 লিঙ্ক সিলেকশন গাইড তিনটি জিনিস আলাদা করে, যেগুলো মানুষ এক করে ফেলে: দূরবর্তী পিয়ার কীভাবে গেটওয়ে ঠিকানা রিজলভ করে, বহির্গামী ট্রাফিক কোন রুট বহন করে, এবং কোন সোর্স IP ব্যবহার হয়। প্রতিটি ভিন্ন প্রশ্নের উত্তর দেয়। এর কোনোটিই পিয়ার যে পরিচয় অথেন্টিকেট করে তা বদলায় না।

এই বিভাজনই ব্যাখ্যা করে কেন একটি রুট পরিবর্তন IKE পরিচয়ে হাত না দিয়েই দৃশ্যমান বাহ্যিক ঠিকানা বদলে দিতে পারে, আর কেন পরিচয় বদলালে এমন টানেলও ভাঙতে পারে যার রুটিং নিখুঁত।

RFC 7296 IKE-র ক্ষেত্রেও একই সীমারেখা টানে: আইডেন্টিফিকেশন পেলোড ট্রান্সপোর্ট ঠিকানা নয়। ভেন্ডররা এই বিভাজন বাস্তবায়ন করে, পুনরায় সংজ্ঞায়িত করে না।

সেটিংস প্যানেল নয়, প্রমাণ দিয়ে সিদ্ধান্ত নিন

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

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

দুই প্রান্ত মিলিয়ে নিন এবং রেকর্ড রাখুন

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

পর্যবেক্ষিত বাহ্যিক ঠিকানাগুলো সক্রিয় ভার্চুয়াল-সিস্টেম প্রসঙ্গের পাশে সংরক্ষণ করুন। তাহলে পরের রুট পরিবর্তন কারও ডিফল্টের স্মৃতির বদলে একটি নথিভুক্ত চুক্তির সঙ্গে তুলনা করবে।