Acceder a una aplicación privada de Container Apps mediante VPN de punto a sitio
Un entorno interno de Container Apps necesita una entrada privada, un nombre de host coincidente y un resolutor que la VPN pueda alcanzar. Ejecute cada paso y luego verifique la denegación.
Esta guía cubre un entorno de Container Apps con perfiles de carga de trabajo y una entrada de red virtual interna, a la que se llega desde un portátil mediante una VPN de punto a sitio aprobada, usando el FQDN directo de la aplicación y sin rutas HTTP a nivel de entorno. la entrada del entorno es accesible desde el cliente, el ámbito de entrada de la aplicación admite al llamador y el nombre de host se resuelve en la entrada privada. Cada paso siguiente deja un resultado verificable y una reversión que no toca nada que no haya cambiado. Realícelos en el orden indicado, porque ningún paso posterior puede compensar una decisión de ámbito tomada incorrectamente en el paso 1.
Antes de tocar DNS, aclare la palabra interno. Se usa para dos ámbitos distintos en este producto, e intercambiarlos es la causa más común de que un nombre que funciona siga sin devolver nada útil.
Paso 1: fije el ámbito del entorno y de la aplicación
Lea la configuración de entrada de la aplicación antes de cambiar cualquier registro:
| 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 |
La entrada interna se expone en el equilibrador de carga interno del entorno dentro de la VNet del entorno, así que la pregunta no es si el portátil es otra aplicación de contenedores, sino si puede alcanzar esa VNet. Un cliente VPN con una ruta hacia la VNet y el dominio predeterminado del entorno resuelto mediante la zona privada es un llamador admisible, y eso es lo que construyen los pasos restantes. Un entorno interno sin entrada pública es un hecho distinto de una aplicación con entrada interna, y la entrada externa a nivel de aplicación no da al entorno una puerta pública. Escriba el ámbito en el ticket y también en el portal, porque el siguiente ingeniero lee primero el ticket.
Confirme ese ámbito con el propietario de la configuración antes de continuar, y mantenga la puerta estrecha: si no existe ninguna ruta hacia la VNet del entorno, o el dominio predeterminado del entorno no se resuelve mediante la zona privada, deténgase y arregle primero esa ruta. Ningún paso posterior puede sustituir a un llamador que no puede alcanzar la VNet ni resolver el nombre.
Paso 2: reúna el nombre de host real y la dirección de entrada
Anote el dominio predeterminado del entorno, su dirección de entrada privada estática y el FQDN configurado de la aplicación, tomados del recurso y no de una captura de pantalla antigua o de una 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"La guía de entrada privada de Container Apps describe cómo hacer coincidir el dominio del entorno con su dirección interna manteniendo intactos los nombres de host de la aplicación. Esa es exactamente la forma que construye a mano aquí, así que alinee el contenido de la zona con ella en lugar de inventar un esquema de nombres.
Si el dominio que leyó no coincide con el FQDN que informa la aplicación, deténgase y reconcilíelos ahora. Construir una zona con el sufijo equivocado produce un nombre de host que se resuelve perfectamente y aun así acaba en el host virtual equivocado.
Paso 3: ponga la zona privada en la ruta del resolutor de la VPN
Cree o reutilice la zona DNS privada admitida para el dominio predeterminado real del entorno, con los registros de comodín y de dirección documentados apuntando a la entrada estática. Vincule esa zona a la red virtual adecuada y haga que la autoridad privada sea accesible a través de la ruta de resolutor aprobada de la VPN en lugar de suponer que el vínculo basta.
Un cliente de punto a sitio normalmente necesita un punto de conexión entrante de resolutor privado o un reenviador DNS admitido para llegar a esa zona. Vincular una zona cambia lo que Azure resuelve para las redes vinculadas; no redirige el resolutor público de cada portátil externo. No la sustituya por una zona DNS de punto de conexión privado tomada de otro modelo de red de Container Apps, porque los nombres de los registros y el sufijo de la zona no coincidirán.
La reversión de este paso es eliminar el vínculo de la zona o el registro que agregó. Anote cuál de los dos era, porque borrar una zona compartida para deshacer un solo vínculo es una forma bien conocida de romper un segundo entorno.
Paso 4: pruebe el nombre y luego el público denegado
Pruebe el nombre de host y la identidad TLS juntos, no solo la dirección. Para un diagnóstico controlado de asignación de nombres puede fijar la dirección conservando el nombre de host:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Sustituya el nombre de host por el FQDN real de la aplicación y la dirección por la entrada interna real. Esto afecta solo a esa solicitud y no es aprovisionamiento de DNS. No agregue -k para convertir un fallo de identidad en un aprobado aparente, porque un desajuste de certificado es la señal de que está alcanzando el escucha equivocado.
Solicitar la dirección numérica directamente puede seleccionar el host virtual equivocado o hacer fallar la validación incluso mientras TCP 443 responde, así que trate una prueba de IP correcta como evidencia sobre la red y nada más. Desde el portátil previsto, la ruta normal del resolutor es el reenviador DNS del cliente o el punto de conexión entrante del resolutor privado que aloja la zona, y un fallo allí es un problema de accesibilidad del resolutor, no un registro ausente. Confirme que la misma solicitud tiene éxito en esa ruta y luego confirme que el público denegado sigue denegado.
Qué registrar y qué revertir
El puerto de destino del contenedor y el puerto HTTPS del cliente son ajustes separados. No publique el puerto de destino del contenedor a través de la VPN porque el contenedor escucha allí, y no amplíe una regla de red para hacer pasar una prueba de puerto. Ambos cambios sobreviven al incidente y luego son difíciles de atribuir.
Termine con una operación nueva de la aplicación desde el portátil previsto, con su identidad autorizada y su DNS normal, y luego compruebe que un llamador no autorizado sigue fallando. Mientras esté en la configuración de la aplicación, confirme también si una ruta HTTP a nivel de entorno expone esta aplicación como destino, porque esa ruta es una segunda puerta que el ámbito de entrada no describe.
Anote cinco valores juntos: ámbito del entorno, ámbito de entrada de la aplicación, FQDN, dirección de entrada privada y propietario del resolutor. Esos cinco describen todo el contrato de acceso, y la siguiente persona que lo depure pedirá exactamente esos.