Доступ к частному приложению Container Apps через VPN «точка — сайт»

Внутренней среде Container Apps нужны частный вход, подходящее имя узла и сопоставитель, до которого VPN может добраться. Выполните каждый шаг, затем проверьте отказ.

Это руководство описывает среду 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, частный адрес входа и владельца сопоставителя. Эти пять описывают весь договор доступа, и следующий человек, который будет это отлаживать, попросит именно их.

Похожие статьи