Atteindre une application Container Apps privée via un VPN point à site
Un environnement Container Apps interne a besoin d'une entrée privée, d'un nom d'hôte correspondant et d'un résolveur que le VPN peut joindre. Exécutez chaque étape, puis vérifiez le refus.
Ce guide couvre un environnement Container Apps avec profils de charge de travail et une entrée de réseau virtuel interne, joignable depuis un ordinateur portable via un VPN point à site approuvé, en utilisant le FQDN direct de l'application et sans routes HTTP au niveau de l'environnement. l'entrée de l'environnement est joignable depuis le client, la portée d'entrée de l'application admet l'appelant, et le nom d'hôte se résout vers l'entrée privée. Chaque étape ci-dessous laisse un résultat vérifiable et un retour arrière qui ne touche à rien que vous n'ayez modifié. Suivez-les dans l'ordre indiqué, car aucune étape ultérieure ne peut compenser une décision de portée prise à tort à l'étape 1.
Avant de toucher au DNS, clarifiez le mot interne. Il est utilisé pour deux portées différentes dans ce produit, et les confondre est la raison la plus courante pour laquelle un nom qui fonctionne ne renvoie toujours rien d'utile.
Étape 1 : fixer la portée de l'environnement et de l'application
Lisez la configuration d'entrée de l'application avant de modifier le moindre enregistrement :
| 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 |
L'entrée interne est exposée sur l'équilibreur de charge interne de l'environnement à l'intérieur du VNet de l'environnement, la question n'est donc pas de savoir si l'ordinateur portable est une autre application conteneurisée, mais s'il peut atteindre ce VNet. Un client VPN disposant d'une route vers le VNet et du domaine par défaut de l'environnement résolu via la zone privée est un appelant éligible, et c'est exactement ce que construisent les étapes restantes. Un environnement interne sans entrée publique est un fait différent d'une application avec entrée interne, et une entrée externe au niveau de l'application ne donne pas à l'environnement une porte publique. Écrivez la portée dans le ticket ainsi que dans le portail, car l'ingénieur suivant lit d'abord le ticket.
Confirmez cette portée avec le propriétaire de la configuration avant de continuer, et gardez la porte étroite : s'il n'existe aucune route vers le VNet de l'environnement, ou si le domaine par défaut de l'environnement ne se résout pas via la zone privée, arrêtez-vous et corrigez d'abord ce chemin. Aucune étape ultérieure ne peut remplacer un appelant qui ne peut pas atteindre le VNet ni résoudre le nom.
Étape 2 : collecter le vrai nom d'hôte et l'adresse d'entrée
Notez le domaine par défaut de l'environnement, son adresse d'entrée privée statique et le FQDN configuré de l'application, pris depuis la ressource et non depuis une ancienne capture d'écran ou une page 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"Le guide de l'entrée privée de Container Apps décrit l'alignement du domaine de l'environnement sur son adresse interne tout en gardant les noms d'hôte de l'application intacts. C'est exactement la forme que vous construisez à la main ici, alors alignez le contenu de la zone dessus au lieu d'inventer un nouveau schéma de nommage.
Si le domaine que vous avez lu ne correspond pas au FQDN rapporté par l'application, arrêtez-vous et réconciliez-les maintenant. Construire une zone sur le mauvais suffixe produit un nom d'hôte qui se résout parfaitement et atterrit tout de même sur le mauvais hôte virtuel.
Étape 3 : placer la zone privée sur le chemin du résolveur du VPN
Créez ou réutilisez la zone DNS privée prise en charge pour le domaine par défaut réel de l'environnement, avec les enregistrements génériques et d'adresse documentés pointant vers l'entrée statique. Liez cette zone au réseau virtuel approprié et rendez l'autorité privée joignable via le chemin de résolveur approuvé du VPN au lieu de supposer que la liaison suffit.
Un client point à site a généralement besoin d'un point de terminaison entrant de résolveur privé ou d'un redirecteur DNS pris en charge pour atteindre cette zone. Lier une zone change ce qu'Azure résout pour les réseaux liés ; cela ne redirige pas le résolveur public de chaque ordinateur portable externe. Ne la remplacez pas par une zone DNS de point de terminaison privé empruntée à un autre modèle de réseau Container Apps, car les noms d'enregistrement et le suffixe de zone ne correspondront pas.
Le retour arrière de cette étape consiste à supprimer la liaison de zone ou l'enregistrement que vous avez ajouté. Notez lequel des deux c'était, car supprimer une zone partagée pour annuler une seule liaison est un moyen bien connu de casser un second environnement.
Étape 4 : tester le nom, puis le public refusé
Testez le nom d'hôte et l'identité TLS ensemble, pas seulement l'adresse. Pour un diagnostic contrôlé de mappage de noms, vous pouvez épingler l'adresse tout en conservant le nom d'hôte :
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Remplacez le nom d'hôte par le vrai FQDN de l'application et l'adresse par la vraie entrée interne. Cela n'affecte que cette seule requête et ne constitue pas un provisionnement DNS. N'ajoutez pas -k pour transformer un échec d'identité en réussite apparente, car une inadéquation de certificat est le signal que vous frappez le mauvais écouteur.
Demander directement l'adresse numérique peut sélectionner le mauvais hôte virtuel ou faire échouer la validation alors même que TCP 443 répond, donc traitez un test d'IP réussi comme une preuve sur le réseau et rien de plus. Depuis l'ordinateur portable prévu, le chemin de résolveur normal est le redirecteur DNS du client ou le point de terminaison entrant du résolveur privé qui héberge la zone, et un échec à cet endroit est un problème d'accessibilité du résolveur, pas un enregistrement manquant. Confirmez que la même requête réussit sur ce chemin, puis confirmez que le public refusé l'est toujours.
Ce qu'il faut consigner et ce qu'il faut annuler
Le port cible du conteneur et le port HTTPS du client sont des réglages distincts. Ne publiez pas le port cible du conteneur à travers le VPN parce que le conteneur y écoute, et n'élargissez pas une règle réseau pour faire passer un test de port. Les deux changements survivent à l'incident et sont difficiles à attribuer ensuite.
Terminez par une nouvelle opération d'application depuis l'ordinateur portable prévu, avec son identité autorisée et son DNS normal, puis vérifiez qu'un appelant non autorisé échoue toujours. Pendant que vous êtes dans la configuration de l'application, vérifiez aussi si une route HTTP au niveau de l'environnement expose cette application comme cible, car cette route est une seconde porte que la portée d'entrée ne décrit pas.
Consignez cinq valeurs ensemble : portée de l'environnement, portée d'entrée de l'application, FQDN, adresse d'entrée privée et propriétaire du résolveur. Ces cinq valeurs décrivent tout le contrat d'accès, et la prochaine personne qui le déboguer a demandera exactement celles-ci.