Considerazioni sulla rete per l'ambiente del servizio app

Un ambiente del servizio app è una distribuzione del Servizio app di Azure in una subnet nella rete virtuale di Azure dell'utente. 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.
• 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 bilanciamento del carico interno. Per altre informazioni, vedere Creare e usare un ambiente del servizio app con bilanciamento del carico interno.

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

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

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

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

Se si dispone di un ambiente del servizio app con una distribuzione con 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 l'ambiente del servizio app, non è possibile modificare le dimensioni della subnet usata per ospitarlo. L'ambiente del servizio app usa un indirizzo per ogni ruolo di infrastruttura e per ogni istanza del piano di servizio app Isolato. Inoltre, la rete di Azure usa cinque indirizzi per ogni subnet creata.

Un ambiente del servizio app senza alcun piano di servizio app userà 12 indirizzi prima che venga creata un'app. Se si usa la distribuzione con bilanciamento del carico interno, verranno usati 13 indirizzi prima di creare un'app. Con l'aumento, tenere presente che i ruoli dell'infrastruttura vengono aggiunti per ogni multiplo di 15 e 20 istanze del piano di servizio app.

In caso di aumento o riduzione, vengono aggiunti nuovi ruoli di dimensioni appropriate e viene quindi eseguita la migrazione dei carichi di lavoro dalle dimensioni correnti a quelle di destinazione. Le VM originarie vengono rimosse solo dopo la migrazione dei carichi di lavoro. Ad esempio, se si dispone di un ambiente del servizio app con 100 istanze del piano di servizio app, esiste un periodo di tempo in cui è necessario raddoppiare il numero di VM.

Dipendenze in ingresso e in uscita

Le sezioni seguenti illustrano le dipendenze da tenere presenti per l'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:

Le porte 7564 e 1221 possono essere visualizzate come aperte in un'analisi delle porte. Rispondono con un indirizzo IP e null'altro. È possibile bloccarle.

Il traffico di gestione in ingresso fornisce comandi e controllo dell'ambiente del servizio app, oltre al monitoraggio del sistema. Gli indirizzi di origine per il questo traffico sono elencati in Indirizzi di gestione dell'Ambiente del servizio app. La configurazione della sicurezza di rete deve consentire l'accesso dagli indirizzi di gestione dell'ambiente del servizio app sulle porte 454 e 455. Se si blocca l'accesso da questi indirizzi, l'ambiente del servizio app diventerà non integro e quindi verrà sospeso. Il traffico TCP proveniente sulle porte 454 e 455 deve essere ritrasmesso dallo stesso indirizzo VIP, altrimenti si verificherà un problema di routing asimmetrico.

All'interno della subnet, molte porte sono usate per la comunicazione dei componenti interni e possono cambiare. Ciò richiede che tutte le porte nella subnet siano accessibili dalla subnet.

Per la comunicazione tra Azure Load Balancer e la subnet dell'ambiente del servizio app, è necessario aprire almeno le porte 454, 455 e 16001. Se si usa una distribuzione con bilanciamento del carico interno, è possibile bloccare il traffico solo alle porte 454, 455, 16001. Se si usa una distribuzione esterna, è necessario prendere tenere conto delle normali porte di accesso delle app. In particolare, sono:

Se si bloccano le porte dell'applicazione, l'ambiente del servizio app può comunque funzionare, ma l'app potrebbe non funzionare. Se si usano indirizzi IP assegnati dalle app con una distribuzione esterna, è necessario consentire il traffico dagli IP assegnati alle app nella subnet. Dal portale dell'ambiente del servizio app, passare a Indirizzi IPe 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 corrispondono a un set fisso di indirizzi IP. Pertanto, l'ambiente del servizio app richiede l'accesso in uscita dalla subnet della subnet a tutti gli IP esterni su svariate porte.

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

Le dipendenze in uscita sono elencate in Blocco di un ambiente del servizio app. Se l'ambiente del servizio app perde l'accesso alle relative dipendenze, smette di funzionare. Quando ciò 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. L'ambiente del servizio app usa DNS di Azure per scopi di gestione. Se la rete virtuale è configurata con un server DNS selezionato dal cliente, il server DNS deve essere raggiungibile dalla subnet.

Per testare la risoluzione DNS dall’app Web, usare il comando della console nameresolver. Passare alla finestra di debug nel sito scm per l'app o passare all'app nel portale e selezionare la 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, eseguire una ricerca usando invece DNS di Azure.

Se si modifica l'impostazione DNS della rete virtuale in cui si trova l'ambiente del servizio app, sarà necessario il riavvio. Per evitare il riavvio, è consigliabile configurare le impostazioni DNS per la rete virtuale prima di creare l'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 funzionalità nel portale di Azure dipendono dall'accesso diretto al sito SCM (Source Control Manager). 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 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 al sito SCM direttamente anziché usare il portale.

Se il bilanciamento del carico interno è il nome di dominio contoso.appserviceenvironment.net e il nome dell'app è testapp, l'app viene raggiunta in testapp.contoso.appserviceenvironment.net. Il sito SCM abbinato viene raggiunto in 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 delle app in una distribuzione esterna e per il traffico di gestione nelle distribuzioni sia interne che esterne.
• IP pubblico in uscita: usato come IP di provenienza per le connessioni in uscita che lasciano la rete virtuale. Queste connessioni non vengono instradate verso un VPN.
• Indirizzo IP del 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 è configurato il binding TLS/SSL basato su IP.

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

Indirizzi IP assegnati alle app

Con una distribuzione esterna è possibile assegnare indirizzi IP alle singole app. Questa operazione non è possibile 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 con un binding TLS/SSL in Servizio app di Azure.

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

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, esiste una regola di rifiuto implicita con la priorità più bassa che nega tutto. Ciò che si crea sono le regole di consenso.

Non si ha accesso alle VM usate per ospitare l'ambiente del servizio app stesso. Si trovano in una sottoscrizione gestita da Microsoft. Se si desidera limitare l'accesso alle app, impostare NSG nella subnet. In questo caso, prestare particolare attenzione alle dipendenze. Se si bloccano eventuali dipendenze, l'ambiente del servizio app smette di funzionare.

È possibile configurare NSG 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 NSG sono quelle per consentire il traffico:

In entrata

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

In uscita

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

Queste porte non includono le porte necessarie per l'uso corretto delle app. Ad esempio, si supponga 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 del 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:

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

Se si colloca una regola per negare tutto prima delle regole predefinite, si impedisce il traffico tra il VIP e l'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 Qualsiasi e un intervallo di porte di *. Siccome la regola NSG viene applicata alla subnet, non è necessario impostare una destinazione specifica.

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 NSG, assegnarli alla subnet. Se non si ricorda la rete virtuale o la subnet, è possibile visualizzarla dal portale dell'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 avviene quando si impostano le route nella rete virtuale in modo che il traffico in uscita non passi direttamente a Internet. Il traffico passa in un altro punto, ad esempio un gateway di Azure ExpressRoute o un'appliance virtuale. Se è necessario configurare l'ambiente del servizio app in questo modo, vedere Configurazione dell'ambiente del servizio app con 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 al portale di Azure e selezionare Rete>Tabelle di route.

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

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

4. Impostare Tipo hop successivo su Internet e 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 servizio consentono di limitare l'accesso ai servizi multi-tenant a un set di reti e subnet virtuali di Azure. Per altre informazioni, vedere Endpoint del servizio di rete virtuale.

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

Quando gli endpoint servizio sono abilitati in una subnet con un'istanza di Azure SQL, tutte le istanze di Azure SQL connesse da/verso tale subnet devono avere gli endpoint 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 del 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 di Archiviazione di Azure, anche se non hanno endpoint del servizio abilitati.