Azure S2S VPN منسلک ہے مگر ٹریفک نہیں: IKE لاگ پڑھیں

پورٹل Connected کہتا ہے، ٹنل میں اپ ٹائم کا کاؤنٹر ہے، اور آپ کی ورچوئل مشین سے آیا trace دوسرے hop پر مر جاتا ہے۔ کنکشن کی حالت IKE اور IPsec مذاکرات بیان کرتی ہے، یہ نہیں کہ کسی بھی طرف ایک پیکٹ پالیسی کی تہہ سے گزرتا ہے یا نہیں۔ ان ٹکٹوں کی بیشتر وجہ دو خرابیاں ہیں اور ان میں سے کوئی ایک بھی Azure روٹ بدلنے سے درست نہیں ہوتی۔ دونوں پہلے ہی اس لاگ میں لکھی ہیں جو گیٹ وے نے بنایا، اسی لیے میں روٹ ٹیبل کی بجائے وہیں سے شروع کرتا ہوں۔

Connected درحقیقت کس چیز کی تصدیق کرتا ہے

منسلک site-to-site کنکشن کا مطلب ہے کہ مرحلہ 1 اور مرحلہ 2 مکمل ہو چکے ہیں اور سیکیورٹی ایسوسی ایشنز فعال ہیں۔ یہ مذاکرات کے بارے میں ایک بیان ہے: دونوں فریق ایک تجویز پر متفق ہوئے، چابیاں تبدیل کیں اور SA کی جوڑی نصب کی۔ یہ نہیں بتاتا کہ ٹریفک کے منتخب کنندگان ان سب نیٹ سے میل کھاتے ہیں یا نہیں جنہیں آپ محفوظ سمجھتے ہیں، اور نہ یہ کہ ڈکرپٹ کرنے کے بعد دوسرا فریق پیکٹ کو کہیں روٹ کرے گا۔ ٹنل ہفتوں تک قائم رہ سکتا ہے جبکہ ہر دلچسپ فلو گرادیا جاتا ہے، اور یہی وہ نمونہ ہے جو لوگوں کو صحت مند گیٹ وے دوبارہ بنانے پر مجبور کرتا ہے۔

پہلے جانچنے کے قابل دو خرابیاں یہ ہیں کہ peer ESP کی بجائے AH تجویز کرے، اور ایسی جگہ میں نمبر شدہ ورچوئل نیٹ ورک جسے گیٹ وے اندرونی نہ سمجھے۔

روٹس کو چھونے سے پہلے برآمد شدہ لاگ کھولیں

پورٹل میں ورچوئل نیٹ ورک گیٹ وے کھولیں اور کنکشن پر VPN troubleshoot کارروائی چلائیں، پھر بننے والا بنڈل ڈاؤن لوڈ کر کے کھولیں۔ اندر مرحلہ 1 اور مرحلہ 2 کے تبادلوں والا IKE لاگ ہے، وقت کی مہروں کے ساتھ اور سادہ متن کے طور پر پڑھنے کے قابل۔ اوپر سے نیچے پڑھنے کی بجائے اس میں transform لائن تلاش کریں، کیونکہ دلچسپ اندراج عموماً چند سو سطروں کے بعد ہوتا ہے۔ اگر پورٹل تک رسائی نہ ہو تو تشخیصی ترتیبات فعال ہونے پر وہی تشخیصات گیٹ وے کی لاگ منزل میں ظاہر ہوتی ہیں۔

دو اندراجات زیادہ تر قدر رکھتے ہیں۔ پہلا تقریباً یوں پڑھا جاتا ہے: expected ESP with combined authentication and cipher, received AH. دوسرا IKE تبادلے کے دوران invalid payload کی خرابی ہے، جس کا مطلب عموماً غلط بنا ہوا یا غیر معاون تجویزی فیلڈ ہے۔

دونوں بتاتے ہیں کہ آن پریمائز ڈیوائس نے کیا تجویز کیا، لہٰذا دونوں peer کی طرف کی ترتیبات ہیں۔ کنکشن کی Azure طرف دوبارہ بنانے سے آپ کے فائر وال کا بھیجا ہوا تجویز نہیں بدلتا، اور پھر بھی ایسا کرنا اس کام کا سب سے زیادہ ضائع ہونے والا گھنٹہ ہے۔ peer پر مرحلہ 2 کو مشترکہ تصدیق اور سائفر کے ساتھ ESP پر رکھیں اور الگورتھم پر مذاکرات کرنے دیں، پھر دیکھیں کہ combined mode جیسے نام والا وینڈر چیک باکس نیچے سے خاموشی سے AH تجویز منتخب نہ کر رہا ہو۔

ورچوئل نیٹ ورک کی ایڈریس اسپیس کی تصدیق کریں

گیٹ وے توقع کرتا ہے کہ ورچوئل نیٹ ورک نجی حدود میں ہو۔ عوامی بلاک میں نمبر شدہ نیٹ ورک، مثلاً جو 111.x سے شروع ہوتا ہے، ٹنل کو اوپر لا سکتا ہے جبکہ Azure اس جگہ کو اندرونی سمجھنے سے انکار کرتا ہے، اس لیے کنکشن صحت مند دکھائی دیتا ہے اور کوئی فلو قبول نہیں ہوتا۔ منتخب کنندگان پر دوپہر ضائع کرنے سے پہلے ایڈریس اسپیس کی تصدیق کریں۔ اگر نمبرنگ پرانی تقسیم کی سخت شرط ہو تو حل دوسرا گیٹ وے نہیں بلکہ ایڈریس پلان کی تبدیلی ہے۔

ایڈریس اسپیس بلیڈ میں رہتے ہوئے ہی آن پریمائز حدود کے ساتھ اوورلیپ نوٹ کریں، کیونکہ اوورلیپ ہونے والے پریفکس ایک مختلف ناکامی پیدا کرتے ہیں جو کلائنٹ سے ایک جیسی دکھتی ہے۔

دونوں سمتوں میں پریفکس کی تصدیق کریں

لوکل نیٹ ورک گیٹ وے کا وسیلہ آن پریمائز پریفکس رکھتا ہے اور انہیں ان سب نیٹ سے میل کھانا چاہیے جنہیں دور کا ڈیوائس واقعی محفوظ رکھتا ہے۔ ایسا خلاصہ جس میں وہ پتے شامل ہوں جو ڈیوائس چھوڑ دیتا ہے، کچھ فلو گزرنے دے گا اور کچھ پر ناکام ہوگا، جو کنفیگریشن کی عدم مطابقت کی بجائے وقفے وقفے سے آنے والی روٹنگ خرابی جیسا پڑھا جاتا ہے۔ دور کی طرف بھی دیکھیں: ایک سرا /16 درج کرے جبکہ دوسرا اس کے اندر تین /24 درج کرے — یہی کلاسک جزوی ناکامی ہے۔ کوئی فہرست تنہا مستند نہیں، اس لیے جو آپ دیکھ سکتے ہیں اس پر بھروسہ کرنے کی بجائے دونوں کا ساتھ ساتھ موازنہ کریں۔

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

ping نہیں، راستہ جانچیں

کام کرنے والی ٹنل کو کام کرنے والے راستے سے الگ کرنے والا trace ایسا دکھتا ہے: پہلا hop آن پریمائز گیٹ وے ہے، پھر کچھ بے جواب hop، پھر دور کا میزبان جواب دیتا ہے۔ اگر trace کبھی میزبان تک نہ پہنچے تو وہ TCP پورٹ جانچیں جو ایپلیکیشن واقعی استعمال کرتی ہے، کیونکہ ICMP کافی کثرت سے فلٹر ہوتا ہے کہ ناکام ping بہت کم ثابت کرتا ہے۔ وہی trace دور کے میزبان سے Azure کی ورچوئل مشین کی طرف چلائیں۔ دو نتائج کے درمیان عدم توازن ہی گم شدہ واپسی راستہ یا صرف ایک سمت کی اجازت دینے والا اصول ڈھونڈنے کا تیز ترین طریقہ ہے۔

peer کی تجویز، دونوں ایڈریس اسپیسز اور کنکشن بننے کا وقت ٹکٹ میں لکھیں، تاکہ اگلے انجینئر کو معلوم ہو کہ کون سی قدریں دوبارہ بنیں اور کنہیں کبھی چھوا نہیں گیا۔

اگر لاگ خالی واپس آئے تو ہو سکتا ہے گیٹ وے آپ کا کنکشن بالکل ختم نہ کر رہا ہو۔ تصدیق کریں کہ لوکل نیٹ ورک گیٹ وے پر peer کا پتہ اس ڈیوائس سے میل کھاتا ہے جس سے آپ لاگ پڑھ رہے ہیں، کیونکہ ایک ہی سبسکرپشن میں دو گیٹ وے دوبارہ تعمیر کے دوران آسانی سے الجھ جاتے ہیں۔ وہ غلطی ایک دن لیتی ہے اور کسی بھی لاگ میں نشان نہیں چھوڑتی۔