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 گروپ جسے ایک peer قبول نہیں کر سکتا ابھی آزمایا ہی نہیں جاتا۔ سرنگ صحت مند دکھتی ہے کیونکہ جس شرط پر آپ بعد میں ناکام ہوں گے وہ کبھی آزمائی نہیں گئی۔

CHILD_SA دوبارہ کلید ایک مختلف پیغامی ترتیب ہے۔ جب PFS ترتیب دیا گیا ہو، peer نئے کلیدی تبادلے کرتے ہیں اور اُنہیں ایسے گروپ پر متفق ہونا ہوتا ہے جسے دونوں فریق قبول کریں، نیز نئی انجمن کے لیے 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 کا تقاضا کرتی ہے، تو حل وہ گروپ ہے جسے دونوں طرف کے دونوں peer قبول کریں، جو مماثل پالیسی کے ذریعے ظاہر ہوتا ہے۔ خرابی مٹانے کے لیے PFS بند کرنا اُس حفاظتی خصوصیت کو بدل دیتا ہے جسے آپ برقرار رکھنا چاہتے تھے، اور یہ عام طور پر بعد میں کسی اور عدم مطابقت کے طور پر واپس آتا ہے۔

Azure سے مخصوص ایک جال: جب آپ ESP کے لیے GCM منتخب کرتے ہیں، تو خفیہ کاری اور سالمیت کی انتخابات کو ایک ہی GCM الگورتھم اور ایک ہی کلید کی لمبائی بتانی ہوتی ہے۔ GCM سائفر کو الگ سالمیت الگورتھم کے ساتھ ملانا ایسا امتزاج بناتا ہے جسے سروس مسترد کرتی ہے، اور جب تک پالیسی غور سے نہ پڑھیں یہ peer عدم مطابقت جیسا لگتا ہے۔

وہ مضبوط ترین امتزاج منتخب کریں جسے دونوں سرے تائید کریں اور آپ کا تقاضا اجازت دے، پھر اُسے تبدیلی کے ریکارڈ میں لکھیں۔ اگلا شخص اُسی ریکارڈ سے موازنہ کرے گا، کسی چلتی سرنگ کی یاد سے نہیں۔ اُس میں PFS گروپ اور ESP تجویز رکھیں، صرف پالیسی کا نام نہیں۔ جب بعد میں کوئی پوچھے کہ آڈٹ کیوں ناکام ہوا یا دوبارہ کلید کیوں سست ہے، تو وہی سطر دونوں سوالوں کا جواب دیتی ہے۔

ناکام تبادلے کی تصدیق کریں

تبدیلی کو بحالی کے راستے کے ساتھ ترتیب دیں، کیونکہ پالیسی میں ترمیم اُس سرنگ میں خلل ڈال سکتی ہے جسے آپ ٹھیک کرنے کی کوشش کر رہے ہیں۔ ٹریفک واپس آنے کے بعد CHILD_SA کی تجدید کا انتظار کریں یا اُسے شروع کریں اور تصدیق کریں کہ نئی انجمن مطلوبہ PFS گروپ کے ساتھ قائم ہوئی ہے۔ پھر تصدیق کریں کہ ایپلیکیشن ٹریفک اُس کے ذریعے جاری ہے۔

دو گمراہ کن اشاروں کا نام دینا مناسب ہے۔ SA کی عمریں مقامی تصریحات ہیں، اس لیے غیر مساوی اقدار معمول ہیں اور اُنہیں بدلنا صرف یہ منتقل کرتا ہے کہ مسئلہ کب ظاہر ہوتا ہے۔ DPD معلوم کرتا ہے کہ peer زندہ ہے یا نہیں؛ اُس کی وقت کی حد بڑھانا ESP یا PFS انتخابات کو ہم آہنگ نہیں کرتا۔

تبدیلی کے بعد طے شدہ نتیجہ اور اگلا واقعہ درج کریں۔ اگر کنکشن اب IKE تصدیق مکمل ہونے سے پہلے ناکام ہوتا ہے، تو آپ ابھی ترمیم کی گئی IKE ترتیبات دیکھ رہے ہیں، اصل CHILD-تجدید کی ناکامی نہیں۔