Condividi tramite

Collegamento privato di Azure in una rete hub-and-spoke

Questo articolo descrive come usare il collegamento privato di Azure in una topologia di rete hub-spoke. Il gruppo di destinatari include architetti di rete e architetti di soluzioni cloud. Questa guida illustra come usare gli endpoint privati di Azure per accedere privatamente alle risorse PaaS (Platform as a Service).

Questa guida non illustra l'integrazione della rete virtuale, gli endpoint di servizio e altre soluzioni per la connessione dei componenti IaaS (Infrastructure as a Service) alle risorse PaaS di Azure. Per altre informazioni su queste soluzioni, vedere Integrare i servizi di Azure con le reti virtuali per l'isolamento della rete.

Topologie hub-spoke di Azure

È possibile usare una topologia di rete hub-spoke in Azure per gestire in modo efficiente i servizi di comunicazione e soddisfare i requisiti di sicurezza su larga scala. Per altre informazioni, vedere Topologia di rete Hub-spoke.

Un'architettura hub-spoke offre i vantaggi seguenti:

  • Distribuisce singoli carichi di lavoro tra team IT centrali e team del carico di lavoro
  • Consente di risparmiare sui costi riducendo al minimo le risorse ridondanti
  • Gestisce le reti in modo efficiente centralizzando i servizi condivisi da più carichi di lavoro
  • Supera i limiti associati a una singola sottoscrizione di Azure

Il diagramma seguente illustra una tipica topologia hub-spoke che è possibile distribuire in Azure.

Diagramma dell'architettura che mostra una rete virtuale hub e due spoke. Uno spoke è una rete locale. L'altro è una rete virtuale della zona di destinazione.

Scaricare un file di Visio di questa architettura.

Questa architettura è una delle due opzioni di topologia di rete supportate da Azure. Questa progettazione di riferimento classica usa componenti di rete di base come Azure Rete virtuale, peering di rete virtuale e route definite dall'utente. Quando si usa una topologia hub-spoke, si configurano i servizi ed è necessario assicurarsi che la rete soddisfi i requisiti di sicurezza e routing.

Azure rete WAN virtuale offre un'alternativa per le distribuzioni su larga scala. Questo servizio usa una progettazione di rete semplificata. La rete WAN virtuale riduce il sovraccarico di configurazione associato al routing e alla sicurezza.

collegamento privato supporta diverse opzioni per le reti hub-spoke tradizionali e per le reti rete WAN virtuale.

Collegamento privato fornisce l'accesso ai servizi tramite un'interfaccia di rete di endpoint privato. Un endpoint privato usa un indirizzo IP privato dalla rete virtuale. È possibile accedere a vari servizi tramite tale indirizzo IP privato:

  • Servizi PaaS di Azure
  • Servizi di proprietà del cliente ospitati da Azure
  • Servizi partner ospitati da Azure

Il traffico tra la rete virtuale e il servizio a cui si accede passa attraverso il backbone di rete di Azure. Di conseguenza, non si accede più al servizio tramite un endpoint pubblico. For more information, see Private Link.

Il diagramma seguente illustra come gli utenti locali si connettono a una rete virtuale e usano il collegamento privato per accedere alle risorse PaaS.

Diagramma dell'architettura che mostra come collegamento privato di Azure connette una rete virtuale alle risorse PaaS.

Scaricare un file di Visio di questa architettura.

È possibile distribuire endpoint privati in un hub o in uno spoke. Alcuni fattori determinano quale posizione funziona meglio in ogni situazione. Considerare i fattori seguenti per determinare la configurazione migliore per i servizi PaaS di Azure e per i servizi di proprietà del cliente e dei partner ospitati da Azure.

Determinare se si usa la rete WAN virtuale come soluzione di connettività di rete

Se si usa rete WAN virtuale, è possibile distribuire solo endpoint privati in reti virtuali spoke connesse all'hub virtuale. Non è possibile distribuire risorse nell'hub virtuale o nell'hub protetto.

Per altre informazioni sull'integrazione di endpoint privati nella rete, vedere gli articoli seguenti:

Determinare se si usa un'appliance virtuale di rete, ad esempio Firewall di Azure

Il traffico verso endpoint privati usa il backbone di rete di Azure e viene crittografato. Potrebbe essere necessario registrare o filtrare il traffico. È anche possibile analizzare il traffico che passa agli endpoint privati se si usa un firewall nelle aree seguenti:

  • Across spokes
  • Tra l'hub e gli spoke
  • Tra i componenti locali e le reti di Azure

In questo caso, distribuire endpoint privati nell'hub in una subnet dedicata. Questa configurazione offre i vantaggi seguenti:

  • Semplifica la configurazione della regola SNAT (Secure Network Address Translation). È possibile creare una singola regola SNAT nell'appliance virtuale di rete per il traffico verso la subnet dedicata che contiene gli endpoint privati. È possibile instradare il traffico ad altre applicazioni senza applicare SNAT.

  • Semplifica la configurazione della tabella di route. Per il traffico che passa agli endpoint privati, è possibile aggiungere una regola per instradare il traffico attraverso l'appliance virtuale di rete. È possibile riutilizzare tale regola tra tutti gli spoke, i gateway VPN (Virtual Private Network) e i gateway Di Azure ExpressRoute.

  • Consente di applicare le regole del gruppo di sicurezza di rete per il traffico in ingresso nella subnet dedicata a un endpoint privato. Queste regole filtrano il traffico verso le risorse. Forniscono un'unica posizione per controllare l'accesso alle risorse.

  • Centralizza la gestione degli endpoint privati. Se si distribuiscono tutti gli endpoint privati in un'unica posizione, è possibile gestirli in modo più efficiente in tutte le reti virtuali e nelle sottoscrizioni.

Usare questa configurazione quando tutti i carichi di lavoro devono accedere a ogni risorsa PaaS che il collegamento privato protegge. Se i carichi di lavoro accedono a risorse PaaS diverse, non distribuire endpoint privati in una subnet dedicata. Migliorare invece la sicurezza seguendo il principio dei privilegi minimi:

  • Posizionare ogni endpoint privato in una subnet separata.
  • Concedere solo ai carichi di lavoro che usano un accesso protetto a tale risorsa.

Determinare se si usa un endpoint privato da un sistema locale

Se si prevede di usare endpoint privati per accedere alle risorse da un sistema locale, distribuire gli endpoint nell'hub. Questa configurazione offre i vantaggi seguenti:

  • È possibile usare i gruppi di sicurezza di rete per controllare l'accesso alle risorse.
  • È possibile gestire gli endpoint privati in una posizione centralizzata.

Se si prevede di accedere alle risorse dalle applicazioni distribuite in Azure, si applicano i fattori seguenti:

  • Se una sola applicazione deve accedere alle risorse, distribuire un endpoint privato nello spoke dell'applicazione.
  • Se più applicazioni devono accedere alle risorse, distribuire un endpoint privato nell'hub.

Flowchart

Il diagramma di flusso seguente riepiloga le opzioni e le raccomandazioni. Ogni cliente ha un ambiente univoco, quindi prendere in considerazione i requisiti del sistema quando si decide dove posizionare gli endpoint privati.

Diagramma di flusso che illustra il processo di decidere se posizionare il collegamento privato in uno spoke o nell'hub di una rete hub-spoke.

Scaricare un file di Visio di questa architettura.

Considerations

I fattori seguenti possono influire sull'implementazione dell'endpoint privato. Si applicano ai servizi PaaS di Azure e ai servizi di proprietà del cliente e partner ospitati da Azure.

Networking

Quando si usano endpoint privati in una rete virtuale spoke, la tabella di route predefinita della subnet include una /32 route, con un tipo di hop successivo .InterfaceEndpoint

  • Se si usa una topologia hub-spoke tradizionale, è possibile visualizzare questa route efficace a livello di interfaccia di rete delle macchine virtuali.If you use a traditional hub-and-spoke topology, you can view this effective route at the network-interface level of your virtual machines (VM). Per altre informazioni, vedere Diagnosticare un problema di routing delle macchine virtuali.

  • Se si usa la rete WAN virtuale, è possibile visualizzare questa route nelle route valide dell'hub virtuale. Per altre informazioni, vedere Visualizzare le route valide dell'hub virtuale.

Il /32 percorso viene propagato alle aree seguenti:

  • Qualsiasi peering di rete virtuale configurato
  • Qualsiasi connessione VPN o ExpressRoute a un sistema locale

Per limitare l'accesso dall'hub o dal sistema locale a un endpoint privato, usare un gruppo di sicurezza di rete nella subnet in cui si distribuisce l'endpoint privato. Configurare le regole in ingresso appropriate.

Name resolution

I componenti nella rete virtuale associano un indirizzo IP privato a ogni endpoint privato. Questi componenti possono risolvere tale indirizzo IP privato solo se si usa una configurazione DNS (Domain Name System) specifica. Se si usa una soluzione DNS personalizzata, usare i gruppi di zone DNS. Integrare l'endpoint privato con una zona DNS privata di Azure centralizzata, indipendentemente dal fatto che si distribuiscano risorse in un hub o in uno spoke. Collegare la zona DNS privata a tutte le reti virtuali che devono risolvere il nome DNS dell'endpoint privato.

In questo approccio, i client DNS di Azure e locali possono risolvere il nome e accedere all'indirizzo IP privato. Per un'implementazione di riferimento, vedere integrazione di collegamento privato e DNS su larga scala.

Costs

  • Quando si usano endpoint privati in un peering di rete virtuale a livello di area, le tariffe di peering non si applicano per il traffico da e verso endpoint privati.

  • I costi di peering si applicano con altro traffico di risorse dell'infrastruttura che passa attraverso un peering di rete virtuale.

  • Quando si distribuiscono endpoint privati in aree diverse, si applicano le tariffe di collegamento privato e il peering globale in ingresso e in uscita.

For more information, see Bandwidth pricing.

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Principal author:

  • Jose Angel Fintune Miguelues | Senior Specialist GBB

Other contributor:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Next steps