Condividi tramite


Considerazioni sulla topologia di rete e sulla connettività per Red Hat Enterprise Linux in Azure

Questo articolo descrive le considerazioni e le raccomandazioni sulla rete di Red Hat Enterprise Linux (RHEL) basate sulle linee guida nell'area di progettazione della zona di destinazione di Azure per la topologia e la connettività di rete.

Architettura

L'architettura RHEL seguente è un punto di partenza che è possibile adattare ulteriormente per soddisfare i requisiti aziendali e tecnici specifici. È possibile distribuire i vari componenti e ruoli della piattaforma RHEL nelle macchine virtuali (VM) con dimensioni e ridondanza specifiche in base alle esigenze. Il layout di rete semplificato in questi esempi illustra i principi architetturali e non descrive un'intera rete aziendale.

Diagramma che mostra un'architettura di riferimento RHEL.

Scaricare un file di Visio di questa architettura.

Elemento Descrizione
A Componenti nel Contratto del cliente Microsoft e fatturazione
G Componenti della gestione delle identità e degli accessi di Microsoft Entra
A Componenti nei gruppi di gestione di Azure
D Componenti nella sottoscrizione di Gestione delle identità di Active Directory di Windows Server
E Componenti nella sottoscrizione dell'hub di rete
F Componenti nella sottoscrizione di gestione e identità di RHEL
G Componenti nella sottoscrizione del gruppo di gestione di Azure
H Componenti nella sottoscrizione del carico di lavoro di produzione RHEL
I Componenti locali
J Servizi cloud Red Hat

Considerazioni sulla progettazione per la rete delle zone di destinazione RHEL

Prendere in considerazione i consigli seguenti per la progettazione della rete della zona di destinazione:

  • Usare una topologia di rete hub-spoke per distribuzioni a singola area o a più aree. L'hub rete WAN virtuale di Azure offre funzionalità aggiuntive oppure è possibile usare un hub di rete virtuale tradizionale. Per altre informazioni, vedere Rete dell'area di destinazione di Azure.

  • Usare l'infrastruttura come codice per automatizzare le distribuzioni, la gestione della configurazione e le operazioni quotidiane 2 per tutti i componenti correlati alla rete della zona di destinazione.

  • Usare gli endpoint privati per tutti i servizi di Azure supportati per migliorare la sicurezza. Gli endpoint privati assicurano che tutte le route di traffico attraverso la rete privata anziché gli indirizzi IP pubblici.

Considerazioni relative al firewall

Il diagramma seguente illustra un'architettura della zona di destinazione RHEL dell'area di destinazione di Azure ibrida.

Diagramma che mostra un'architettura della zona di destinazione RHEL dell'area di destinazione ibrida di Azure.

Elemento Descrizione
A Componenti nella rete virtuale di Red Hat Management contenuti tramite la sottoscrizione di Red Hat Management
G Componenti nella rete virtuale RHEL Workloads contenuti tramite la sottoscrizione RHEL Production Workloads
A Componenti nella rete virtuale di Identity Management contenuti tramite la sottoscrizione di Red Hat Identity Management
D Componenti nella rete virtuale RHEL Workloads contenuti tramite la sottoscrizione RHEL Production Workloads
  • Per rete WAN virtuale topologie, è consigliabile usare Firewall di Azure per instradare il traffico tra le zone di destinazione. Firewall di Azure offre funzionalità di filtro e registrazione del traffico.

  • Un gateway VPN di Azure o un gateway ExpressRoute di Azure controlla la connettività ibrida all'hub. Per monitorare e controllare il traffico, usare Firewall di Azure o un'appliance di rete virtuale nell'hub.

  • È possibile usare un firewall locale per proteggere e instradare tutto il traffico Internet in ingresso e in uscita. Un firewall potrebbe introdurre latenza per le risorse basate sul cloud. Comprendere i requisiti di prestazioni e sicurezza per determinare come instradare il traffico in ingresso e in uscita.

Considerazioni sulla subnet

Il diagramma seguente illustra le subnet di gestione e carico di lavoro in una configurazione resiliente alla zona.

Diagramma che mostra le subnet di gestione e carico di lavoro in una configurazione resiliente alla zona.

  • Quando si pianificano ambiti di indirizzi IP e dimensioni di rete virtuale per la zona di destinazione RHEL, prendere in considerazione subnet dedicate per le risorse di applicazione, database e archiviazione.

  • Adottare un approccio basato su Zero Trust per la rete perimetrale e la sicurezza del traffico. Per altre informazioni, vedere Strategie per la sicurezza della rete in Azure.

Considerazioni sul gruppo di sicurezza di rete

Diagramma che mostra una configurazione del gruppo di sicurezza di rete per la sicurezza del traffico.

  • Usare i gruppi di sicurezza di rete (NSG) per proteggere il traffico tra subnet e traffico orientale e occidentale attraverso la piattaforma (traffico tra zone di destinazione). Criteri di Azure possibile impostare questa configurazione come predefinita per tutte le subnet.

  • Usare gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni per micro segmentare il traffico all'interno della zona di destinazione ed evitare l'uso di un'appliance virtuale di rete centrale per filtrare i flussi di traffico.

  • Abilitare i log dei flussi del gruppo di sicurezza di rete e inserirli nell'analisi del traffico. Per ottimizzare la capacità di controllo e la sicurezza, abilitare i log dei flussi in tutte le reti virtuali e le subnet critiche nella sottoscrizione.

  • Usare i gruppi di sicurezza di rete per consentire in modo selettivo la connettività tra le zone di destinazione.

  • Il team dell'applicazione deve usare i gruppi di sicurezza delle applicazioni ai gruppi di sicurezza di rete a livello di subnet per proteggere le macchine virtuali multilivello all'interno della zona di destinazione.

  • Se l'organizzazione implementa il tunneling forzato o una route predefinita pubblicizzata, verso posizioni locali, è consigliabile incorporare regole del gruppo di sicurezza di rete in uscita per negare il traffico in uscita dalla rete virtuale direttamente a Internet. Questa configurazione offre resilienza se la sessione BGP (Border Gateway Protocol) viene eliminata. Per altre informazioni, vedere Pianificare la segmentazione della rete della zona di destinazione.

Altre considerazioni

  • Abilitare Internet e filtrare ed esaminare il traffico. Le opzioni in uscita per abilitare Internet e filtrare e controllare il traffico includono:

    • Accesso in uscita a Red Hat Cloud tramite la rete hub.
    • Route predefinita locale che usa l'accesso a Internet locale.
    • rete WAN virtuale o l'hub di rete virtuale tradizionale protetto con Firewall di Azure o un'appliance virtuale di rete.
  • Distribuire contenuto e applicazioni. Le opzioni in ingresso per distribuire contenuto e applicazioni includono:

    • app Azure lication Gateway con L7, terminazione TLS (Transport Layer Security) e Web application firewall.
    • Dynamic Network Translation (DNAT) e un servizio di bilanciamento del carico dall'ambiente locale.
    • Azure Rete virtuale con Firewall di Azure o un'appliance virtuale di rete e un server di route di Azure in vari scenari.
    • rete WAN virtuale hub con Firewall di Azure, con L4 e DNAT.
    • rete WAN virtuale hub con appliance virtuale di rete in vari scenari.
  • Configurare la risoluzione dei nomi di dominio per le risorse locali e di Azure. L'ambiente RHEL usa spesso risorse locali e di Azure, che richiedono una risoluzione efficace dei nomi delle risorse. Prendi in considerazione le seguenti raccomandazioni:

    • Azure offre una risoluzione dei nomi interna predefinita all'interno di una rete virtuale. Questo scenario non richiede alcuna configurazione. Non è possibile modificare il suffisso di risoluzione dei nomi di dominio o eseguire la registrazione manuale. Per altre informazioni, vedere Risoluzione dei nomi fornita da Azure.
    • Per la risoluzione dei nomi tra reti virtuali, le distribuzioni RHEL usano spesso servizi DNS (Domain Name System) da Redhat Identity Management Server (IdM) o DNS di Azure. Per fornire l'inoltro basato su regole, combinare Azure DNS privato Resolver e l'infrastruttura DNS esistente.

Passaggio successivo