Raggiungere un'app Container Apps privata tramite VPN da punto a sito
Un ambiente Container Apps interno richiede un ingresso privato, un nome host corrispondente e un resolver che la VPN possa raggiungere. Eseguite ogni passaggio, poi verificate il rifiuto.
Questa guida copre un ambiente Container Apps con profili di carico di lavoro e un ingresso di rete virtuale interno, raggiungibile da un laptop tramite una VPN da punto a sito approvata, usando l'FQDN diretto dell'app e senza route HTTP a livello di ambiente. l'ingresso dell'ambiente è raggiungibile dal client, l'ambito di ingresso dell'app ammette il chiamante e il nome host viene risolto nell'ingresso privato. Ogni passaggio seguente lascia un risultato verificabile e un rollback che non tocca nulla che non abbiate modificato. Seguiteli nell'ordine indicato, perché nessun passaggio successivo può compensare una decisione di ambito presa male nel passaggio 1.
Prima di toccare il DNS, chiarite la parola interno. In questo prodotto è usata per due ambiti diversi, e scambiarli è la causa più comune per cui un nome funzionante continua a non restituire nulla di utile.
Passaggio 1: fissare l'ambito dell'ambiente e dell'app
Leggete la configurazione di ingresso dell'app prima di modificare qualsiasi record:
| 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'ingresso interno è esposto sul bilanciatore di carico interno dell'ambiente all'interno della VNet dell'ambiente, quindi la domanda non è se il laptop sia un'altra app container, ma se possa raggiungere quella VNet. Un client VPN con una route verso la VNet e il dominio predefinito dell'ambiente risolto tramite la zona privata è un chiamante idoneo, ed è esattamente ciò che costruiscono i passaggi restanti. Un ambiente interno senza ingresso pubblico è un fatto diverso da un'app con ingresso interno, e un ingresso esterno a livello di app non dà all'ambiente una porta pubblica. Scrivete l'ambito nel ticket e anche nel portale, perché il prossimo ingegnere legge prima il ticket.
Confermate quell'ambito con il proprietario della configurazione prima di continuare, e tenete il cancello stretto: se non esiste una route verso la VNet dell'ambiente, o il dominio predefinito dell'ambiente non viene risolto tramite la zona privata, fermatevi e correggete prima quel percorso. Nessun passaggio successivo può sostituire un chiamante che non riesce a raggiungere la VNet o a risolvere il nome.
Passaggio 2: raccogliere il nome host reale e l'indirizzo di ingresso
Annotate il dominio predefinito dell'ambiente, il relativo indirizzo di ingresso privato statico e l'FQDN configurato dell'app, presi dalla risorsa e non da uno screenshot vecchio o da una pagina 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 indicazioni per l' ingresso privato di Container Apps descrivono come far corrispondere il dominio dell'ambiente al suo indirizzo interno mantenendo intatti i nomi host dell'applicazione. È esattamente la forma che state costruendo a mano qui, quindi allineate il contenuto della zona a essa invece di inventare un nuovo schema di denominazione.
Se il dominio che avete letto non corrisponde all'FQDN riportato dall'app, fermatevi e riconciliateli ora. Costruire una zona sul suffisso sbagliato produce un nome host che si risolve perfettamente e finisce comunque sull'host virtuale sbagliato.
Passaggio 3: mettere la zona privata sul percorso del resolver della VPN
Create o riutilizzate la zona DNS privata supportata per il dominio predefinito effettivo dell'ambiente, con i record jolly e di indirizzo documentati che puntano all'ingresso statico. Collegate quella zona alla rete virtuale appropriata e rendete l'autorità privata raggiungibile tramite il percorso del resolver approvato della VPN invece di presumere che il collegamento basti.
Un client da punto a sito di solito necessita di un endpoint in ingresso del resolver privato o di un inoltro DNS supportato per raggiungere quella zona. Collegare una zona cambia ciò che Azure risolve per le reti collegate; non reindirizza il resolver pubblico di ogni laptop esterno. Non sostituitela con una zona DNS di endpoint privato presa in prestito da un altro modello di rete di Container Apps, perché i nomi dei record e il suffisso della zona non coincideranno.
Il rollback di questo passaggio consiste nel rimuovere il collegamento della zona o il record aggiunto. Annotate quale dei due era, perché eliminare una zona condivisa per annullare un singolo collegamento è un modo ben noto di rompere un secondo ambiente.
Passaggio 4: testare il nome, poi il pubblico negato
Testate il nome host e l'identità TLS insieme, non solo l'indirizzo. Per una diagnostica controllata della mappatura dei nomi potete fissare l'indirizzo mantenendo il nome host:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Sostituite il nome host con l'FQDN reale dell'app e l'indirizzo con l'ingresso interno reale. Questo influisce solo su quella singola richiesta e non è un provisioning DNS. Non aggiungete -k per trasformare un errore di identità in un superamento apparente, perché una mancata corrispondenza del certificato è il segnale che state colpendo l'ascoltatore sbagliato.
Richiedere direttamente l'indirizzo numerico può selezionare l'host virtuale sbagliato o far fallire la convalida anche mentre TCP 443 risponde, quindi trattate un test IP riuscito come prova sulla rete e nulla di più. Dal laptop previsto, il percorso normale del resolver è l'inoltro DNS del client o l'endpoint in ingresso del resolver privato che ospita la zona, e un errore lì è un problema di raggiungibilità del resolver, non un record mancante. Confermate che la stessa richiesta riesce su quel percorso, poi confermate che il pubblico negato è ancora negato.
Cosa registrare e cosa ripristinare
La porta di destinazione del container e la porta HTTPS del client sono impostazioni separate. Non pubblicate la porta di destinazione del container attraverso la VPN perché il container ascolta lì, e non ampliate una regola di rete per far passare un test di porta. Entrambe le modifiche sopravvivono all'incidente e sono difficili da attribuire in seguito.
Concludete con una nuova operazione dell'applicazione dal laptop previsto, con la sua identità autorizzata e il suo DNS normale, poi verificate che un chiamante non autorizzato fallisca ancora. Mentre siete nella configurazione dell'app, confermate anche se una route HTTP a livello di ambiente espone questa app come destinazione, perché quella route è una seconda porta che l'ambito di ingresso non descrive.
Annotate cinque valori insieme: ambito dell'ambiente, ambito di ingresso dell'app, FQDN, indirizzo di ingresso privato e proprietario del resolver. Quei cinque descrivono l'intero contratto di accesso, e la prossima persona che lo eseguirà il debug chiederà esattamente quelli.