IKE পরিচয় বা এন্ডপয়েন্ট ঠিকানা: এগুলো মিলিয়ে ফেলবেন না
FQDN ধরনের IKE পরিচয় একটি আক্ষরিক প্রমাণীকরণ মান, রিভার্স-DNS অনুসন্ধান নয়। এন্ডপয়েন্ট ঠিকানা, স্থানীয় পরিচয় এবং প্রত্যাশিত peer আলাদা রাখুন।
FQDN পরিচয় হিসেবে লেবেল করা ফিল্ডকে আক্ষরিক স্ট্রিং হিসেবে পড়ুন, আপনার পাবলিক ঠিকানার রিভার্স-DNS নামের অনুরোধ হিসেবে নয়। strongSwan-এর পার্সারে এটি ঠিক সেটাই, একটি স্ট্রিং, এবং এটি পড়লে কখনও এন্ডপয়েন্টে সমাধান হয় না। এই সত্যটিই peer-এর জন্য শনাক্তকারী বাছাই করার সময় সবচেয়ে সাধারণ বিভ্রান্তি দূর করে। নিচের যাচাইগুলো তিনটি সংশ্লিষ্ট মানকে এক হয়ে যাওয়া থেকে বিরত রাখে।
লেবেল কোনো অনুসন্ধান নয়
বিক্রেতাদের ইন্টারফেস FQDN আর hostname-এর মতো শব্দ ঢিলেঢালাভাবে ব্যবহার করে, আর বাক্সের লেবেল তার পেছনের এনকোডিং সম্পর্কে কিছুই বলে না। যে ডিভাইস একটি ফিল্ডকে Client FQDN বলে, সেটি FQDN, ইমেইলের আকারের স্ট্রিং বা খালি ঠিকানা পাঠাতে পারে। টেক্সট ও ধরনকে দুটি আলাদা সিদ্ধান্ত হিসেবে ধরুন এবং দুটোই নথিভুক্ত করুন।
আক্ষরিক পরিচয়ে কিছুই DNS দাবি করে না। এটি অন্য প্রান্তের যাচাই করা একটি দাবি, নেটওয়ার্কের সমাধান করার মতো নাম নয়।
তিনটি আলাদা মান, আলাদাভাবে লেখা
একটি কনফিগারেশন স্ক্রিনের পেছনে তিনটি কাজ থাকে, আর সেগুলো এক করা ব্যয়বহুল ভুল। একটি মান এন্ডপয়েন্ট ঠিকানা, যা নির্ধারণ করে প্যাকেট কোথায় যাবে। আরেকটি এই peer যে স্থানীয় পরিচয় উপস্থাপন করে, আর তৃতীয়টি সেই পরিচয় যা আপনি প্রমাণীকরণের আগে দূরের প্রান্ত থেকে প্রত্যাশা করেন। পরিবর্তন টিকিটে সেগুলো তিন লাইন হিসেবে লিখুন, কারণ এর কম কিছু সম্পর্ক নয়, VPN বোঝায়।
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
নমুনা পরিচয়গুলো মোতায়েনের অংশ হিসেবে বাছাই ও অনুমোদন করতে হবে। এগুলো এমন দাবি যা প্রমাণীকরণ যাচাই করে, কোনো peer-কে বিশ্বাসযোগ্য করার প্রমাণপত্র নয়, তাই বিশ্বাসযোগ্য দেখতে পাওয়া স্ট্রিং কিছুই অনুমোদন করে না।
ধরন মানের অংশ
strongSwan পরিচয় রেফারেন্স FQDN, ইমেইলের আকারের মান, IP ঠিকানা এবং অন্যান্য এনকোডিং আলাদা করে, তাই এনকোডিং অক্ষরের মতোই গুরুত্বপূর্ণ। দুটি ডিভাইস একই টেক্সট ভিন্ন ধরনের অধীনে গ্রহণ করেও একে অন্যকে প্রত্যাখ্যান করতে পারে। ধরন ছাড়া মান নথিভুক্ত করা নোট অর্ধেক কনফিগারেশন।
ডিভাইসটি আসলে কোন ধরন পাঠায় তা বিক্রেতাকে জিজ্ঞাসা করুন, এবং ইন্টারফেস লেবেলের বদলে ডিকোড দিয়ে নিশ্চিত করুন। অনুমান করা ধরন পরবর্তী পরিবর্তনের অপেক্ষায় থাকা অসঙ্গতি।
প্রতিটি পক্ষকে অন্যটিকে সন্তুষ্ট করতে হবে
প্রতিটি পক্ষের স্থানীয় পরিচয়কে অন্য পক্ষের প্রমাণীকরণ নীতি পার হতে হবে। এটি দুই ডিভাইসের প্রতিটি পরিচয় বাক্সে একই স্ট্রিং আটকে দেওয়ার মতো নয়, সেই শর্টকাট এমন কনফিগারেশন বানায় যা কেউ ডিবাগ করতে পারে না।
সনদপত্র প্রমাণীকরণ নিজের প্রয়োজন যোগ করে, কারণ সনদপত্রের পরিচয় ও বিশ্বাসের শর্ত আপনার টাইপ করা IKE পরিচয়ের পাশে থাকে। কেবল IKE পরিচয়ের মিল সনদযুক্ত peer-কে অনুমোদন করে না।
DNS কোথায় গুরুত্বপূর্ণ, এবং আপনার সংস্করণ কী বাধ্যতামূলক করে
আবিষ্কারের জন্য ব্যবহৃত গেটওয়ে hostname সত্যিই কাজ করা DNS দরকার, এবং সেই প্রয়োজন এন্ডপয়েন্ট খোঁজার, টাইপ করা পরিচয়ের কোনো রিভার্স অনুসন্ধানের নয়। টিকিটে দুটোই আলাদা রাখুন, কারণ আবিষ্কার ব্যর্থতা ও পরিচয়ের অসঙ্গতি ক্লায়েন্ট লগে একইভাবে পড়া হয় এবং ভিন্ন জায়গায় মেরামত হয়।
ধরন বাধ্য করে এমন সিনট্যাক্স কপি করার আগে আপনি যে পণ্য ও সংস্করণ সত্যিই চালান তার পার্সার পড়ুন, কারণ পুরোনো strongSwan সংস্করণ ভিন্ন আচরণ করত এবং অন্য বিক্রেতারা নিজেদের সীমাবদ্ধতা যোগ করে। দুটি প্রান্ত তুলনা করার সময় চারটি বিষয় একসাথে রাখুন: প্রত্যাশিত পরিচয়, উপস্থাপিত পরিচয়, ধরন এবং প্রমাণীকরণ ত্রুটি। এই সেটটি অসঙ্গতিকে মত নয়, প্রমাণে পরিণত করে।