حركة العودة في VPN من نوع P2S على Azure تعمل في اتجاه واحد فقط

أيقونة النفق خضراء، ويبدو NSG متسامحًا، وتبدو المسارات الفعلية سليمة، ومع ذلك لا يزال الجهاز الظاهري عاجزًا عن فتح اتصال عائد إلى العميل المتصل. الافتراض المعتاد هو أن نفق point-to-site العامل متماثل: إذا وصل العميل إلى الجهاز الظاهري، وصل الجهاز الظاهري إلى العميل. هذا الافتراض هو الخطأ في الاستدلال، لا في التهيئة. يمكن للنفق أن يحمل اتجاهًا واحدًا من تدفق غير مطلوب ويُسقط الاتجاه الآخر، ويتوقف الإصلاح على الطبقة التي تُسقطه.

خرافة: النفق المتصل نفق ثنائي الاتجاه

نفق VPN مسار سياسي، لا سلك. يُطابق كل اتجاه مقابل المحددات والمسارات والمرشّحات، وأي منها يمكنه السماح باتجاه واحد مع حجب الآخر.

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

افحص الاتجاه قبل أن تفحص قابلية الوصول

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

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

مسار العودة في IKEv2 point-to-site هو المشتبه المعتاد

في تقرير Azure الذي تقوم عليه هذه المقالة، كان العميل يصل إلى الأجهزة الظاهرية عبر IKEv2، لكن ICMP الوارد من الجهاز الظاهري إلى العميل فشل حتى حُوّل نوع نفق البوابة إلى OpenVPN. يذكر صاحب التقرير أن Microsoft أكدت وجود قيد في مسار IKEv2 point-to-site، حيث لا تُوجَّه حركة العودة من الجهاز الظاهري إلى العميل بشكل متماثل ما لم يكن العميل قد بدأ الجلسة. يعتمد IKEv2 على محددات الحركة، ولم تحترم البوابة اتجاه العودة في تلك الحالة.

هذا لا يجعل OpenVPN نوع النفق الأفضل عمومًا. لكنه يجعل نوع النفق متغيرًا في مصفوفة الاختبار لهذا الحمل.

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

خرافة: اكتشاف البث يعبر حدود VNet

يفشل افتراض ثانٍ لسبب غير مرتبط. لا تنقل الشبكة الظاهرية في Azure حركة البث، لذا لا يمكن للجهاز الظاهري استقبال إطارات بث من شبكة محلية عبر اتصال site-to-site أو point-to-site. التطبيقات التي تعثر على الأقران عبر البث، مثل استعراض الملفات القديم أو بعض بروتوكولات اكتشاف الأجهزة، لن ترى الطرف البعيد أبدًا مهما كُتبت المسارات.

استبدل اكتشاف البث بأسماء DNS أو خدمة دليل أو قائمة أقران صريحة. إذا لم يكن للتطبيق بديل أحادي الإرسال (unicast)، فالتصميم يحتاج آلية اكتشاف مختلفة، لا نفقًا أوسع.

ما الذي يجب تغييره، وكيف تثبت ذلك

إذا فشل اختبار الاتجاه على IKEv2 فقط، فسجّل نوع نفق البوابة ومجمّع عناوين العملاء واختبار ICMP أو TCP الدقيق، ثم قيّم ملف تعريف OpenVPN معتمدًا للعملاء المتأثرين. وإذا فشل على كل أنواع الأنفاق، فاعمل على مسار العودة: يجب أن يكون عنوان العميل قابلًا للتوجيه من الشبكة الفرعية للجهاز الظاهري، ويجب أن يشير أي مسار يحدده المستخدم إلى قفزة تالية صالحة، ويجب أن يقبل جدار الحماية في العميل التدفق الوارد. أرفق أدلة NSG والمسارات إلى التذكرة.

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