IKE-তে MAC মিলছে না মানে শেয়ার্ড কী যাচাই ব্যর্থ হয়েছে

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

অনুশীলনে দুটি শর্ত এটি ঘটায়: দুই প্রান্তের সিক্রেট একই মান নয়, অথবা সিক্রেট বাছাই করতে ব্যবহৃত পরিচয় দুটি মেলে না। কোনটি তা জোড়াটি পড়ে ঠিক করুন, একক টানেল পড়ে নয়।

পর্যায়টি কী প্রমাণ করে

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

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

দুটি কনফিগারেশন ত্রুটি, একটি বার্তা

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

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

NAT শনাক্তকরণ আলাদা পর্যায়

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

একটি ভেন্ডর রিলিজ সম্পর্কে পুরোনো বক্তব্য বর্তমান ডিপ্লয়মেন্টে বহন করবেন না। আপনার রিলিজে NAT ট্রাভার্সাল কী চায় তা তার নিজস্ব ডকুমেন্টেশনে থাকে, আর MAC mismatch বাক্যটি এর পক্ষে বা বিপক্ষে প্রমাণ নয়।

স্ক্রিন নয়, জোড়া থেকে সিদ্ধান্ত নিন

সিক্রেট ঢেকে দুই কনফিগারেশন পাশাপাশি পড়ুন, তারপর তিনটি প্রশ্ন করুন। প্রতিটি পক্ষের পরিচয় কি অন্যপক্ষের প্রত্যাশার ঠিক মতো, অক্ষরে অক্ষরে? দুই প্রান্ত কি একই IKE সংস্করণ ও একই অথেনটিকেশন পদ্ধতি ব্যবহার করছে? ব্যর্থ টানেলটি কি আপনি যে কনফিগারেশন পড়ছেন তার সঙ্গে মেলে? এর যেকোনোটিতে 'না' হলে সিক্রেট স্পর্শ না করেই মেরামত নির্ধারিত হয়।

তিনটি যদি পরিষ্কার হয়, সিক্রেটের চারপাশে সম্পাদনা না করে অনুমোদিত কর্মপ্রবাহে সিক্রেট প্রতিস্থাপন করুন।

পিয়ার অথেনটিকেট হওয়ার পরে

অথেনটিকেশন সফল হলে পরবর্তী ব্যর্থতার পৃষ্ঠ হলো চাইল্ড সিকিউরিটি অ্যাসোসিয়েশন: প্রস্তাব ও ট্রাফিক সিলেক্টর। ইতিমধ্যে গৃহীত সিক্রেট ঘোরানো চাইল্ড ব্যর্থতা ঠিক করতে পারে না, বরং বিভ্রাট দীর্ঘ করে। চাইল্ড অবস্থা, তারপর দুই পক্ষের সিলেক্টর ও সুরক্ষিত রেঞ্জ পড়ুন, এবং Cloud VPN সমস্যা সমাধান নির্দেশিকা সত্যিই ব্যর্থ পর্যায়ের সঙ্গে মিলান।

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

কী সিদ্ধান্ত নেবেন না

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

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