Azure Point-to-Site VPN کے لاگز کہاں ہیں؟ Monitor میں دیکھیں

صارف Point-to-Site گیٹ وے سے جڑ نہیں سکتا، آپ گیٹ وے بلیڈ کھولتے ہیں، اور صفحے پر کہیں بھی کنکشن کی تاریخ نہیں ہے۔ کنفیگریشن، سرٹیفکیٹ، حالت: سب موجود، کوئی ریکارڈ نہیں۔ لاگز موجود ہیں، لیکن نیٹ ورکنگ صفحات انہیں بالکل نہیں بناتے۔ وہ گیٹ وے ریسورس سے منسلک ایک ڈائگناسٹک سیٹنگ سے آتے ہیں، اور وہ سیٹنگ Monitor کے تحت رہتی ہے؛ اسی لیے واضح جگہ پر پہلی تلاش کچھ واپس نہیں کرتی، اور لوگ نتیجہ نکالتے ہیں کہ سروس کوئی آڈٹ ٹریل نہیں رکھتی۔

واضح تلاش کیوں ناکام ہوتی ہے

پرانے رہنما کہتے ہیں کہ Azure Point-to-Site VPN میں کوئی آڈٹ نہیں ہے، اور یہ تب سچ تھا جب سروس ہر کنکشن کا کوئی ریکارڈ ظاہر نہیں کرتی تھی۔ موجودہ گیٹ وے ٹنل کے ڈائگناسٹک ریکارڈ شائع کرتے ہیں، اس لیے مفید سوال بدل گیا ہے: لاگز ہیں یا نہیں یہ نہیں، بلکہ کون سا ریسورس انہیں جاری کرتا ہے اور آپ نے کون سی قسم فعال کی۔ گیٹ وے بلیڈ ایک کنفیگریشن سطح ہے، اور کنفیگریشن سطحیں شاذ و نادر ہی لاگ ویور کا کام بھی کرتی ہیں۔ ڈائگناسٹک سیٹنگ فی ریسورس ایک شے ہے، اس لیے آپ کا منتخب کردہ ریسورس آگے کا سب کچھ طے کرتا ہے۔

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

ڈائگناسٹک سیٹنگ کو گیٹ وے ریسورس سے منسلک کریں

Monitor کھولیں، پھر Diagnostic settings، اور نئی سیٹنگ شامل کریں جس کا ہدف خود ورچوئل نیٹ ورک گیٹ وے ہو، نہ کہ وہ ورچوئل نیٹ ورک جو اسے رکھتا ہے۔ Point-to-Site ڈائگناسٹک قسم منتخب کریں، وہ جس کا نام P2SDiagnosticLog ہے، کیونکہ وہی فی کلائنٹ کنکشن ریکارڈ رکھتی ہے؛ ٹنل، روٹ یا IKE اقسام صرف ان site-to-site غلطیوں کے لیے شامل کریں جنہیں وہ ڈھانپتی ہیں۔ پھر ڈیٹا اس Log Analytics ورک اسپیس میں بھیجیں جسے آپ کنٹرول کرتے ہیں، ایسی مدتِ برقراری کے ساتھ جو آپ نے جان بوجھ کر منتخب کی۔ زیادہ تر ناکام تلاشیں غلط ریسورس سے منسلک سیٹنگ ہوتی ہیں، کوئی غائب خصوصیت نہیں۔

اقسام کی فہرستیں گیٹ وے کی قسم اور نسل کے مطابق مختلف ہوتی ہیں۔ اگر Point-to-Site قسم موجود نہیں، تو گیٹ وے اس خصوصیت سے پرانا ہو سکتا ہے یا ایسی SKU پر چل رہا ہو جو اسے کبھی جاری نہیں کرتی، اس لیے اجازت کا مسئلہ تلاش کرنے سے پہلے معاون اقسام جانچیں۔ Point-to-Site قسم کے بغیر گیٹ وے خراب نہیں؛ یہ صرف اس ریکارڈ کا ماخذ نہیں ہو سکتا، اور قریب ترین متبادل ٹنل یا IKE قسم ہے، جو Point-to-Site سیشن بیان نہ کرنے کے باوجود کلائنٹ کا پتہ ریکارڈ کرتی ہے۔ غائب لاگز کے بارے میں سپورٹ کیس کھولنے سے پہلے اقسام کی فہرست کی تصدیق کریں۔

ریکارڈ اس جدول میں پڑھیں جو آپ کا موڈ استعمال کرتا ہے

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

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

کالم کا مجموعہ آپ کے جمع کرنے کے موڈ کی پیروی کرتا ہے، اس لیے استفسار کو اسکرپٹ نہیں، شکل سمجھیں۔ آپ جو تلاش کر رہے ہیں وہ کلائنٹ کا پتہ ہے جو ظاہر ہوتا ہے اور پھر غائب ہو جاتا ہے، ایسی نتیجہ قسم کے ساتھ جو کامیابی نہیں ہے۔

گیٹ وے ریکارڈ کو کلائنٹ کے اپنے نقطہ نظر سے جوڑیں

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

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

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

برقراری، دائرہ اور رن بک اندراج

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

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