ike-scan কাজ করা IPsec গেটওয়ের কাছ থেকে কোনো উত্তর পায় না

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

তিনটি আলাদা প্রশ্ন নিয়ে কাজ করুন: প্যাকেটটি পৌঁছেছে কি, কোনো প্রস্তাব মিলেছে কি, এবং অন্য কিছু কি পিয়ারকে প্রত্যাখ্যান করেছে?

ধাপ 1: টুলটি যে প্রস্তাব পাঠায় তা পড়ুন

মেইন মোড শুরু হয় একটি SA পেলোড দিয়ে যা ইনিশিয়েটর যে ট্রান্সফর্মগুলো গ্রহণ করবে তা তালিকাভুক্ত করে, এবং ike-scan সেই তালিকা একটি কম্পাইল করা ডিফল্ট থেকে পূরণ করে। ডিফল্ট সেটটি ইচ্ছাকৃতভাবে পুরোনো: এনক্রিপশনের জন্য DES ও 3DES, হ্যাশের জন্য MD5 ও SHA1, কী বিনিময়ের জন্য গ্রুপ 1 ও 2, প্রমাণীকরণের জন্য পূর্ব-শেয়ার করা কী। AES নেই, SHA-2 নেই, গ্রুপ 14 নেই। AES-256, SHA-256 ও modp2048 দিয়ে কনফিগার করা গেটওয়ের সাথে এর কিছুই মেলে না।

কিছু ইমপ্লিমেন্টেশন অমিলিত প্রোবের জবাবে NO-PROPOSAL-CHOSEN বিজ্ঞপ্তি। বাকিরা এটি কেবল ফেলে দেয়, যা অজানা পিয়ারকে শব্দ হিসেবে গণ্য করা অ্যাপ্লায়েন্সে সাধারণ। যেভাবেই হোক স্ক্যান কিছু ছাপে না, আর সেই কিছু বাইরে থেকে ফিল্টার করা UDP 500 যেমন দেখায় ঠিক তেমনই, যেমনটি ike-scan প্রকল্পের ডকুমেন্টেশন ডিফল্ট সেট সম্পর্কে স্পষ্ট করে।

ধাপ 2: একটি আধুনিক প্রস্তাব দিন

ডিফল্ট সেটটি --trans দিয়ে প্রতিস্থাপন করুন। অ্যাট্রিবিউট ফর্মটি IKE অ্যাট্রিবিউট নম্বর সরাসরি নেয়: এনক্রিপশনের জন্য 1, হ্যাশের জন্য 2, প্রমাণীকরণের জন্য 3, গ্রুপের জন্য 4, এবং অ্যালগরিদম দৈর্ঘ্য নিলে কী দৈর্ঘ্যের জন্য 14। যা বের হয় তা একটি লাইন যা আপনি পরিবর্তন পর্যালোচনায় উচ্চস্বরে পড়তে পারেন।

পজিশনাল ফর্মটি একই মান ক্রমে বহন করে এবং বন্ধনী এড়ায়, যা কমান্ড শেলের মধ্য দিয়ে গেলে গুরুত্বপূর্ণ।

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

গণনার সময় প্রতি প্যাকেটে একটি প্রস্তাব ধীর, তাই সম্ভাব্য মানগুলোর উপর লুপ করুন: এনক্রিপশন 5, 7/128, 7/192, 7/256; হ্যাশ 1, 2, 5, 6, 7; গ্রুপ 1, 2, 5, 14, 15, 19, 20, 21; পূর্ব-শেয়ার করা কীয়ের জন্য প্রমাণীকরণ 1 এবং RSA স্বাক্ষরের জন্য 3। চালানোর আগে প্রতিটি কমান্ড ছাপুন যাতে ট্রান্সক্রিপ্ট দেখায় কী এবং কোন ক্রমে প্রস্তাব দেওয়া হয়েছে।

ধাপ 3: উত্তর ব্যাখ্যা করুন

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

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

ধাপ 4: নীরবতা ব্যাখ্যা করুন

নীরবতা যতটা মনে হয় তার চেয়ে দুর্বল প্রমাণ। প্রতিটি প্রস্তাব বাতিল হয়ে থাকতে পারে, UDP 500 ও 4500 ফিল্টার হতে পারে, উৎসটি বিস্ফোরণের পরে হার-সীমাবদ্ধ হতে পারে, অথবা সেবাটি আপনি যে ঠিকানা স্ক্যান করেছেন তার চেয়ে ভিন্ন ঠিকানায় শুনতে পারে। বাক্স সম্পর্কে কিছু সিদ্ধান্তে আসার আগে গেটওয়ের IKE লগকে এমন ক্লায়েন্টের সাথে তুলনা করুন যা ইতিমধ্যে বৈধ শংসাপত্র দিয়ে সংযুক্ত হয়।

বিস্ফোরণ আচরণ ওই তালিকায় থাকা উচিত, কারণ গণনা অল্প সময়ের মধ্যে অনেক প্যাকেট তৈরি করে। যে গেটওয়ে প্রথম প্রচেষ্টার উত্তর দিয়ে চুপ হয়ে যায়, সে তার প্রস্তাব সেট নয় বরং anti-DoS নীতি বর্ণনা করছে।

ধাপ 5: আপনি কী প্রমাণ করেছেন তা লিখে রাখুন

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

যে প্রোব কখনও উত্তর দেয়নি, সেও কিছু উত্তর দিয়েছে: এটি দেখায় এই ডিভাইস কোন প্রস্তাব নিয়ে আলোচনা করতে রাজি, আর কোনগুলো মেঝেতে ফেলে দিতে পছন্দ করে।