مراقبة VPN في Azure Site: اربط حالة النفق بفحص حقيقي

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

ابدأ من العَرَض الفاشل، لا من النفق

ارتباط أمني قائم يعني أن الطرفين اتفقا على اقتراح وثبّتا مفاتيح. ولا يعني أن المحدِّدات تغطي الشبكة الفرعية التي يحتاجها المستخدم، أو أن الطرف البعيد لديه مسار عودة، أو أن جدارًا ناريًا يقبل المنفذ بعد فك التشفير. قد تفشل الحركة أيضًا على جانب الفرع من النفق، وعندها لا يرى 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 وافحص طابعه الزمني ووسوم الموارد. مستند بطابع زمني خاطئ أسوأ من مستند مفقود، لأنه يجعل البيانات القديمة تبدو حديثة.

نبّه على الفرق، لا على اللون

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

لوحة معلومات مليئة بعيّنات ناجحة من الأمس يجب ألا تُقرأ كمسار سليم اليوم.

مكتوبًا، العقد صغير: مقياس النفق يخبرك أن البوابة تفاوضت، والفحص يخبرك أن المسار يعمل من حيث يجلس المستخدمون، وصحة خط الأنابيب تخبرك هل أي من الجوابين حديث. كل ما عدا ذلك على اللوحة تعليق.