أين توجد سجلات VPN من نقطة إلى موقع في Azure؟ ابحث عنها في Monitor

يتعذّر على مستخدم الاتصال بالبوابة من نقطة إلى موقع، فتفتح شفرة البوابة، فلا تجد أي سجل اتصالات في أي مكان على الصفحة. التكوين والشهادات والحالة: كلها موجودة، ولا سجلات. السجلات موجودة، لكن صفحات الشبكات لا تُنتجها على الإطلاق. إنها تأتي من إعداد تشخيصي مرتبط بمورد البوابة، وهذا الإعداد يعيش ضمن Monitor، ولهذا لا يعيد البحث الأول في المكان البديهي شيئًا، ويستنتج الناس أن الخدمة لا تحتفظ بأي أثر تدقيق.

لماذا يفشل البحث البديهي

تقول الإرشادات القديمة إن VPN من نقطة إلى موقع في Azure لا يملك أي تدقيق، وكان ذلك صحيحًا حين لم تكن الخدمة تكشف أي سجل لكل اتصال. البوابات الحالية تنشر سجلات تشخيص النفق، لذلك تغيّر السؤال المفيد: لا هل توجد سجلات، بل أي مورد يصدرها وأي فئة فعّلتها. شفرة البوابة سطح تكوين، وأسطح التكوين نادرًا ما تكون عارضات سجلات في الوقت نفسه. الإعداد التشخيصي كائن لكل مورد، لذا فالمورد الذي تختاره يحدد كل ما يلي.

النصف الآخر من الالتباس هو المصادقة. اتصالات نقطة إلى موقع القائمة على الشهادات لا تولّد حدث تسجيل دخول لكل مستخدم كما يفعل مزوّد الهوية، لذا لا يوجد سجل لشخص مسمّى يكتب كلمة مرور كي تجده.

أرفق الإعداد التشخيصي بمورد البوابة

افتح Monitor ثم Diagnostic settings، وأضف إعدادًا جديدًا يكون هدفه بوابة الشبكة الظاهرية نفسها لا الشبكة الظاهرية التي تحتويها. اختر فئة التشخيص من نقطة إلى موقع، الفئة المسماة P2SDiagnosticLog، فهي التي تحمل سجلات الاتصال لكل عميل؛ وأضف فئات النفق أو المسار أو IKE فقط لأخطاء الموقع إلى الموقع التي تغطيها. ثم أرسل البيانات إلى مساحة عمل Log Analytics تتحكم فيها بمدة احتفاظ اخترتها عن قصد. معظم عمليات البحث الفاشلة هي إعداد مرتبط بالمورد الخطأ، لا ميزة مفقودة.

تختلف قوائم الفئات حسب نوع البوابة وجيلها. إذا كانت فئة نقطة إلى موقع غائبة، فقد تكون البوابة أقدم من الميزة أو تشغّل SKU لا يصدرها أبدًا، لذا تحقق من الفئات المدعومة قبل أن تبحث عن مشكلة أذونات. البوابة التي لا تملك فئة نقطة إلى موقع ليست معطوبة؛ إنها ببساطة لا تستطيع أن تكون مصدر ذلك السجل، وأقرب بديل هو فئة النفق أو IKE، التي تسجل عنوان العميل وإن كانت لا تصف جلسة نقطة إلى موقع. أكّد قائمة الفئات قبل أن تفتح حالة دعم بشأن سجلات مفقودة.

اقرأ السجلات في الجدول الذي يستخدمه وضعك

في وضع التجميع القديم تهبط المدخلات في جدول AzureDiagnostics وتظهر الفئة كقيمة عمود؛ وفي الجداول الخاصة بالمورد تكون للبوابة جدولها الخاص. وفي الحالتين استعلم بمورد البوابة ونافذة حول المحاولة الفاشلة، ثم اقرأ الارتباط بدل الصفوف الفردية:

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

تتبع مجموعة الأعمدة وضع التجميع لديك، فتعامل مع الاستعلام كشكل لا كنص برمجي. ما تبحث عنه هو عنوان عميل يظهر ثم يختفي، بنوع نتيجة ليس النجاح.

اقرن سجل البوابة برؤية العميل نفسه

تصف سجلات البوابة النفق، لا سبب فشل حاسوب محمول في بناء واحد. اجمع جانب العميل عند الطابع الزمني نفسه: سجل أحداث Windows لعميل RAS، أو سجل اتصال macOS، أو نص الخطأ الذي عرضه تطبيق العميل. سجل بوابة بلا محاولة عميل مطابقة يشير إلى العميل؛ أما عميل يبلّغ بالنجاح بينما لا تسجل البوابة شيئًا فيعني عادة أن الملف الشخصي موجّه إلى بوابة أخرى.

احتفظ بالنصفين في التذكرة نفسها. سجل البوابة وحده يدعو إلى الاستنتاج الخاطئ، وسجل العميل وحده لا يمكنه أن يُظهر هل وصلت الحزمة أصلًا.

إن لم يظهر شيء في أي من المكانين، فتحقق من ساعة العميل قبل أن تشك في المنصة. الطوابع الزمنية المنحرفة تجعل الارتباط يفشل بطريقة تشبه تمامًا البيانات المفقودة.

الاحتفاظ والنطاق ومدخل دليل التشغيل

تحمل سجلات النفق عناوين العملاء وطوابع أوقات الاتصال، فتعامل معها كبيانات شخصية بجدول حذف بدلًا من ترك الوضع الافتراضي للمنصة. تحقق أيضًا من أن مساحة العمل لا تستوعب كل فئة من كل مورد في الاشتراك، لأن مساحة عمل مزدحمة تجعل الارتباط أبطأ من قراءة سجل العميل مباشرة.

وأخيرًا، اكتب اسم الإعداد ومساحة العمل والفئات المختارة في دليل تشغيل البوابة. أول من سيشخّص عميلًا سينظر في شفرة البوابة أولًا، فلا يجد شيئًا، ويستنتج أن السجلات غير موجودة.