IPsec প্রোফাইলে পাঁচটি ঠিকানার ভূমিকা, এবং কোনটি ভুল

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

পাঁচটি কাজ, যে ক্রমে তারা গুরুত্বপূর্ণ

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

left ও right-এর মতো অংশগ্রহণকারীর লেবেল একটি সংযোগের দুই পক্ষের জন্য রীতি, স্থানীয় ও দূরবর্তীর সমার্থক নয়। একটি কী যে অর্থে অন্য একটি পণ্য ব্যবহার করেছিল তা ধরে নেওয়ার আগে প্রকৃতপক্ষে ইনস্টল করা বাস্তবায়নের ম্যানুয়াল পড়ুন।

প্রথম সিদ্ধান্ত: কিছুই প্রতিষ্ঠিত হয় না

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

অনুবাদের মাধ্যমে দেখা একটি পাবলিক ঠিকানা পিয়ার যে পরিচয় প্রমাণ করে তার সমান কিছু নয়। প্যাকেট ক্যাপচার দূর প্রান্তে যা দেখায় তার সঙ্গে মেলাতে ঠিকানা বদলানো একটি সাধারণ ও ভুল সংশোধন।

দ্বিতীয় সিদ্ধান্ত: টানেল উঠে আছে আর ট্রাফিক মরে

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

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

তৃতীয় সিদ্ধান্ত: শুধু গেটওয়ের নিজের ট্রাফিক ব্যর্থ হয়

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

যে অ্যাপ্লিকেশন স্পষ্টভাবে অন্য ঠিকানা বাঁধে সে পছন্দটিকে অগ্রাহ্য করতে পারে, তাই সেটিং উপেক্ষিত বলে সিদ্ধান্তে আসার আগে প্যাকেটের প্রকৃত উৎস নিশ্চিত করুন। কনফিগারেশনের অভিপ্রায়ে ভরসা না করে গেটওয়ের নিজের ইন্টারফেসে ক্যাপচার করুন।

পরবর্তী হপ একটি স্থানীয় নির্দেশ

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

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

উভয় প্রান্ত থেকে প্রোফাইল পড়ুন

কাগজে ভূমিকা উল্টে দেওয়া সবচেয়ে দ্রুত পর্যালোচনা: সুরক্ষিত রেঞ্জ অদলবদল করুন, প্রতিটি পক্ষের নিজস্ব পরবর্তী হপ রাখুন, এবং প্রতিটি পক্ষের নিজস্ব পরিচয় রাখুন। যা অদলবদল সহ্য করে না তা সম্ভবত ভুল কাজে বরাদ্দ হয়েছে।

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