Доступ до приватної програми Container Apps через VPN «точка — сайт»

Цей посібник описує середовище Container Apps із профілями робочих навантажень і внутрішнім входом у віртуальну мережу, доступним із ноутбука через затверджений VPN «точка — сайт», з використанням прямого FQDN програми та без HTTP-маршрутів на рівні середовища. вхід середовища доступний із боку клієнта, область вхідного трафіку програми допускає викликувача, а ім'я вузла розпізнається в приватний вхід. Кожен крок нижче залишає перевірюваний результат і відкат, який не зачіпає нічого, що ви не змінювали. Пройдіть їх у вказаному порядку, бо жоден наступний крок не компенсує хибно ухвалене рішення про область на кроці 1.

Перш ніж торкатися DNS, з'ясуйте слово внутрішній. У цьому продукті воно використовується для двох різних областей, і їх плутанина — найчастіша причина, чому робоче ім'я досі не повертає нічого корисного.

Крок 1: зафіксуйте область середовища й програми

Прочитайте конфігурацію вхідного трафіку програми, перш ніж змінювати будь-який запис:

Внутрішній вхідний трафік публікується на внутрішньому балансувальнику навантаження середовища всередині 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, приватну адресу входу й власника розпізнавача. Ці п'ять описують увесь договір доступу, і наступна людина, яка це відлагоджуватиме, попросить саме їх.