«التحقق من تدفق IP» في Azure يقول مسموح، لكن VPN ما زال يفشل

النفق من موقع إلى موقع متصل، والجهاز الافتراضي سليم، ومع ذلك لا يحصل العميل المحلي على شيء. تفتح Network Watcher وتشغّل التحقق من تدفق IP فيقول Access allowed، فتُغلق التذكرة على أنها مشكلة VPN. تلك النتيجة لا تعني ما تبدو عليه، لأن التحقق من تدفق IP يقيّم قواعد الأمان للتدفق الذي وصفته ولا يختبر أبداً ما إذا كان لدى Azure مسار إلى بادئتك المحلية.

سؤال التصفية وسؤال التوجيه منفصلان، وNetwork Watcher يجيب عنهما بأدوات مختلفة. معرفة أي السؤالين طرحت هو معظم التشخيص.

ما يقرره التحقق من تدفق IP فعلاً

يأخذ التحقق من تدفق IP جهازاً افتراضياً وواجهة شبكة واتجاهاً وقيم الخماسية وبروتوكولاً، ثم يبلّغ عن قرار قاعدة NSG وقاعدة مسؤول الأمان لذلك التدفق. يعمل على TCP وUDP، لذا ليس أداة اختبار قواعد ICMP، وping محجوب لا يثبت شيئاً عن خدمتك. أعطه التدفق الحقيقي بدل التخمين. الاتصال الوارد من المحلي إلى منفذ قاعدة بيانات وصف مختلف عن اتصال صادر يبدأه الجهاز الافتراضي.

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

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

ما تضيفه الخطوة التالية والمسارات الفعّالة

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

يوضح نظرة عامة على التحقق من تدفق IP من Microsoft نطاق التصفية مباشرة، بينما تغطي صفحات الخطوة التالية وتشخيص المسارات جانب إعادة التوجيه. اقتبس الصفحة الصحيحة عند كتابة النتيجة.

الأوامر قصيرة بما يكفي لتشغيلها من صدفة. az network nic show-effective-route-table يسرد المسارات المطبقة على الواجهة. az network watcher show-next-hop مع مصدر ووجهة يعيد الخطوة المختارة. قارن البادئة التي تهمك بذلك الجدول ثم أكّد أي إدخال يفوز.

امشِ مسار العودة من بطاقة واجهة الجهاز الافتراضي

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

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

اقرأ نوع الخطوة التالية بدل نسخ مثال

مسار بوابة VPN المُدارة يُظهر عادةً VirtualNetworkGateway كنوع الخطوة التالية. VirtualAppliance يصف تصميماً مختلفاً لإعادة التوجيه، عادةً جدار حماية أو جهاز شبكة افتراضي.

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

انتقل إلى الحد الذي لا يزال يفشل

عندما تتوافق التصفية والتوجيه مع التصميم، يكون العطل في مكان آخر. تحقق من جدول مسارات الجهاز نفسه، وجدار حمايته، وهل المستمع مرتبط بالعنوان المتوقع. ثم تحقق من محددات حركة المرور المحمية في VPN ومسار الرد المحلي. كل واحد منها اختبار منفصل بنتيجة منفصلة.

اختم بطلب تطبيق مسموح وملاحظات من الطرفين. نتيجة سماح وخطوة تالية صحيحة هما دليلان، وليسا إثباتاً أن الاتصال نجح.