FortiGate Azure রিকি: peer SA প্রস্তাব স্থানীয় নীতির সাথে মেলে না

টানেল উঠে এল, ট্রাফিক চলল, আর পরে লগে দেখা যায় peer SA proposal not match local policy. বেশিরভাগ মানুষ এই লাইনটিকে প্রমাণ হিসেবে পড়েন যে দুটি কনফিগারেশন কখনোই মেলেনি। এটি সাধারণত আরও সংকীর্ণ কিছু বোঝায়: তারা প্রথম CHILD SA-এর জন্য মিলেছিল এবং প্রথম নবায়নেই মেলা বন্ধ করে দিয়েছিল, কারণ প্রথম অ্যাসোসিয়েশনের কখনো সেই বিনিময়ের প্রয়োজন হয়নি যা পরেরগুলো করে। এই পার্থক্যই ঠিক করে আপনি কোথায় তাকাবেন।

প্রথম CHILD SA উত্তরাধিকার পায়, পরেরগুলো দরকষাকষি করে

IKEv2-তে প্রাথমিক CHILD SA তৈরি হয় IKE_AUTH-এর সময়, এবং এর কীগুলো IKE SA-এর কী উপাদান থেকে উদ্ভূত হয়। সেই মুহূর্তে আলাদা Diffie-Hellman বিনিময় নেই, তাই একটি PFS গ্রুপ যা এক পিয়ার গ্রহণ করতে পারে না তা তখনো পরীক্ষাই হয় না। টানেল সুস্থ দেখায় কারণ যে শর্তে আপনি পরে ব্যর্থ হবেন তা কখনো পরীক্ষা হয়নি।

CHILD_SA রিকি হলো ভিন্ন বার্তা-ক্রম। PFS কনফিগার করা থাকলে পিয়াররা নতুন কী বিনিময় চালায় এবং উভয় পক্ষ যে গ্রুপ গ্রহণ করে তা নিয়ে সম্মত হতে হয়, সাথে নতুন অ্যাসোসিয়েশনের জন্য ESP প্রস্তাব। ঠিক সেই মুহূর্তেই অমিলটি দৃশ্যমান হয়, এবং তাই ত্রুটিটি রুটের বদলে প্রস্তাবের নাম নেয়।

তাই “গতকাল এটি কাজ করেছিল” প্রস্তাব সম্পর্কে আপনাকে কিছুই বলে না। এটি বলে প্রাথমিক বিনিময় সফল হয়েছিল, যা আপনি আগেই জানতেন।

ব্যর্থ বিনিময়টি পড়ুন, প্রথম ping নয়

কিছু বদলানোর আগে উভয় প্রান্ত থেকে সফল IKE প্রমাণীকরণ, প্রাথমিক CHILD SA এবং ব্যর্থ প্রতিস্থাপন সংগ্রহ করুন। তারপর ক্রিয়াটিকে নির্ভুলভাবে নাম দিন: IKE SA রিকি, IKE পুনঃপ্রমাণীকরণ এবং CHILD SA রিকি তিনটি ভিন্ন ঘটনা, আর “ফেজ 2” কথ্য ভাষায় এগুলোর সবকিছুকেই বোঝায়।

নিচের ক্ষেত্রগুলো ব্যর্থ হওয়া সংযোগের জন্য তুলনা করুন, সাধারণভাবে টানেলের জন্য নয়।

FortiGate-এ ওই টানেলের ফেজ-2 প্রস্তাব, PFS সেটিং এবং গৃহীত DH গ্রুপগুলো খুলুন। আগে প্রতিষ্ঠিত একটি সংযোগ থেকে অনুমান করার বদলে লোড করা মানগুলো পড়ুন। GUI পৃষ্ঠার স্ক্রিনশট চলমান কনফিগারেশনের চেয়ে দুর্বল প্রমাণ, কারণ আপগ্রেডের পর দুটি ভিন্ন হতে পারে। আপনি যে অংশটি বদলেছেন তা এক্সপোর্ট করুন এবং টিকিটের সাথে রাখুন।

Azure-এর ডিফল্ট নীতি এখনো একটি নীতি

সংযোগে কোনো কাস্টম নীতি সংযুক্ত না থাকার অর্থ Azure কোনো নীতি প্রয়োগ করে না তা নয়। সংযোগটি গেটওয়ের ডিফল্ট প্রস্তাব-সেটে ফিরে যায়, যা আপনার FortiGate যা দেয় তার চেয়ে প্রশস্ত বা সংকীর্ণ হতে পারে। যদি দুটি সেট IKE-এর জন্য ওভারল্যাপ করে কিন্তু PFS সহ ESP-এর জন্য না করে, তাহলে ঠিক এই ব্যর্থতার ধরনটাই পাবেন।

এই শুধু-পাঠ্য দৃশ্যটি প্রকৃতপক্ষে সংযুক্ত নীতি দেখায়, কোনো গোপন তথ্য ফাঁস না করেই:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

আপনার আসল রিসোর্স নাম ব্যবহার করুন। স্পষ্ট নীতি প্রয়োজন হলে তা সংযোগ রিসোর্সে সেট করুন। এটি গেটওয়-ব্যাপী কোনো সুইচ নয়, এবং একই গেটওয়ের অন্য টানেলে নীরবে প্রযোজ্য হয় না।

পোর্টালে ওই সংযোগের Configuration পৃষ্ঠাটিই সেখানে যায় যেখানে কাস্টম IPsec/IKE নীতি বসে। Microsoft-এর কাস্টম-নীতি নির্দেশিকা সমর্থিত প্যারামিটার ও SKU প্রয়োজনীয়তা তালিকাভুক্ত করে। Azure প্রতি সংযোগে একটি সম্পূর্ণ সমন্বয় নেয়, তাই আপনি IKE ক্ষেত্র ও IPsec ক্ষেত্র একসাথে নির্দিষ্ট করেন, একবারে একটি নয়।

PFS একটি প্রয়োজনীয়তা, উল্টে দেওয়ার সুইচ নয়

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

Azure-নির্দিষ্ট একটি ফাঁদ: ESP-এর জন্য GCM বাছাই করলে এনক্রিপশন ও অখণ্ডতার নির্বাচনকে একই GCM অ্যালগরিদম ও কী-দৈর্ঘ্যের নাম দিতে হবে। GCM সাইফারের সাথে আলাদা অখণ্ডতা অ্যালগরিদম মেশালে এমন সমন্বয় হয় যা সেবা প্রত্যাখ্যান করে, আর নীতিটি মনোযোগ দিয়ে না পড়া পর্যন্ত তা পিয়ার-অমিলের মতো দেখায়।

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

ব্যর্থ হওয়া বিনিময়টি যাচাই করুন

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

দুটি ভ্রান্ত পথের নাম দেওয়া দরকার। SA জীবৎকাল স্থানীয় বৈশিষ্ট্য, তাই অসম মান স্বাভাবিক এবং সেগুলো বদলালে কেবল সমস্যাটি কখন দেখা দেবে তা সরে যায়। DPD দেখে পিয়ার জীবিত কি না; তার টাইমআউট বাড়ালে ESP বা PFS নির্বাচন মিলে যায় না।

সমঝোতাকৃত ফলাফল এবং পরিবর্তনের পরের ঘটনাটি লিখে রাখুন। যদি সংযোগটি এখন IKE প্রমাণীকরণ সম্পূর্ণ হওয়ার আগেই ব্যর্থ হয়, তবে আপনি এইমাত্র সম্পাদনা করা IKE সেটিংস দেখছেন, মূল CHILD-নবায়ন ব্যর্থতা নয়।