الوصول إلى تطبيق Container Apps خاص عبر VPN من نقطة إلى موقع
تحتاج بيئة Container Apps داخلية إلى مدخل خاص واسم مضيف مطابق ومحلل أسماء يمكن لشبكة VPN الوصول إليه. نفّذ كل خطوة، ثم تحقّق من الرفض.
يغطي هذا الدليل بيئة Container Apps ذات ملفات تعريف عبء العمل مع مدخل شبكة افتراضية داخلي، يُوصَل إليه من حاسوب محمول عبر VPN من نقطة إلى موقع معتمدة، باستخدام اسم FQDN المباشر للتطبيق ودون مسارات HTTP على مستوى البيئة. مدخل البيئة قابل للوصول من العميل، ونطاق الدخول في التطبيق يسمح للمتصل، واسم المضيف يُحلّ إلى المدخل الخاص. تترك كل خطوة أدناه نتيجة قابلة للتحقق وتراجعًا لا يمسّ شيئًا لم تغيّره. نفّذها بالترتيب المحدد، لأن أي خطوة لاحقة لا يمكنها تعويض قرار نطاق اتُّخذ خطأً في الخطوة 1.
قبل أن تمسّ DNS، حدِّد معنى كلمة داخلي. فهي تُستخدم لنطاقين مختلفين في هذا المنتج، وتبديلهما هو السبب الأكثر شيوعًا في أن يظل اسم عامل عائدًا بلا شيء مفيد.
الخطوة 1: ثبّت نطاق البيئة والتطبيق
اقرأ إعداد الدخول الخاص بالتطبيق قبل تغيير أي سجل:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
يُكشف الدخول الداخلي على موازن التحميل الداخلي للبيئة داخل شبكة VNet الخاصة بالبيئة، لذا فالسؤال ليس ما إذا كان الحاسوب المحمول تطبيق حاويات آخر، بل ما إذا كان يستطيع الوصول إلى شبكة VNet تلك. عميل VPN لديه مسار إلى شبكة VNet والنطاق الافتراضي للبيئة يُحلّ عبر المنطقة الخاصة هو متصل مؤهل، وهذا ما تبنيه الخطوات المتبقية. البيئة الداخلية بلا مدخل عام حقيقة مختلفة عن تطبيق ذي دخول داخلي، والدخول الخارجي على مستوى التطبيق لا يمنح البيئة بابًا عامًا. اكتب النطاق في التذكرة وعلى البوابة معًا، لأن المهندس التالي يقرأ التذكرة أولًا.
أكّد ذلك النطاق مع مالك الإعداد قبل المتابعة، وأبقِ البوابة ضيقة: إن لم يوجد مسار إلى شبكة VNet الخاصة بالبيئة، أو لم يُحلّ النطاق الافتراضي للبيئة عبر المنطقة الخاصة، فتوقّف وأصلح ذلك المسار أولًا. لا خطوة لاحقة يمكنها أن تعوّض متصلًا لا يستطيع الوصول إلى شبكة VNet أو حلّ الاسم.
الخطوة 2: اجمع اسم المضيف الحقيقي وعنوان المدخل
سجّل النطاق الافتراضي للبيئة وعنوان مدخلها الخاص الثابت واسم FQDN المهيّأ للتطبيق، مأخوذة من المورد لا من لقطة شاشة قديمة أو صفحة ويكي:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"إن إرشادات المدخل الخاص في Container Apps تصف مطابقة نطاق البيئة مع عنوانه الداخلي مع الحفاظ على أسماء مضيف التطبيق سليمة. وهذا بالضبط الشكل الذي تبنيه يدويًا هنا، فطابق محتويات المنطقة معه بدلًا من اختراع مخطط تسمية.
إن لم يطابق النطاق الذي قرأته اسم FQDN الذي يبلغ عنه التطبيق، فتوقّف ووفّق بينهما الآن. فبناء منطقة على اللاحقة الخاطئة ينتج اسم مضيف يُحلّ تمامًا ومع ذلك يهبط على المضيف الافتراضي الخطأ.
الخطوة 3: ضع المنطقة الخاصة على مسار المحلل في VPN
أنشئ منطقة DNS الخاصة المدعومة أو أعد استخدامها للنطاق الافتراضي الفعلي للبيئة، مع سجلات الحرف البديل والعنوان الموثقة التي تشير إلى المدخل الثابت. اربط تلك المنطقة بالشبكة الافتراضية المناسبة، واجعل السلطة الخاصة قابلة للوصول عبر مسار المحلل المعتمد في VPN بدلًا من افتراض أن الربط كافٍ.
يحتاج عميل النقطة إلى الموقع عادةً إلى نقطة نهاية واردة لمحلل خاص أو مُمرِّر DNS مدعوم للوصول إلى تلك المنطقة. ربط منطقة يغيّر ما يحلّه Azure للشبكات المرتبطة؛ لكنه لا يعيد توجيه المحلل العام لكل حاسوب محمول خارجي. لا تستبدل بمنطقة DNS لنقطة نهاية خاصة مستعارة من نموذج شبكات Container Apps مختلف، لأن أسماء السجلات ولاحقة المنطقة لن تتطابق.
التراجع عن هذه الخطوة هو إزالة ربط المنطقة أو السجل الذي أضفته. دوّن أيّهما كان، لأن حذف منطقة مشتركة للتراجع عن ربط واحد طريقة معروفة لكسر بيئة ثانية.
الخطوة 4: اختبر الاسم، ثم الجمهور المرفوض
اختبر اسم المضيف وهوية TLS معًا، لا العنوان وحده. لتشخيص مُتحكَّم فيه لتعيين الأسماء يمكنك تثبيت العنوان مع الحفاظ على اسم المضيف:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/استبدل اسم المضيف باسم FQDN الحقيقي للتطبيق والعنوان بالمدخل الداخلي الحقيقي. هذا يؤثر في ذلك الطلب وحده وليس تزويد DNS. لا تُضف -k لتحويل فشل هوية إلى نجاح ظاهري، لأن عدم تطابق الشهادة هو الإشارة إلى أنك تصيب المستمع الخطأ.
طلب العنوان الرقمي مباشرة قد يختار المضيف الافتراضي الخطأ أو يفشل التحقق حتى بينما يجيب TCP 443، فاعتبر اختبار IP الناجح دليلًا على الشبكة لا أكثر. من الحاسوب المحمول المقصود، مسار المحلل الطبيعي هو مُمرِّر DNS للعميل أو نقطة النهاية الواردة للمحلل الخاص التي تستضيف المنطقة، والفشل هناك مشكلة في إمكانية الوصول إلى المحلل لا سجل مفقود. أكّد نجاح الطلب نفسه على ذلك المسار، ثم أكّد أن الجمهور المرفوض ما زال مرفوضًا.
ما الذي يجب تسجيله، وما الذي يجب التراجع عنه
منفذ هدف الحاوية ومنفذ HTTPS للعميل إعدادان منفصلان. لا تنشر منفذ هدف الحاوية عبر VPN لأن الحاوية تستمع هناك، ولا توسّع قاعدة شبكة لاجتياز اختبار منفذ. كلا التغييرين يعيش بعد الحادث ويصعب نسبه لاحقًا.
اختم بعملية تطبيق جديدة من الحاسوب المحمول المقصود، باستخدام هويته المصرح بها و DNS العادي، ثم تحقّق من أن متصلًا غير مصرح به ما زال يفشل. وأثناء وجودك في إعداد التطبيق، تحقّق أيضًا مما إذا كان مسار HTTP على مستوى البيئة يعرّض هذا التطبيق كهدف، لأن ذلك المسار باب ثانٍ لا يصفه نطاق الدخول.
سجّل خمس قيم معًا: نطاق البيئة، ونطاق دخول التطبيق، واسم FQDN، وعنوان المدخل الخاص، ومالك المحلل. تلك الخمس تصف عقد الوصول كله، والشخص التالي الذي سيصلحه سيطلبها بالضبط.