این راهنما محیطی از Container Apps با پروفایل‌های بار کاری و ورودی شبکه مجازی داخلی را پوشش می‌دهد که از یک لپ‌تاپ از طریق VPN تأییدشده نقطه به سایت و با استفاده از FQDN مستقیم برنامه و بدون مسیرهای HTTP در سطح محیط به آن دسترسی پیدا می‌شود. ورودی محیط از سمت کلاینت قابل دسترسی است، دامنه ورود برنامه فراخوان را می‌پذیرد و نام میزبان به ورودی خصوصی تفکیک می‌شود. هر مرحله در ادامه یک نتیجه قابل بررسی و یک بازگردانی بر جای می‌گذارد که به چیزی که تغییر نداده‌اید دست نمی‌زند. آنها را به ترتیب داده‌شده انجام دهید، زیرا هیچ مرحله بعدی نمی‌تواند تصمیم دامنه‌ای را که در مرحله 1 اشتباه گرفته شده جبران کند.

پیش از دست زدن به DNS، واژه داخلی را روشن کنید. در این محصول از آن برای دو دامنه متفاوت استفاده می‌شود و جابه‌جا کردن آنها رایج‌ترین دلیل بازگرداندن هیچ چیز مفیدی توسط نامی است که کار می‌کند.

مرحله 1: دامنه محیط و برنامه را تثبیت کنید

پیش از تغییر هر رکورد، پیکربندی ورود برنامه را بخوانید:

SettingBoundary
Internal environmentThe environment entry is reached through its private network arrangement
App with internal ingressCallers 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 environmentThe 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، نشانی ورودی خصوصی و مالک حل‌کننده. همان پنج مقدار کل قرارداد دسترسی را توصیف می‌کنند و نفر بعدی که آن را اشکال‌زدایی کند دقیقاً همین‌ها را خواهد خواست.

مقالات مرتبط