Considerazioni sulla rete per l'ambiente del servizio app

Importante

Questo articolo riguarda ambiente del servizio app v2, usato con i piani di servizio app isolato. ambiente del servizio app v2 verrà ritirato il 31 agosto 2024. È disponibile una nuova versione di ambiente del servizio app che è più facile da usare e che viene eseguita su un'infrastruttura più potente. Per altre informazioni sulla nuova versione, iniziare con l'introduzione alla ambiente del servizio app. Se si usa attualmente ambiente del servizio app v2, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 29 gennaio 2024, non è più possibile creare nuove risorse ambiente del servizio app v2 usando uno dei metodi disponibili, inclusi i modelli ARM/Bicep, il portale di Azure, l'interfaccia della riga di comando di Azure o l'API REST. È necessario eseguire la migrazione a ambiente del servizio app v3 prima del 31 agosto 2024 per evitare l'eliminazione delle risorse e la perdita di dati.

ambiente del servizio app è una distribuzione del servizio app Azure in una subnet nella rete virtuale di Azure. Esistono due tipi di distribuzione per un ambiente del servizio app:

• Esterno: questo tipo di distribuzione espone le app ospitate usando un indirizzo IP accessibile su Internet. Per altre informazioni, vedere Creare un ambiente del servizio app esterno.
• Servizio di bilanciamento del carico interno: questo tipo di distribuzione espone le app ospitate in un indirizzo IP all'interno della rete virtuale. L'endpoint interno è un servizio di bilanciamento del carico interno. Per altre informazioni, vedere Creare e usare un servizio di bilanciamento del carico interno ambiente del servizio app.

Nota

Questo articolo riguarda ambiente del servizio app v2, che viene usato con piani di servizio app isolati.

Indipendentemente dal tipo di distribuzione, tutti i ambiente del servizio app hanno un indirizzo IP virtuale pubblico (VIP). Questo indirizzo VIP viene usato per il traffico di gestione in ingresso e come indirizzo quando si effettuano chiamate dal ambiente del servizio app a Internet. Tali chiamate lasciano la rete virtuale tramite l'indirizzo VIP assegnato per il ambiente del servizio app.

Se le app effettuano chiamate alle risorse nella rete virtuale o in una VPN, l'INDIRIZZO IP di origine è uno degli indirizzi IP nella subnet. Poiché il ambiente del servizio app si trova all'interno della rete virtuale, può anche accedere alle risorse all'interno della rete virtuale senza alcuna configurazione aggiuntiva. Se la rete virtuale è connessa alla rete locale, anche le app hanno accesso alle risorse senza configurazione aggiuntiva.

 

Se si dispone di un ambiente del servizio app con una distribuzione esterna, l'indirizzo VIP pubblico è anche l'endpoint a cui le app vengono risolte per quanto segue:

• HTTP/S
• FTP/S
• Distribuzione Web
• Debug remoto

Se si dispone di un ambiente del servizio app con una distribuzione del servizio di bilanciamento del carico interno, l'indirizzo dell'indirizzo interno è l'endpoint per HTTP/S, FTP/S, distribuzione Web e debug remoto.

Dimensioni della subnet

Dopo aver distribuito il ambiente del servizio app, non è possibile modificare le dimensioni della subnet usata per ospitarla. ambiente del servizio app usa un indirizzo per ogni ruolo dell'infrastruttura, nonché per ogni istanza del piano servizio app isolata. Inoltre, la rete di Azure usa cinque indirizzi per ogni subnet creata.

Un ambiente del servizio app senza piani di servizio app userà 12 indirizzi prima di creare un'app. Se si usa la distribuzione del servizio di bilanciamento del carico interno, verranno usati 13 indirizzi prima di creare un'app. Quando si aumenta il numero di istanze, tenere presente che i ruoli dell'infrastruttura vengono aggiunti a ogni multiplo di 15 e 20 istanze del piano servizio app.

Importante

Nient'altro può trovarsi nella subnet, ma il ambiente del servizio app. Assicurarsi di scegliere uno spazio di indirizzi che consente la crescita futura. Non è possibile modificare questa impostazione in un secondo momento. È consigliabile una dimensione pari a /24 con 256 indirizzi.

Quando si aumenta o si riduce, vengono aggiunti nuovi ruoli delle dimensioni appropriate e quindi i carichi di lavoro vengono migrati dalle dimensioni correnti alle dimensioni di destinazione. Le macchine virtuali originali vengono rimosse solo dopo la migrazione dei carichi di lavoro. Ad esempio, se si dispone di un ambiente del servizio app con 100 istanze di piano servizio app, è necessario un periodo di tempo in cui è necessario raddoppiare il numero di macchine virtuali.

Dipendenze in ingresso e in uscita

Le sezioni seguenti illustrano le dipendenze da tenere presenti per il ambiente del servizio app. Un'altra sezione illustra le impostazioni DNS.

Dipendenze in ingresso

Le porte seguenti devono essere aperte solo per consentire all'ambiente del servizio app di funzionare:

Utilizzo	Da	A
Gestione	Indirizzi di gestione del servizio app	subnet ambiente del servizio app: 454, 455
ambiente del servizio app comunicazione interna	subnet ambiente del servizio app: tutte le porte	subnet ambiente del servizio app: tutte le porte
Consenti bilanciamento del carico di Azure in ingresso	Azure Load Balancer	subnet ambiente del servizio app: 16001

Le porte 7564 e 1221 possono essere visualizzate come aperte in un'analisi delle porte. Rispondono con un indirizzo IP e niente di più. Puoi bloccarli se vuoi.

Il traffico di gestione in ingresso fornisce il comando e il controllo delle ambiente del servizio app, oltre al monitoraggio del sistema. Gli indirizzi di origine per questo traffico sono elencati negli indirizzi di gestione ambiente del servizio app. La configurazione di sicurezza di rete deve consentire l'accesso dagli indirizzi di gestione ambiente del servizio app sulle porte 454 e 455. Se si blocca l'accesso da tali indirizzi, il ambiente del servizio app diventerà non integro e quindi verrà sospeso. Il traffico TCP proveniente dalle porte 454 e 455 deve uscire dallo stesso indirizzo VIP oppure si avrà un problema di routing asimmetrico.

All'interno della subnet sono disponibili molte porte usate per la comunicazione interna dei componenti e possono cambiare. Questa operazione richiede che tutte le porte nella subnet siano accessibili dalla subnet.

Per la comunicazione tra il servizio di bilanciamento del carico di Azure e la subnet ambiente del servizio app, le porte minime che devono essere aperte sono 454, 455 e 16001. Se si usa una distribuzione del servizio di bilanciamento del carico interno, è possibile bloccare il traffico solo alle porte 454, 455, 16001. Se si usa una distribuzione esterna, è necessario prendere in considerazione le normali porte di accesso alle app. In particolare, si tratta di:

Utilizzo	Porti
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Debug remoto in Visual Studio	4020, 4022, 4024
Servizio distribuzione Web	8172

Se si bloccano le porte dell'applicazione, il ambiente del servizio app può comunque funzionare, ma l'app potrebbe non funzionare. Se si usano indirizzi IP assegnati dall'app con una distribuzione esterna, è necessario consentire il traffico dagli indirizzi IP assegnati alle app alla subnet. Dal portale di ambiente del servizio app passare agli indirizzi IP e visualizzare le porte da cui è necessario consentire il traffico.

Dipendenze in uscita

Per l'accesso in uscita, un ambiente del servizio app dipende da più sistemi esterni. Molte di queste dipendenze di sistema sono definite con nomi DNS e non eseguono il mapping a un set fisso di indirizzi IP. Di conseguenza, l'ambiente del servizio app richiede l'accesso in uscita dalla subnet a tutti gli INDIRIZZI IP esterni, in un'ampia gamma di porte.

ambiente del servizio app comunica con indirizzi accessibili da Internet sulle porte seguenti:

Usi	Porte
DNS	53
NTP	123
CRL, aggiornamenti di Windows, dipendenze linux, servizi di Azure	80/443
Azure SQL	1433
Monitoraggio	12000

Le dipendenze in uscita sono elencate in Blocco di un ambiente del servizio app. Se il ambiente del servizio app perde l'accesso alle relative dipendenze, smette di funzionare. Quando questo accade per un lungo periodo di tempo, viene sospeso.

DNS del cliente

Se la rete virtuale è configurata con un server DNS definito dal cliente, i carichi di lavoro del tenant lo usano. Il ambiente del servizio app usa DNS di Azure a scopo di gestione. Se la rete virtuale è configurata con un server DNS selezionato dal cliente, il server DNS deve essere raggiungibile dalla subnet.

Nota

Archiviazione i montaggi o i pull di immagini del contenitore in ambiente del servizio app v2 non sono in grado di usare il DNS definito dal cliente nella rete virtuale o tramite l'impostazione dell'appWEBSITE_DNS_SERVER.

Per testare la risoluzione DNS dall'app Web, è possibile usare il comando nameresolverdella console . Passare alla finestra di debug nel scm sito per l'app oppure passare all'app nel portale e selezionare console. Dal prompt della shell è possibile eseguire il comando nameresolver, insieme al nome DNS da cercare. Il risultato ottenuto è lo stesso di quello ottenuto dall'app dopo l'esecuzione della stessa ricerca. Se si usa nslookup, si esegue invece una ricerca usando DNS di Azure.

Se si modifica l'impostazione DNS della rete virtuale in cui si trova il ambiente del servizio app, sarà necessario riavviare. Per evitare il riavvio, è consigliabile configurare le impostazioni DNS per la rete virtuale prima di creare il ambiente del servizio app.

Dipendenze per il portale

Oltre alle dipendenze descritte nelle sezioni precedenti, è necessario tenere presenti alcune considerazioni aggiuntive relative all'esperienza del portale. Alcune delle funzionalità del portale di Azure dipendono dall'accesso diretto al sito di gestione del controllo del codice sorgente. Per ogni app nel Servizio app di Azure esistono due URL. Il primo URL consente l'accesso all'app. Il secondo URL consente l'accesso al sito di Gestione controllo servizi, chiamato anche console di Kudu. Le funzionalità che usano il sito di Gestione controllo servizi includono:

• Processi Web
• Funzioni
• Streaming dei log
• Kudu
• Estensioni
• Esplora processi
• Console

Quando si usa un servizio di bilanciamento del carico interno, il sito SCM non è accessibile dall'esterno della rete virtuale. Alcune funzionalità non funzionano dal portale delle app perché richiedono l'accesso al sito SCM di un'app. È possibile connettersi direttamente al sito SCM anziché usare il portale.

Se il servizio di bilanciamento del carico interno è il nome contoso.appserviceenvironment.netdi dominio e il nome dell'app è testapp, l'app viene raggiunta all'indirizzo testapp.contoso.appserviceenvironment.net. Il sito SCM con cui viene eseguito viene raggiunto all'indirizzo testapp.scm.contoso.appserviceenvironment.net.

Indirizzi IP

Un ambiente del servizio app ha alcuni indirizzi IP di cui tenere conto. Sono:

• Indirizzo IP in ingresso pubblico: usato per il traffico dell'app in una distribuzione esterna e il traffico di gestione sia nelle distribuzioni interne che esterne.
• IP pubblico in uscita: usato come IP "da" per le connessioni in uscita che lasciano la rete virtuale. Queste connessioni non vengono instradate verso un VPN.
• Indirizzo IP del servizio di bilanciamento del carico interno: questo indirizzo esiste solo in una distribuzione interna.
• Indirizzi TLS/SSL basati su IP assegnati dall'app: questi indirizzi sono possibili solo con una distribuzione esterna e quando è configurata l'associazione TLS/SSL basata su IP.

Tutti questi indirizzi IP sono visibili nella portale di Azure dall'interfaccia utente di ambiente del servizio app. Se si dispone di una distribuzione interna, viene elencato l'indirizzo IP per il servizio di bilanciamento del carico interno.

Nota

Questi indirizzi IP non cambiano, purché il ambiente del servizio app sia in esecuzione. Se il ambiente del servizio app viene sospeso e viene ripristinato, gli indirizzi usati cambieranno. La causa normale di una sospensione è se si blocca l'accesso alla gestione in ingresso o si blocca l'accesso a una dipendenza.

Indirizzi IP assegnati alle app

Con una distribuzione esterna, è possibile assegnare indirizzi IP a singole app. Non è possibile farlo con una distribuzione interna. Per altre informazioni su come configurare l'app in modo che abbia un proprio indirizzo IP, vedere Proteggere un nome DNS personalizzato con un'associazione TLS/SSL nel servizio app Azure.

Quando un'app ha un proprio indirizzo SSL basato su IP, l'ambiente del servizio app riserva due porte per eseguire il mapping a tale indirizzo IP. Una porta è destinata al traffico HTTP e l'altra al traffico HTTPS. Tali porte sono elencate nella sezione Indirizzi IP del portale di ambiente del servizio app. Il traffico deve essere in grado di raggiungere tali porte dall'indirizzo VIP. In caso contrario, le app non sono accessibili. Questo requisito è importante da ricordare quando si configurano i gruppi di sicurezza di rete.

Gruppi di sicurezza di rete

I gruppi di sicurezza di rete consentono di controllare l'accesso alla rete all'interno di una rete virtuale. Quando si usa il portale, è presente una regola di negazione implicita con la priorità più bassa per negare tutto. Le regole consentite vengono compilate.

Non si ha accesso alle macchine virtuali usate per ospitare il ambiente del servizio app stesso. Si trovano in una sottoscrizione gestita da Microsoft. Se si vuole limitare l'accesso alle app, impostare gruppi di sicurezza di rete nella subnet. In questo modo, prestare attenzione alle dipendenze. Se si bloccano dipendenze, il ambiente del servizio app smette di funzionare.

È possibile configurare i gruppi di sicurezza di rete tramite il portale di Azure o tramite PowerShell. Le informazioni riportate di seguito si riferiscono al portale di Azure. I gruppi di sicurezza di rete vengono creati e gestiti nel portale come risorsa di primo livello in Rete.

Le voci necessarie in un gruppo di sicurezza di rete consentono il traffico:

In entrata

• TCP dal tag AppServiceManagement del servizio IP sulle porte 454, 455
• TCP dal servizio di bilanciamento del carico sulla porta 16001
• Dalla subnet ambiente del servizio app alla subnet ambiente del servizio app su tutte le porte

In uscita

• UDP a tutti gli INDIRIZZI IP sulla porta 53
• UDP a tutti gli INDIRIZZI IP sulla porta 123
• TCP a tutti gli INDIRIZZI IP sulle porte 80, 443
• TCP al tag Sql del servizio IP sulla porta 1433
• TCP a tutti gli INDIRIZZI IP sulla porta 12000
• Nella subnet ambiente del servizio app su tutte le porte

Queste porte non includono le porte necessarie per l'uso corretto delle app. Si supponga, ad esempio, che l'app debba chiamare un server MySQL sulla porta 3306. Il protocollo NTP (Network Time Protocol) sulla porta 123 è il protocollo di sincronizzazione dell'ora usato dal sistema operativo. Gli endpoint NTP non sono specifici di servizio app, possono variare con il sistema operativo e non si trovano in un elenco ben definito di indirizzi. Per evitare problemi di sincronizzazione dell'ora, è quindi necessario consentire il traffico UDP a tutti gli indirizzi sulla porta 123. Il traffico TCP in uscita verso la porta 12000 è per il supporto e l'analisi del sistema. Gli endpoint sono dinamici e non si trovano in un set ben definito di indirizzi.

Le porte di accesso alle app normali sono:

Utilizzo	Porti
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Debug remoto in Visual Studio	4020, 4022, 4024
Servizio Distribuzione Web	8172

Una regola predefinita consente agli indirizzi IP nella rete virtuale di comunicare con la subnet. Un'altra regola predefinita consente al servizio di bilanciamento del carico, noto anche come indirizzo VIP pubblico, di comunicare con il ambiente del servizio app. Per visualizzare le regole predefinite, selezionare Regole predefinite (accanto all'icona Aggiungi).

Se si inserisce una regola nega tutto il resto prima delle regole predefinite, si impedisce il traffico tra l'indirizzo VIP e il ambiente del servizio app. Per impedire il traffico proveniente dall'interno della rete virtuale, aggiungere una regola personalizzata per consentire l'ingresso. Usare un'origine uguale a AzureLoadBalancer, con una destinazione Qualsiasie un intervallo di porte di *. Poiché la regola del gruppo di sicurezza di rete viene applicata alla subnet, non è necessario essere specifici nella destinazione.

Se è stato assegnato un indirizzo IP all'app, accertarsi di mantenere le porte aperte. Per visualizzare le porte selezionare Ambiente del servizio app>Indirizzi IP.  

Dopo aver definito i gruppi di sicurezza di rete, assegnarli alla subnet. Se non si ricorda la rete virtuale o la subnet, è possibile visualizzarla dal portale di ambiente del servizio app. Per assegnare il gruppo di sicurezza di rete alla subnet, passare all'interfaccia utente della subnet e selezionare il gruppo di sicurezza di rete.

Route

Il tunneling forzato è quando si impostano le route nella rete virtuale in modo che il traffico in uscita non vada direttamente a Internet. Il traffico passa in un altro punto, ad esempio un gateway Di Azure ExpressRoute o un'appliance virtuale. Se è necessario configurare il ambiente del servizio app in questo modo, vedere Configuring your ambiente del servizio app with forced tunneling (Configurazione del ambiente del servizio app con il tunneling forzato).

Quando si crea un ambiente del servizio app nel portale, si crea automaticamente un set di tabelle di route nella subnet. Tali route indicano semplicemente di inviare il traffico in uscita direttamente a Internet.

Per creare le stesse route manualmente, seguire questa procedura:

1. Passare alla portale di Azure e selezionare Rete>tabelle di route.

2. Creare una nuova tabella di route nella stessa area della rete virtuale.

3. Dall'interfaccia utente per le tabelle route selezionare Route>Aggiungi.

4. Impostare il tipo hop successivo su Internet e il prefisso Indirizzo su 0.0.0.0/0. Seleziona Salva.

   Verrà visualizzata una schermata simile alla seguente:

   

5. Dopo aver creato la nuova tabella di route, passare alla subnet. Selezionare la tabella di route nell'elenco del portale. Dopo aver salvato la modifica, dovrebbero essere visibili i gruppi di sicurezza di rete e le route associati alla subnet.

   

Endpoint di servizio

Gli endpoint di servizio consentono di limitare l'accesso ai servizi multi-tenant a un set di reti virtuali e subnet di Azure. Per altre informazioni, vedere Rete virtuale endpoint di servizio.

Quando si abilitano gli endpoint di servizio in una risorsa, vengono create route con priorità più alta rispetto a tutte le altre route. Se si usano endpoint di servizio in qualsiasi servizio di Azure, con un ambiente del servizio app con tunnel forzato, il traffico verso tali servizi non viene sottoposto a tunneling forzato.

Quando gli endpoint di servizio sono abilitati in una subnet con un'istanza di SQL di Azure, tutte le istanze SQL di Azure connesse a da tale subnet devono avere endpoint di servizio abilitati. Se si vuole accedere a più istanze di Azure SQL dalla stessa subnet, non è possibile abilitare gli endpoint servizio in un'istanza di Azure SQL e non in un'altra. Nessun altro servizio di Azure si comporta come Azure SQL rispetto agli endpoint di servizio. Quando si abilitano gli endpoint di servizio con Archiviazione di Azure, si blocca l'accesso a tale risorsa dalla subnet. È comunque possibile accedere ad altri account Archiviazione di Azure, anche se non hanno endpoint di servizio abilitati.