كيف يصل تطبيق Azure Web إلى أماكن العمل من خلال VPN

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

ما يرسله العامل فعليًا

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

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

تتبع حركة مرور التكوين، مثل سحب صورة الحاوية عند بدء التشغيل، قواعد التوجيه الخاصة بها ويمكن أن تفشل أثناء نجاح استدعاءات واجهة برمجة التطبيقات (API).

الشبكة الفرعية للتكامل هي المصدر الذي يجب أن تسمح به

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

لا تسمح بعنوان عامل واحد حدث أن لاحظته. تتغير المثيلات مع التوسع وصيانة النظام الأساسي، وتنقطع القاعدة المثبتة على عنوان واحد في أسوأ الأوقات.

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

التناظر وعبور البوابة واضحان

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

يعد التصميم المحوري والشعاعي الذي يرسل جدول توجيهه 0.0.0.0/0 إلى جدار الحماية متغيرًا شائعًا، ويحتاج جدار الحماية بعد ذلك إلى قاعدة خاصة به للبادئة المحلية.

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

نقطة النهاية الخاصة للداخل هي الاتجاه الآخر

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

تصف الوثائق الأقدم التكامل الذي تتطلبه البوابة والمبني على VPN من نقطة إلى موقع، وهي ميزة مختلفة لها متطلباتها الخاصة. قامت Microsoft بجدولة إيقاف هذه الميزة في 31 مارس 2027، وتوصي بالتكامل الإقليمي بدلاً من ذلك.

لا تقم بنسخ تكوين نقطة إلى موقع قديم لمجرد أن أحد الأمثلة القديمة استخدمه.

تحقق باستخدام سياق التطبيق الخاص

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

تثبت حالة النفق الأخضر أن البوابة مفتوحة فقط. ولا يذكر شيئًا عن المحددات أو قواعد جدار الحماية أو DNS.

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