Aceder a uma aplicação privada do Container Apps através de VPN ponto a site
Um ambiente interno do Container Apps precisa de uma entrada privada, um nome de anfitrião correspondente e um resolvedor que a VPN consiga alcançar. Execute cada passo e depois verifique a negação.
Este manual cobre um ambiente do Container Apps com perfis de carga de trabalho e uma entrada de rede virtual interna, alcançada a partir de um portátil através de uma VPN ponto a site aprovada, usando o FQDN direto da aplicação e sem rotas HTTP ao nível do ambiente. a entrada do ambiente é acessível a partir do cliente, o âmbito de entrada da aplicação admite o autor da chamada, e o nome de anfitrião é resolvido para a entrada privada. Cada passo abaixo deixa um resultado verificável e uma reversão que não toca em nada que não tenha alterado. Percorra-os na ordem indicada, porque nenhum passo posterior consegue compensar uma decisão de âmbito tomada incorretamente no passo 1.
Antes de tocar no DNS, esclareça a palavra interno. É usada para dois âmbitos diferentes neste produto, e trocá-los é a razão mais comum para um nome que funciona continuar a não devolver nada de útil.
Passo 1: fixar o âmbito do ambiente e da aplicação
Leia a configuração de entrada da aplicação antes de alterar qualquer registo:
| 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 |
A entrada interna é exposta no balanceador de carga interno do ambiente dentro da VNet do ambiente, pelo que a questão não é se o portátil é outra aplicação de contentores, mas se consegue alcançar essa VNet. Um cliente VPN com uma rota para a VNet e o domínio predefinido do ambiente resolvido através da zona privada é um autor de chamada elegível, e é exatamente isso que os restantes passos constroem. Um ambiente interno sem entrada pública é um facto diferente de uma aplicação com entrada interna, e a entrada externa ao nível da aplicação não dá ao ambiente uma porta pública. Escreva o âmbito no ticket e também no portal, porque o próximo engenheiro lê primeiro o ticket.
Confirme esse âmbito com o proprietário da configuração antes de continuar, e mantenha o portão estreito: se não existir qualquer rota para a VNet do ambiente, ou o domínio predefinido do ambiente não for resolvido através da zona privada, pare e corrija primeiro esse caminho. Nenhum passo posterior consegue substituir um autor de chamada que não alcança a VNet nem resolve o nome.
Passo 2: recolher o nome de anfitrião real e o endereço de entrada
Registe o domínio predefinido do ambiente, o seu endereço de entrada privado estático e o FQDN configurado da aplicação, obtidos do recurso e não de uma captura de ecrã antiga ou de uma página wiki:
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"As orientações para a entrada privada do Container Apps descrevem o alinhamento do domínio do ambiente com o seu endereço interno, mantendo intactos os nomes de anfitrião da aplicação. É exatamente a forma que está a construir à mão aqui, por isso alinhe o conteúdo da zona com ela em vez de inventar um novo esquema de nomes.
Se o domínio que leu não corresponder ao FQDN que a aplicação reporta, pare e reconcilie-os agora. Construir uma zona com o sufixo errado produz um nome de anfitrião que é resolvido na perfeição e ainda assim acaba no anfitrião virtual errado.
Passo 3: colocar a zona privada no caminho do resolvedor da VPN
Crie ou reutilize a zona DNS privada suportada para o domínio predefinido real do ambiente, com os registos de curinga e de endereço documentados a apontar para a entrada estática. Ligue essa zona à rede virtual adequada e torne a autoridade privada acessível através do caminho de resolvedor aprovado da VPN, em vez de presumir que a ligação é suficiente.
Um cliente ponto a site normalmente precisa de um ponto final de entrada de um resolvedor privado ou de um reencaminhador DNS suportado para alcançar essa zona. Ligar uma zona altera o que o Azure resolve para as redes ligadas; não redireciona o resolvedor público de cada portátil externo. Não a substitua por uma zona DNS de ponto final privado emprestada de outro modelo de rede do Container Apps, porque os nomes dos registos e o sufixo da zona não vão coincidir.
A reversão deste passo é remover a ligação da zona ou o registo que adicionou. Registe qual dos dois era, porque eliminar uma zona partilhada para desfazer uma única ligação é uma forma bem conhecida de quebrar um segundo ambiente.
Passo 4: testar o nome e depois o público negado
Teste o nome de anfitrião e a identidade TLS em conjunto, não apenas o endereço. Para um diagnóstico controlado de mapeamento de nomes pode fixar o endereço mantendo o nome de anfitrião:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Substitua o nome de anfitrião pelo FQDN real da aplicação e o endereço pela entrada interna real. Isto afeta apenas esse pedido e não é aprovisionamento de DNS. Não adicione -k para transformar uma falha de identidade numa passagem aparente, porque uma incompatibilidade de certificado é o sinal de que está a atingir o serviço de escuta errado.
Pedir o endereço numérico diretamente pode selecionar o anfitrião virtual errado ou falhar a validação mesmo enquanto o TCP 443 responde, por isso trate um teste de IP bem-sucedido como evidência sobre a rede e nada mais. A partir do portátil previsto, o caminho normal do resolvedor é o reencaminhador DNS do cliente ou o ponto final de entrada do resolvedor privado que aloja a zona, e uma falha aí é um problema de acessibilidade do resolvedor, não um registo em falta. Confirme que o mesmo pedido tem sucesso nesse caminho e depois confirme que o público negado continua negado.
O que registar e o que reverter
A porta de destino do contentor e a porta HTTPS do cliente são definições separadas. Não publique a porta de destino do contentor através da VPN porque o contentor escuta aí, e não alargue uma regra de rede para fazer passar um teste de porta. Ambas as alterações sobrevivem ao incidente e depois são difíceis de atribuir.
Termine com uma operação nova da aplicação a partir do portátil previsto, com a sua identidade autorizada e o seu DNS normal, e depois verifique que um autor de chamada não autorizado continua a falhar. Enquanto estiver na configuração da aplicação, confirme também se uma rota HTTP ao nível do ambiente expõe esta aplicação como destino, porque essa rota é uma segunda porta que o âmbito de entrada não descreve.
Registe cinco valores em conjunto: âmbito do ambiente, âmbito de entrada da aplicação, FQDN, endereço de entrada privado e proprietário do resolvedor. Esses cinco descrevem todo o contrato de acesso, e a próxima pessoa que o depurar vai pedir exatamente esses.