Azure Site VPN نگرانی: ٹنل کی حالت کو حقیقی پروب کے ساتھ جوڑیں

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

ٹنل سے نہیں، ناکام ہونے والی علامت سے شروع کریں

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

تین حالتیں الگ ہونی چاہئیں: ٹنل بند ہے، ٹنل چل رہا ہے مگر سروس ناکام ہے، اور نگرانی کا ذریعہ خود دستیاب نہیں۔

پروب کو وہاں رکھیں جہاں صارفین ہیں

برانچ سے Azure ایپ کے لیے، مصنوعی ٹیسٹ برانچ کے ورک لوڈ نیٹ ورک کے میزبان سے چلائیں اور اسے نجی HTTPS داخلی نقطے کی طرف نشانہ بنائیں جہاں صارفین واقعی پہنچتے ہیں۔ گیٹ وے سے شروع کیا گیا پروب مختلف ماخذ پتہ اور اکثر مختلف پالیسی راستہ استعمال کرتا ہے، اس لیے ہر صارف کے ناکام ہونے کے باوجود وہ کامیاب ہو سکتا ہے۔ Azure Connection Monitor ٹیسٹ گروپوں اور حدوں کے ساتھ TCP، ICMP اور HTTP جانچ کی حمایت کرتا ہے، اور اس کے مقامی ذرائع کے ایجنٹ تقاضے Azure کی جانب والوں سے مختلف ہیں۔ بلاگ سے ریٹائر شدہ کلاسک نگرانی کی ترکیب نقل کرنے کے بجائے موجودہ معاون ترتیب جانچیں۔

پروب کو تنگ اور بیزار کن رکھیں: ایک منزل، ایک پورٹ، آپریشنل ضرورت سے مطابق تعدد، اور اس ماخذ کے لیے واضح اجازت قاعدہ۔

سروس سے مطابقت رکھنے والی جانچ منتخب کریں

سروس پورٹ پر TCP کنکشن ٹنل کے ذریعے نقل و حمل کی رسائی ثابت کرتا ہے اور TLS یا ایپ کے بارے میں کچھ نہیں کہتا۔ HTTP جانچ حالت کی توقع شامل کرتی ہے اور ایسے سامع کو پکڑتی ہے جو کنکشن قبول کرتا ہے مگر خدمت نہیں دے سکتا، جو سرٹیفکیٹ یا بیک اینڈ تبدیلی کے بعد زیادہ عام ناکامی ہے۔ ٹیسٹ واقعی تصدیق نہ کرے تو دونوں میں سے کوئی تصدیق شدہ کاروباری لین دین نہیں، اس لیے ڈیش بورڈ پر ایسا لیبل نہ لگائیں۔ وہ جانچ منتخب کریں جو صارف کی شکایت کے وقت ناکام ہو۔

ICMP تینوں میں سب سے کمزور اختیار ہے، کیونکہ بہت سے اسٹیک پالیسی کے تحت اسے چھوڑ دیتے ہیں اور ناکام پنگ بہت کم ثابت کرتا ہے۔

دونوں اشارے بنائے بغیر Elastic میں لائیں

VPN گیٹ وے ٹنل کے خارجی اور داخلی بائٹس اور پیکٹ ڈراپ کاؤنٹر جیسے پلیٹ فارم میٹرکس خارج کرتا ہے، اور ٹنل و IKE واقعات سمیت زمروں میں تشخیصی لاگ بھیج سکتا ہے۔ Connection Monitor کے نتائج Azure Monitor کے ذریعے میٹرکس اور Log Analytics ورک اسپیس کے ذریعے لاگ ریکارڈ کے طور پر آتے ہیں۔ ان میں سے کچھ بھی خود بخود Elastic انڈیکس میں ظاہر نہیں ہوتا۔ میٹرکس کے لیے ایک معاون پائپ لائن اور لاگ کے لیے دوسری منتخب کریں، عام طور پر Azure Event Hub ان پٹ یا Azure Monitor انٹیگریشن، اور انڈیکس پیٹرن پر بھروسہ کرنے سے پہلے جانچیں کہ نصب شدہ انٹیگریشن واقعی کیا وصول کرتی ہے۔

وہ لیبل رکھیں جو آپریٹر کو دو ڈیٹاسیٹ جوڑنے دیں: پروب کے لیے ماخذ اختتامی نقطہ، منزل، پروٹوکول اور پورٹ، اور گیٹ وے کے لیے ٹنل شناخت اور ساتھی کا پتہ۔

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

رنگ پر نہیں، فرق پر انتباہ کریں

دو اشارے رکھنے کا مقصد امتزاج میں ہے۔ ٹنل بند ہو تو نیٹ ورک کے مالک کو فون کریں؛ ٹنل چل رہا ہو اور پروب ناکام ہو تو ایپ کے مالک کو؛ پروب کا نتیجہ غائب ہو تو نگرانی کے ایجنٹ کے مالک کو۔ تینوں کو ایک سرخ پینل میں ڈال دینے سے انتباہ ایک ماہ میں خاموش ہو جائے گا یقینی۔ ایک نمونے پر نہیں، استحکام کی ونڈو کے ساتھ مسلسل ناکامی پر انتباہ کریں، اور انجشن پائپ لائن کی اپنی صحت کے لیے الگ جانچ شامل کریں۔

کل کے کامیاب نمونوں سے بھرا ڈیش بورڈ آج صحت مند راستے کے طور پر نہیں پڑھا جانا چاہیے۔

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