Chegar a unha aplicación privada de Container Apps mediante VPN de punto a sitio
Unha contorna interna de Container Apps necesita unha entrada privada, un nome de host coincidente e un resolvedor que a VPN poida alcanzar. Execute cada paso e despois verifique a denegación.
Esta guía cobre unha contorna de Container Apps con perfís de carga de traballo e unha entrada de rede virtual interna, á que se chega desde un portátil mediante unha VPN de punto a sitio aprobada, usando o FQDN directo da aplicación e sen rutas HTTP a nivel de contorna. a entrada da contorna é accesible desde o cliente, o ámbito de entrada da aplicación admite o chamador e o nome de host resólvese na entrada privada. Cada paso seguinte deixa un resultado verificable e unha reversión que non toca nada que non cambiase. Realízeos na orde indicada, porque ningún paso posterior pode compensar unha decisión de ámbito tomada incorrectamente no paso 1.
Antes de tocar DNS, aclare a palabra interno. Emprégase para dous ámbitos distintos neste produto, e intercambialos é a causa máis común de que un nome que funciona siga sen devolver nada útil.
Paso 1: fixe o ámbito da contorna e da aplicación
Lea a configuración de entrada da aplicación antes de cambiar calquera rexistro:
| 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 exponse no balanceador de carga interno da contorna dentro da VNet da contorna, así que a pregunta non é se o portátil é outra aplicación de contedores, senón se pode alcanzar esa VNet. Un cliente VPN cunha ruta cara á VNet e o dominio predeterminado da contorna resólvese mediante a zona privada é un chamador admisible, e iso é o que constrúen os pasos restantes. Unha contorna interna sen entrada pública é un feito distinto dunha aplicación con entrada interna, e a entrada externa a nivel de aplicación non dá á contorna unha porta pública. Escriba o ámbito no ticket e tamén no portal, porque o seguinte enxeñeiro le primeiro o ticket.
Confirme ese ámbito co propietario da configuración antes de continuar, e manteña a porta estreita: se non existe ningunha ruta cara á VNet da contorna, ou o dominio predeterminado da contorna non se resolve mediante a zona privada, detéñase e arranxe primeiro esa ruta. Ningún paso posterior pode substituír un chamador que non pode alcanzar a VNet nin resolver o nome.
Paso 2: reúna o nome de host real e o enderezo de entrada
Anote o dominio predeterminado da contorna, o seu enderezo de entrada privado estático e o FQDN configurado da aplicación, tomados do recurso e non dunha captura de pantalla antiga ou dunha páxina 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"A guía de entrada privada de Container Apps describe como facer coincidir o dominio da contorna co seu enderezo interno mantendo intactos os nomes de host da aplicación. Esa é exactamente a forma que constrúe a man aquí, así que aliñe o contido da zona con ela en lugar de inventar un esquema de nomes.
Se o dominio que leu non coincide co FQDN que informa a aplicación, detéñase e reconcílieos agora. Construír unha zona co sufixo equivocado produce un nome de host que se resolve perfectamente e aínda así acaba no host virtual equivocado.
Paso 3: poña a zona privada na ruta do resolvedor da VPN
Cree ou reutilice a zona DNS privada admitida para o dominio predeterminado real da contorna, cos rexistros de comodín e de enderezo documentados apuntando á entrada estática. Vincule esa zona á rede virtual axeitada e faga a autoridade privada accesible a través da ruta de resolvedor aprobada da VPN en lugar de supoñer que a vinculación abonda.
Un cliente de punto a sitio normalmente necesita un punto de conexión entrante de resolvedor privado ou un reenviador DNS admitido para chegar a esa zona. Vincular unha zona cambia o que Azure resolve para as redes vinculadas; non redirixe o resolvedor público de cada portátil externo. Non a substitúa por unha zona DNS de punto de conexión privado tomada doutro modelo de rede de Container Apps, porque os nomes dos rexistros e o sufixo da zona non coincidirán.
A reversión deste paso é eliminar a vinculación da zona ou o rexistro que engadiu. Anote cal dos dous era, porque borrar unha zona compartida para desfacer unha soa vinculación é unha forma ben coñecida de romper unha segunda contorna.
Paso 4: probe o nome e despois o público denegado
Probe o nome de host e a identidade TLS xuntos, non só o enderezo. Para un diagnóstico controlado de asignación de nomes pode fixar o enderezo conservando o nome de host:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Substitúa o nome de host polo FQDN real da aplicación e o enderezo pola entrada interna real. Isto afecta só esa solicitude e non é aprovisionamento de DNS. Non engada -k para converter un fallo de identidade nun aprobado aparente, porque un desaxuste de certificado é o sinal de que está a alcanzar o oínte equivocado.
Solicitar o enderezo numérico directamente pode seleccionar o host virtual equivocado ou facer fallar a validación mesmo mentres TCP 443 responde, así que trate unha proba IP correcta como evidencia sobre a rede e nada máis. Desde o portátil previsto, a ruta normal do resolvedor é o reenviador DNS do cliente ou o punto de conexión entrante do resolvedor privado que aloxa a zona, e un fallo alí é un problema de accesibilidade do resolvedor, non un rexistro ausente. Confirme que a mesma solicitude ten éxito nesa ruta e despois confirme que o público denegado segue denegado.
Que rexistrar e que reverter
O porto de destino do contedor e o porto HTTPS do cliente son axustes separados. Non publique o porto de destino do contedor a través da VPN porque o contedor escoita alí, e non amplíe unha regra de rede para facer pasar unha proba de porto. Ambos os cambios sobreviven ao incidente e despois son difíciles de atribuír.
Remate cunha operación nova da aplicación desde o portátil previsto, coa súa identidade autorizada e o seu DNS normal, e despois comprobe que un chamador non autorizado segue fallando. Mentres estea na configuración da aplicación, confirme tamén se unha ruta HTTP a nivel de contorna expón esta aplicación como destino, porque esa ruta é unha segunda porta que o ámbito de entrada non describe.
Anote cinco valores xuntos: ámbito da contorna, ámbito de entrada da aplicación, FQDN, enderezo de entrada privado e propietario do resolvedor. Eses cinco describen todo o contrato de acceso, e a seguinte persoa que o depure pedirá exactamente eses.