Configurazione dell'infrastruttura del gateway applicazione
L'infrastruttura del gateway applicazione di Azure include la rete virtuale, le subnet, i gruppi di sicurezza di rete e le route definite dall'utente.
Rete virtuale e subnet dedicata
Un gateway applicazione è una distribuzione dedicata nella rete virtuale. All'interno della rete virtuale è necessaria una subnet dedicata per il gateway applicazione. È possibile avere più istanze di una distribuzione specifica del gateway applicazione in una subnet. È anche possibile distribuire altri gateway applicazione nella subnet. Tuttavia, non è possibile distribuire altre risorse nella subnet del gateway applicazione. Non è possibile combinare SKU del gateway applicazione v1 e v2 nella stessa subnet.
Nota
I criteri degli endpoint servizio di rete virtuale non sono attualmente supportati in una subnet del gateway applicazione.
Dimensioni della subnet
Il gateway applicazione usa un indirizzo IP privato per ogni istanza, oltre a un altro indirizzo IP privato se è configurato un indirizzo IP front-end privato.
Azure riserva anche cinque indirizzi IP in ogni subnet per l'uso interno. Sono i primi quattro indirizzi e gli ultimi indirizzi IP. Si considerino, ad esempio, 15 istanze del gateway applicazione senza IP front-end privato. Per questa subnet sono necessari almeno 20 indirizzi IP. Ne sono necessari 5 per l'uso interno e 15 per le istanze del gateway applicazione.
Si consideri una subnet con 27 istanze del gateway applicazione e un indirizzo IP per un indirizzo IP front-end privato. In questo caso, sono necessari 33 indirizzi IP. Ne sono necessari 27 per le istanze del gateway applicazione, una per il front-end privato e 5 per l'uso interno.
Il gateway applicazione (SKU Standard o WAF) può supportare fino a 32 istanze (32 indirizzi IP dell'istanza + 1 configurazione IP front-end privato + 5 riservate di Azure). È consigliabile usare una dimensione minima della subnet pari a /26.
Gateway applicazione (Standard_v2 o WAF_v2 SKU) può supportare fino a 125 istanze (125 indirizzi IP di istanza + 1 configurazione IP front-end privato + 5 riservati ad Azure). È consigliabile usare una dimensione minima della subnet pari a /24.
Per determinare la capacità disponibile di una subnet con i gateway applicazione esistenti di cui è stato effettuato il provisioning, prendere le dimensioni della subnet e sottrarre i cinque indirizzi IP riservati della subnet riservata dalla piattaforma. Prendere quindi ogni gateway e sottrarre il numero massimo di istanze. Per ogni gateway con una configurazione IP front-end privata, sottrarre un altro indirizzo IP per ogni gateway.
Ecco ad esempio come calcolare l'indirizzamento disponibile per una subnet con tre gateway di dimensioni variabili:
- Gateway 1: massimo 10 istanze. Usare una configurazione IP front-end privato.
- Gateway 2: massimo 2 istanze. Nessuna configurazione IP front-end privato.
- Gateway 3: massimo 15 istanze. Usare una configurazione IP front-end privato.
- Dimensioni subnet: /24
- Dimensioni subnet /24 = 256 indirizzi IP - 5 riservati dalla piattaforma = 251 indirizzi disponibili
- 251: Gateway 1 (10) - 1 configurazione IP front-end privato = 240
- 240: Gateway 2 (2) = 238
- 238: Gateway 3 (15) - 1 configurazione IP front-end privato = 222
Importante
Anche se una subnet /24 non è necessaria per la distribuzione dello SKU v2 del gateway applicazione, è altamente consigliabile. Una subnet /24 garantisce che il gateway applicazione v2 disponga di spazio sufficiente per l'espansione automatica e gli aggiornamenti di manutenzione.
È necessario assicurarsi che la subnet del gateway applicazione v2 disponga di spazio indirizzi sufficiente per supportare il numero di istanze necessarie per gestire il traffico massimo previsto. Se si specifica il numero massimo di istanze, la subnet deve avere capacità per almeno tale numero di indirizzi. Per la pianificazione della capacità intorno al numero di istanze, vedere Dettagli sul numero di istanze.
La subnet denominata GatewaySubnet è riservata ai gateway VPN. Le risorse del gateway applicazione v1 che usano la subnet GatewaySubnet devono essere spostate in una subnet diversa o migrate allo SKU v2 prima del 30 settembre 2023 per evitare errori del piano di controllo e incoerenze della piattaforma. Per informazioni sulla modifica della subnet di un'istanza del gateway applicazione esistente, vedere Domande frequenti sul gateway applicazione.
Suggerimento
Gli indirizzi IP vengono allocati dall'inizio dello spazio subnet definito per le istanze del gateway. Man mano che le istanze vengono create e rimosse a causa della creazione di gateway o eventi di ridimensionamento, può diventare difficile comprendere qual è l'indirizzo disponibile successivo nella subnet. Per poter determinare l'indirizzo successivo da usare per un gateway futuro e avere un tema di indirizzamento contiguo per gli indirizzi IP front-end, valutare la possibilità di assegnare indirizzi IP front-end dalla metà superiore dello spazio del subset definito.
Ad esempio, se lo spazio indirizzi della subnet è 10.5.5.0/24, Prendere in considerazione l'impostazione della configurazione IP front-end privata dei gateway a partire dalla versione 10.5.5.254 e successivamente con 10.5.5.253, 10.5.5.252, 10.5.5.251 e così via per i gateway futuri.
È possibile modificare la subnet di un'istanza del gateway applicazione esistente all'interno della stessa rete virtuale. Per apportare questa modifica, usare Azure PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Domande frequenti sul gateway applicazione.
Server DNS per la risoluzione dei nomi
La risorsa di rete virtuale supporta la configurazione del server DNS, che consente di scegliere tra server DNS predefiniti o personalizzati forniti da Azure. Le istanze del gateway applicazione rispettano anche questa configurazione DNS per qualsiasi risoluzione dei nomi. Dopo aver modificato questa impostazione, è necessario riavviare (Arrestare e avviare) il gateway applicazione per rendere effettive queste modifiche sulle istanze.
Quando un'istanza del gateway applicazione genera una query DNS, usa prima il valore del server che risponde.
Nota
Se si usano server DNS personalizzati nella rete virtuale del gateway applicazione, il server DNS deve essere in grado di risolvere i nomi Internet pubblici. Il gateway applicazione richiede questa funzionalità.
Autorizzazione della rete virtuale
La risorsa gateway applicazione viene distribuita all'interno di una rete virtuale, quindi vengono eseguiti controlli anche per verificare l'autorizzazione per la risorsa di rete virtuale. Questa convalida viene eseguita sia durante le operazioni di creazione che di gestione e si applica anche alle identità gestite per gateway applicazione Controller di ingresso.
Controllare il controllo degli accessi in base al ruolo di Azure per verificare che gli utenti e le entità servizio che gestiscono i gateway applicazione dispongano almeno delle autorizzazioni seguenti per la rete virtuale o la subnet:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
È possibile usare i ruoli predefiniti, ad esempio Collaboratore rete, che supportano già queste autorizzazioni. Se un ruolo predefinito non fornisce l'autorizzazione corretta, è possibile creare e assegnare un ruolo personalizzato. Altre informazioni sulla gestione delle autorizzazioni della subnet.
Nota
Potrebbe essere necessario consentire tempo sufficiente per l'aggiornamento della cache di Azure Resource Manager dopo la modifica dell'assegnazione di ruolo.
Identificare gli utenti o entità servizio interessate per la sottoscrizione
Visitando Azure Advisor per l'account, è possibile verificare se la sottoscrizione dispone di utenti o entità servizio con autorizzazioni insufficienti. I dettagli di tale raccomandazione sono i seguenti:
Titolo: Aggiornare l'autorizzazione della rete virtuale degli utenti del gateway applicazione
Categoria: Affidabilità
Impatto: Alto
Usare il flag Controllo esposizione funzionalità di Azure (AFEC) temporaneo
Come estensione temporanea, è stato introdotto un controllo a livello di esposizione delle funzionalità di Azure (AFEC) a livello di sottoscrizione. È possibile registrarsi per aFEC e usarlo fino a quando non si correggono le autorizzazioni per tutti gli utenti e le entità servizio. Eseguire la registrazione per la funzionalità seguendo la stessa procedura di registrazione alle funzionalità di anteprima per la sottoscrizione di Azure.
Nome: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Descrizione: Disabilitare il controllo delle autorizzazioni della sottorete del gateway applicativo
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Nota
È consigliabile usare il provisioning AFEC solo come mitigazione provvisoria fino a quando non si assegna l'autorizzazione corretta. È necessario assegnare la priorità alla correzione delle autorizzazioni per tutti gli utenti applicabili (e le entità servizio) e quindi annullare la registrazione del flag AFEC per reintrodurre la verifica delle autorizzazioni nella risorsa di rete virtuale. È consigliabile non dipendere definitivamente da questo metodo AFEC perché verrà rimosso in futuro.
Gestione rete virtuale di Azure
Gestione rete virtuale di Azure è un servizio di gestione che consente di raggruppare, configurare, distribuire e gestire reti virtuali a livello globale tra sottoscrizioni. Con Virtual Network Manager è possibile definire gruppi di rete per identificare e segmentare logicamente le reti virtuali. Successivamente, è possibile determinare le configurazioni di connettività e sicurezza desiderate e applicarle in tutte le reti virtuali selezionate nei gruppi di rete contemporaneamente.
La configurazione delle regole di amministrazione della sicurezza in Gestione rete virtuale di Azure consente di definire criteri di sicurezza su larga scala e applicarli a più reti virtuali contemporaneamente.
Nota
Le regole di amministrazione della sicurezza di Azure Rete virtuale Manager si applicano solo alle subnet gateway applicazione che contengono gateway applicazione con isolamento di rete abilitato. Le subnet con gateway applicazione con isolamento di rete disabilitato non hanno regole di amministratore della sicurezza.
Gruppi di sicurezza di rete
È possibile usare gruppi di sicurezza di rete per la subnet del gateway applicazione, ma tenere presente alcuni punti chiave e restrizioni.
Importante
Queste limitazioni del gruppo di sicurezza di rete sono limitate quando si usa la distribuzione del gateway applicazione privato (anteprima).
Regole di sicurezza necessarie
Per usare un gruppo di sicurezza di rete con il gateway applicazione, è necessario creare o conservare alcune regole di sicurezza essenziali. È possibile impostare la priorità nello stesso ordine.
Regole in ingresso
Traffico client: consente il traffico in ingresso dai client previsti (come intervallo IP o IP di origine) e per la destinazione come prefisso IP dell'intera subnet del gateway applicazione e porte di accesso in ingresso. Ad esempio, se sono configurati listener per le porte 80 e 443, è necessario consentire queste porte. È anche possibile impostare questa regola su Any.
| Origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Accesso |
|---|---|---|---|---|---|
<as per need> |
Any | <Subnet IP Prefix> |
<listener ports> |
TCP | Consenti |
Dopo aver configurato listener pubblici e privati attivi (con regole) con lo stesso numero di porta, il gateway applicazione modifica la destinazione di tutti i flussi in ingresso agli indirizzi IP front-end del gateway. Questa modifica si verifica anche per i listener che non condividono alcuna porta. Quando si usa la stessa configurazione della porta, è necessario includere gli indirizzi IP pubblici e privati del gateway nella destinazione della regola in ingresso.
| Origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Accesso |
|---|---|---|---|---|---|
<as per need> |
Any | <Public and Private frontend IPs> |
<listener ports> |
TCP | Consenti |
Porte dell'infrastruttura: consente le richieste in ingresso dall'origine come tag del servizio GatewayManager e Qualsiasi destinazione. L'intervallo di porte di destinazione è diverso in base allo SKU ed è necessario per comunicare lo stato dell'integrità back-end. Queste porte sono protette o bloccate dai certificati di Azure. Le entità esterne non possono avviare modifiche su tali endpoint senza certificati appropriati.
- V2: Porte 65200-65535
- V1: Porte 65503-65534
| Origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Accesso |
|---|---|---|---|---|---|
| GatewayManager | Qualsiasi | Qualsiasi | <as per SKU given above> |
TCP | Consenti |
Probe di Azure Load Balancer: consente il traffico in ingresso dall'origine come tag del servizio AzureLoadBalancer. Questa regola viene creata per impostazione predefinita per i gruppi di sicurezza di rete. Non è necessario eseguirne l'override con una regola di negazione manuale per garantire operazioni uniformi del gateway applicazione.
| Origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Accesso |
|---|---|---|---|---|---|
| AzureLoadBalancer | Qualsiasi | Qualsiasi | Qualsiasi | Qualsiasi | Consenti |
È possibile bloccare tutto il traffico in ingresso usando una regola Nega tutto.
Regole in uscita
In uscita verso Internet: consente il traffico in uscita verso Internet per tutte le destinazioni. Questa regola viene creata per impostazione predefinita per i gruppi di sicurezza di rete. Non è necessario eseguirne l'override con una regola di negazione manuale per garantire operazioni uniformi del gateway applicazione. Le regole del gruppo di sicurezza di rete in uscita che negano la connettività in uscita non devono essere create.
| Origine | Porte di origine | Destinazione | Porte di destinazione | Protocollo | Accesso |
|---|---|---|---|---|---|
| Qualsiasi | Qualsiasi | Internet | Qualsiasi | Qualsiasi | Consenti |
Nota
gateway applicazione che non hanno L'isolamento di rete abilitato non consente l'invio del traffico tra reti virtuali con peering quando l'opzione Consenti il traffico verso la rete virtuale remota è disabilitata.
Route definite dall'utente supportate
Il controllo granulare sulla subnet del gateway applicazione tramite regole della tabella di route è possibile in anteprima pubblica. Per altre informazioni, vedere distribuzione del gateway applicazione privato (anteprima).
Con la funzionalità corrente, esistono alcune restrizioni:
Importante
L'uso di route definite dall'utente nella subnet del gateway applicazione potrebbe causare la visualizzazione dello stato di integrità nel back-end come Sconosciuto. Potrebbe anche causare l'esito negativo della generazione di log e metriche del gateway applicazione. È consigliabile non usare route definite dall'utente nella subnet del gateway applicazione in modo da poter visualizzare l'integrità, i log e le metriche back-end.
v1: per lo SKU v1, le route definite dall'utente sono supportate nella subnet del gateway applicazione se non modificano la comunicazione di richiesta/risposta end-to-end. Ad esempio, è possibile configurare una route definita dall'utente nella subnet del gateway applicazione in modo che punti a un'appliance del firewall per l'ispezione dei pacchetti. È tuttavia necessario assicurarsi che il pacchetto possa raggiungere la destinazione prevista dopo l'ispezione. In caso contrario, è possibile che si ottengano probe di integrità o comportamento di instradamento del traffico non corretti. Sono incluse anche route apprese o route predefinite 0.0.0.0/0 propagate da Azure ExpressRoute o gateway VPN nella rete virtuale.
v2: per lo SKU v2 sono disponibili scenari supportati e non supportati.
Scenari supportati v2
Avviso
Una configurazione errata della tabella di route potrebbe comportare il routing asimmetrico nel gateway applicazione v2. Assicurarsi che tutto il traffico del piano di gestione/controllo venga inviato direttamente a Internet e non attraverso un'appliance virtuale. Potrebbero essere interessati anche la registrazione, le metriche e i controlli CRL.
Scenario 1: Route definita dall'utente per disabilitare propagazione della route BGP (Border Gateway Protocol) alla subnet del gateway applicazione
A volte la route del gateway predefinita (0.0.0.0/0) viene annunciata tramite i gateway ExpressRoute o VPN associati alla rete virtuale del gateway applicazione. Questo comportamento interrompe il traffico del piano di gestione, che richiede un percorso diretto verso Internet. In questi scenari, è possibile usare una route definita dall'utente per disabilitare la propagazione della route BGP.
Per disabilitare la propagazione della route BGP:
- Creare una risorsa tabella di route in Azure.
- Disabilitare il parametro di propagazione della route del gateway di rete virtuale.
- Associare la tabella di route alla subnet appropriata.
L'abilitazione della route definita dall'utente per questo scenario non deve interrompere le configurazioni esistenti.
Scenario 2: route definita dall'utente per indirizzare 0.0.0.0/0 a Internet
È possibile creare una route definita dall'utente per inviare il traffico 0.0.0.0/0 direttamente a Internet.
Scenario 3: route definita dall'utente per il servizio Azure Kubernetes con kubenet
Se si usa kubenet con il servizio Azure Kubernetes e il controller di ingresso del gateway applicazione, è necessaria una tabella di route per consentire il routing del traffico ai pod dal gateway applicazione al nodo corretto. Non è necessario usare una tabella di route se si usa l'interfaccia di rete di Azure Container.
Per usare la tabella di route per consentire il funzionamento di kubenet:
Passare al gruppo di risorse creato dal servizio Azure Kubernetes. Il nome del gruppo di risorse deve iniziare con
MC_.Trovare la tabella di route creata dal servizio Azure Kubernetes in tale gruppo di risorse. La tabella di route deve essere popolata con le informazioni seguenti:
- Il prefisso dell'indirizzo deve essere l'intervallo IP dei pod che si desidera raggiungere nel servizio Azure Kubernetes.
- Il tipo di hop successivo deve essere un'appliance virtuale.
- L'indirizzo hop successivo deve essere l'indirizzo IP del nodo che ospita i pod.
Associare questa tabella di route alla subnet del gateway applicazione.
Scenari non supportati v2
Scenario 1: route definita dall'utente per le appliance virtuali
Qualsiasi scenario in cui 0.0.0.0/0 deve essere reindirizzato tramite un'appliance virtuale, una rete virtuale hub/spoke o un tunneling forzato (tunneling forzato) non è supportato per la versione 2.