Accediu a una aplicació privada de Container Apps mitjançant una VPN de punt a lloc
Un entorn intern de Container Apps necessita una entrada privada, un nom d'amfitrió coincident i un resolutor que la VPN pugui assolir. Executeu cada pas i després verifiqueu la denegació.
Aquest manual cobreix un entorn de Container Apps amb perfils de càrrega de treball i una entrada de xarxa virtual interna, a la qual s'arriba des d'un portàtil mitjançant una VPN de punt a lloc aprovada, utilitzant l'FQDN directe de l'aplicació i sense rutes HTTP a nivell d'entorn. l'entrada de l'entorn és accessible des del client, l'abast d'entrada de l'aplicació admet el sol·licitant i el nom d'amfitrió es resol a l'entrada privada. Cada pas següent deixa un resultat verificable i una reversió que no toca res que no hàgiu canviat. Feu-los en l'ordre indicat, perquè cap pas posterior no pot compensar una decisió d'abast presa malament al pas 1.
Abans de tocar el DNS, aclariu la paraula intern. En aquest producte s'utilitza per a dos abasts diferents, i intercanviar-los és la causa més habitual que un nom que funciona encara no retorni res d'útil.
Pas 1: fixeu l'abast de l'entorn i de l'aplicació
Llegiu la configuració d'entrada de l'aplicació abans de canviar cap registre:
| 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'entrada interna s'exposa al balancejador de càrrega intern de l'entorn dins de la VNet de l'entorn, així que la pregunta no és si el portàtil és una altra aplicació de contenidors, sinó si pot arribar a aquesta VNet. Un client VPN amb una ruta a la VNet i el domini predeterminat de l'entorn que es resol mitjançant la zona privada és un sol·licitant admissible, i això és el que construeixen els passos restants. Un entorn intern sense entrada pública és un fet diferent d'una aplicació amb entrada interna, i l'entrada externa a nivell d'aplicació no dona a l'entorn una porta pública. Escriviu l'abast al tiquet i també al portal, perquè el pròxim enginyer llegeix primer el tiquet.
Confirmeu aquest abast amb el propietari de la configuració abans de continuar, i manteniu la porta estreta: si no existeix cap ruta a la VNet de l'entorn, o el domini predeterminat de l'entorn no es resol mitjançant la zona privada, atureu-vos i arregleu primer aquest camí. Cap pas posterior no pot substituir un sol·licitant que no pot arribar a la VNet ni resoldre el nom.
Pas 2: recolliu el nom d'amfitrió real i l'adreça d'entrada
Anoteu el domini predeterminat de l'entorn, la seva adreça d'entrada privada estàtica i l'FQDN configurat de l'aplicació, presos del recurs i no d'una captura de pantalla antiga o d'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 guia d' entrada privada de Container Apps descriu com fer coincidir el domini de l'entorn amb la seva adreça interna mantenint intactes els noms d'amfitrió de l'aplicació. Aquesta és exactament la forma que construïu a mà aquí, així que alineeu el contingut de la zona amb ella en lloc d'inventar un esquema de noms.
Si el domini que heu llegit no coincideix amb l'FQDN que l'aplicació informa, atureu-vos i reconcilieu-los ara. Construir una zona amb el sufix equivocat produeix un nom d'amfitrió que es resol perfectament i encara acaba a l'amfitrió virtual equivocat.
Pas 3: poseu la zona privada al camí del resolutor de la VPN
Creeu o reutilitzeu la zona DNS privada admesa per al domini predeterminat real de l'entorn, amb els registres de comodí i d'adreça documentats apuntant a l'entrada estàtica. Enllaçeu aquesta zona a la xarxa virtual adequada i feu l'autoritat privada accessible pel camí de resolutor aprovat de la VPN en lloc de suposar que l'enllaç és suficient.
Un client de punt a lloc normalment necessita un punt final d'entrada de resolutor privat o un reenviador DNS admès per arribar a aquesta zona. Enllaçar una zona canvia què resol l'Azure per a les xarxes enllaçades; no redirigeix el resolutor públic de cada portàtil extern. No substituïu una zona DNS de punt final privat manllevada d'un altre model de xarxa de Container Apps, perquè els noms dels registres i el sufix de la zona no coincidiran.
La reversió d'aquest pas és eliminar l'enllaç de la zona o el registre que heu afegit. Anoteu quin dels dos era, perquè esborrar una zona compartida per desfer un sol enllaç és una manera ben coneguda de trencar un segon entorn.
Pas 4: proveu el nom i després el públic denegat
Proveu el nom d'amfitrió i la identitat TLS junts, no només l'adreça. Per a un diagnòstic controlat de mapatge de noms podeu fixar l'adreça tot conservant el nom d'amfitrió:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Substituïu el nom d'amfitrió per l'FQDN real de l'aplicació i l'adreça per l'entrada interna real. Això afecta només aquella sol·licitud i no és aprovisionament de DNS. No afegiu -k per convertir un error d'identitat en un aprovat aparent, perquè un desajust de certificat és el senyal que esteu tocant l'escoltador equivocat.
Sol·licitar l'adreça numèrica directament pot seleccionar l'amfitrió virtual equivocat o fer fallar la validació fins i tot mentre TCP 443 respon, així que tracteu una prova IP correcta com a evidència sobre la xarxa i res més. Des del portàtil previst, el camí normal del resolutor és el reenviador DNS del client o el punt final d'entrada del resolutor privat que allotja la zona, i un error allà és un problema d'abastabilitat del resolutor, no un registre absent. Confirmeu que la mateixa sol·licitud té èxit en aquest camí i després confirmeu que el públic denegat continua denegat.
Què cal registrar i què cal revertir
El port objectiu del contenidor i el port HTTPS del client són configuracions separades. No publiqueu el port objectiu del contenidor a través de la VPN perquè el contenidor hi escolta, i no amplieu cap regla de xarxa per fer passar una prova de port. Tots dos canvis sobreviuen a l'incident i després són difícils d'atribuir.
Acabeu amb una operació nova de l'aplicació des del portàtil previst, amb la seva identitat autoritzada i el seu DNS normal, i comproveu que un sol·licitant no autoritzat encara falla. Mentre sigueu a la configuració de l'aplicació, confirmeu també si una ruta HTTP a nivell d'entorn exposa aquesta aplicació com a objectiu, perquè aquesta ruta és una segona porta que l'abast d'entrada no descriu.
Anoteu cinc valors junts: abast de l'entorn, abast d'entrada de l'aplicació, FQDN, adreça d'entrada privada i propietari del resolutor. Aquests cinc descriuen tot el contracte d'accés, i la pròxima persona que l'hagi de depurar demanarà exactament aquests.