Windows ও FortiGate-এ IKEv2: মানুষ যে তিনটি সেটিংস এক করে ফেলে
IKE কী বিনিময়, CHILD SA সুরক্ষা এবং পিয়ার প্রমাণীকরণ তিনটি আলাদা সারি। দুটি ডায়ালগে গ্রুপ নম্বর মিলে গেলেও সেগুলো এক হয় না।
Windows ক্লায়েন্ট ও FortiGate গেটওয়ের মধ্যে IKEv2 চুক্তি বারবার ব্যর্থ হচ্ছে, আর অমিল নম্বরের খোঁজ আরও লম্বা নম্বরের তালিকা তৈরি করছে। তালিকাটি তখনই সামলানো সম্ভব হয় যখন এটিকে তিনটি স্বাধীনভাবে ব্যর্থ হওয়া সারিতে ভাগ করা হয়: যে কী বিনিময় IKE-কে রক্ষা করে, CHILD SA-তে প্রয়োগ করা সুরক্ষা, এবং যে প্রমাণীকরণ প্রমাণ করে প্রতিটি পক্ষ কে। গ্রুপ নম্বর ওই সারিগুলোর মধ্যে দুটিতে দেখা যায় এবং ভিন্ন অর্থ বহন করে।
স্বাধীনভাবে ব্যর্থ হওয়া তিনটি সারি
প্রথম সারি হলো IKE-র ভেতরের কী বিনিময়, যা আলোচনাকে রক্ষা করার কী তৈরি করে। দ্বিতীয়টি হলো CHILD SA-র প্রস্তাব, যা টানেল যে ট্রাফিক বহন করে তা রক্ষা করে। তৃতীয়টি হলো প্রমাণীকরণ, যা ঠিক করে প্রতিটি পক্ষ কী উপস্থাপন করে এবং অন্য পক্ষ তা কীভাবে যাচাই করে।
ব্যর্থতাগুলো ভিন্ন ভিন্ন জায়গায় পড়ে। বিনিময়ের ব্যর্থতা কোনো টানেল তৈরির আগেই আলোচনা থামিয়ে দেয়। CHILD SA-র ব্যর্থতা প্রমাণীকরণ সফল হওয়ার পরে ঘটে, কখনও কখনও কেবল কী নবায়নের সময়। প্রমাণীকরণের ব্যর্থতা লগে বিনিময়ের ব্যর্থতার মতো দেখাতে পারে, যদি আপনি কেবল প্রথম ত্রুটিটি পড়েন।
সারিগুলো আলাদা করা হিসাবরক্ষণ নয়। এটি বদলে দেয় কোন সেটিংস পরিবর্তন করা মূল্যবান, এবং এটি এই পুরো ক্ষেত্রের সবচেয়ে ব্যয়বহুল পদক্ষেপ প্রতিরোধ করে, যা হলো প্রস্তাবের অমিল ঠিক করতে কাজ করা সার্টিফিকেট পুনরায় তৈরি করা। একটি সারি বদলালে অন্য দুটিকে তার সঙ্গে বদলাতে বাধ্য করা উচিত নয়। এই স্বাধীনতাই তাদের আলাদাভাবে লেখার পুরো উদ্দেশ্য।
Windows-এর দুটি ফিল্ড কী নিয়ন্ত্রণ করে
Windows দুটি ফিল্ড আলাদা রাখে: DHGroup নিজে IKE বিনিময় কনফিগার করে, আর PfsGroup টানেলের ভেতরের ট্রাফিক রক্ষা করা IPsec নীতি কনফিগার করে। এরা ভিন্ন ধাপের অন্তর্গত। Windows-এর IKE ফিল্ডকে FortiGate-এর 2য় ধাপের মানের সঙ্গে তুলনা করা ভুল জোড়া পরীক্ষা করে, আর নম্বর মিলে যেতে পারে অথচ অন্তর্নিহিত বিনিময় এখনও ব্যর্থ হয়।
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAদ্বিতীয় ও তৃতীয় কমান্ড প্রকৃতপক্ষে বিদ্যমান সিকিউরিটি অ্যাসোসিয়েশন দেখায়, আর এটি ক্লায়েন্ট যে উত্তর দিতে পারে তার সবচেয়ে কাছাকাছি জিনিস। মূল-মোড অ্যাসোসিয়েশন থাকলেও দ্রুত-মোড অ্যাসোসিয়েশন না থাকা CHILD SA-র সমস্যা, এবং এটি সার্টিফিকেটের সমস্যা নয়, বরং 2য় ধাপের অমিলের লক্ষণ।
একটি প্রয়াসে কী প্রস্তাব দেওয়া হলো আর কী বাছাই হলো তা লিখে রাখুন। যে প্রস্তাব-তালিকায় একটি গ্রহণযোগ্য প্রস্তাব আছে কিন্তু বাছাই করা প্রস্তাবটি গেটওয়ের নীতির সঙ্গে মেলে না, সেটি কনফিগারেশনের মতভেদ, ইন্টারঅপারেবিলিটির রহস্য নয়।
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
উপবৃত্তীয় বক্ররেখার গ্রুপ আপনার স্বাক্ষর কী বাছাই করে না
এই ক্ষেত্রের সবচেয়ে দীর্ঘস্থায়ী ভুল সিদ্ধান্ত হলো এই ধারণা যে উপবৃত্তীয় বক্ররেখার DH গ্রুপ বাছাই করতে উপবৃত্তীয় বক্ররেখার সার্টিফিকেট লাগে। DH গ্রুপ কী বিনিময়ের উপাদান যোগায়; স্বাক্ষর অ্যালগরিদম প্রমাণীকরণ কাঠামো দ্বারা আলোচনা হয়, এবং IKEv2-তে এগুলো আলাদা সিদ্ধান্ত।
RFC 7427 বিদ্যমান ঠিক এ কারণেই যে এই সিদ্ধান্তগুলো আগে জড়িয়ে ছিল, এবং এটি নির্ধারণ করে কীভাবে স্বাক্ষর অ্যালগরিদম কী বিনিময় থেকে স্বাধীনভাবে ঘোষণা ও বাছাই হয়। একটি গেটওয়ে একই সঙ্গে একটি বক্ররেখার গ্রুপ এবং স্বাক্ষর স্কিমের একটি নির্বাচন সমর্থন করতে পারে।
তাই গ্রুপ পরিবর্তনের পরে আলোচনা ব্যর্থ হলে, সার্টিফিকেটের কী ধরন দেখার আগে প্রমাণীকরণ পদ্ধতিটি দেখুন। সার্টিফিকেট পরিবর্তন একটি ধীর, ঝুঁকিপূর্ণ কাজ যা খুব কমই উত্তর, আর এটি প্রথমে করলে কোন পরিবর্তন সত্যিই সাহায্য করেছে তা বোঝার ক্ষমতা নষ্ট হয়। সার্টিফিকেট স্টোর স্পর্শ করার আগে প্রমাণীকরণের সারিটি পড়ুন।
দুটোকে চুক্তিপত্রের আলাদা সারিতে রাখুন, তাহলে ভুলটি লোভনীয় থাকবে না। একটি সারিতে গ্রুপ, অন্যটিতে স্বাক্ষর স্কিম ও পরিচয় তালিকাভুক্ত থাকে, এবং কোনোটি অন্যটির প্রমাণ নয়।
প্রতিটি প্রাইভেট কী তার প্রকৃত মালিকের কাছে রাখুন
যে গেটওয়ে নিজের সার্টিফিকেট উপস্থাপন করে তার সেই সার্টিফিকেটের সঙ্গে মেলা প্রাইভেট কী দরকার। যে পিয়ার একটি চেইন যাচাই করে তার CA সার্টিফিকেট দরকার, এবং বিশেষভাবে CA-র স্বাক্ষর কী দরকার নেই। এই তিনটি উপাদান গুলিয়ে ফেলার কারণেই মানুষ VPN ডিভাইসে CA-র প্রাইভেট কী আমদানি করে সার্টিফিকেটকে ভিন্ন শ্রেণিতে দেখাতে চায়।
FortiOS-এ ভূমিকাগুলো আলাদা: নিজের কী-সহ স্থানীয় সার্টিফিকেট, পিয়ার শনাক্ত করতে ব্যবহৃত দূরবর্তী সার্টিফিকেট, এবং দূরবর্তী CA এন্ট্রি যা সেই CA-র স্বাক্ষরিত সার্টিফিকেটে বিশ্বাস প্রতিষ্ঠা করে। প্রাইভেট কী ছাড়া দূরবর্তী CA এন্ট্রি অসম্পূর্ণ নয়; এটি তার উদ্দেশ্যের জন্য সঠিক।
আমদানিকৃত CA স্বাক্ষর কী ওই ডিভাইস পড়তে পারে এমন যে কারও কর্তৃত্ব বাড়ায়। এগুলো সাধারণ পিয়ার যাচাইও সমাধান করে না, কারণ যাচাইয়ের জন্য প্রয়োজন পাবলিক সার্টিফিকেট ও বিশ্বাসের সিদ্ধান্ত, নতুন সার্টিফিকেট তৈরি করার ক্ষমতা নয়।
CA-র স্বাক্ষর কী ইস্যুকারীর নিজের প্রক্রিয়ার কাছে রাখুন, এবং কোন ডিভাইস কোন কী ধরে আছে তা লিখে রাখুন। মালিকদের একটি ছোট তালিকা অ্যালগরিদমের দীর্ঘ তালিকার চেয়ে বেশি মূল্যবান, যখন নিরীক্ষা জিজ্ঞেস করে কে কার ছদ্মবেশ ধারণ করতে পারত। কেউ এমন কী আমদানি করে না যা সে জানে কেবল ইনভেন্টরির জন্য। ঘটনার পরে নয়, আগে ইনভেন্টরি লিখুন।