Configura connettività privata tra tenaci tra regioni incrociate
Per motivi commerciali e tecnici, potrebbe essere necessario abilitare la connettività privata tra le reti virtuali nel cloud e garantire che il traffico tra le reti non attraversa mai Internet pubblico. Ad esempio, potrebbe essere necessaria una connettività privata tra le reti in due aree all'interno della tenancy o tra le reti nella tenancy e quelle nella tenancy di un'organizzazione che ha collaborato.
Oracle Cloud Infrastructure supporta due modelli di network-peering:
- Peering VCN locale
Le reti cloud virtuali (VCN) all'interno di un'area possono essere sottoposte a peering utilizzando i gateway peering locali (LPG). Le risorse collegate a tali VCN peered possono comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet pubblico. I VCN possono trovarsi nella stessa tenancy o in tenancie diverse.
- Peering VCN remoto
I VCN in diverse regioni possono comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet pubblico. È possibile impostare il peering tra due VCN in aree diverse configurando una connessione peering remota (RPC) su ciascuno dei gateway di instradamento dinamico (DRG) associati ai VCN nella relazione peering. Il peering VCN remoto viene generalmente utilizzato per connettere due VCN tra le aree nella stessa tenancy. In alcuni scenari, potrebbe essere necessario connettere VCN in due diverse tenancie in tutte le aree.
Architettura
In questa architettura, la connettività di rete privata è configurata tra due tenance e tra due aree.
Descrizione dell'immagine xregion-private-connectivity-oci.png
L'architettura ha i seguenti componenti:
- Tensione
Una tenancy è una partizione sicura e isolata impostata da Oracle all'interno di Oracle Cloud al momento della registrazione a Oracle Cloud Infrastructure. È possibile creare, organizzare e amministrare le risorse in Oracle Cloud all'interno della tenancy.
Questa architettura ha due tenance, una per l'azienda A e l'altra per l'azienda B.
- Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni, e vaste distanze possono separarle (tra paesi o addirittura continenti).
Questa architettura ha due regioni. L'azienda A ha le sue risorse cloud in una singola regione, USA East (Ashburn). Le risorse della Società B sono distribuite in due regioni: USA Est (Ashburn) e India Ovest (Mumbai).
- Rete cloud virtuale (VCN)
Un VCN è una rete privata personalizzabile impostata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, i VCN ti danno il controllo completo sul tuo ambiente di rete. È possibile segmentare i VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Le subnet regionali e le subnet specifiche del dominio di disponibilità possono coesistere nello stesso VCN. Una subnet può essere pubblica o privata.
In questa architettura, la società A dispone di VCN 10.0.0.0/16 nell'area USA East (Ashburn). La società B dispone di due VCN, ciascuno in un'area diversa: VCN B 172.16.0.0/16 in USA East (Ashburn) e VCN C 192.168.0.0/16 in India West (Mumbai). Tenere presente che ogni VCN in questa architettura peering dispone di un prefisso CIDR univoco.
- Gateway instradamento dinamico (DRG)
DRG è un router virtuale che fornisce un percorso per il traffico di rete privata tra un VCN e una rete al di fuori dell'area, ad esempio un VCN in un'altra area Oracle Cloud Infrastructure, una rete in locale o una rete in un altro provider cloud.
In questa architettura, VCN B in Ashburn e VCN C in Mumbai vengono sottoposti a peeling da remoto utilizzando DRG.
- Gateway peering locale (GPL)
Un GPL consente di eseguire il peer di un VCN con un altro VCN nella stessa area. Peering significa che i VCN comunicano utilizzando indirizzi IP privati, senza il traffico che attraversa Internet o il routing attraverso la rete on-premise.
In questa architettura, VCN A e VCN B (entrambi all'interno dell'area Ashburn) vengono sottoposti a peeling localmente utilizzando LPG.
- Tabelle instradamento
Le tabelle di instradamento virtuale contengono regole per instradare il traffico dalle subnet alle destinazioni al di fuori di un VCN, in genere tramite gateway.
Questa architettura include tabelle di instradamento per indirizzare il traffico attraverso i VCN.- VCN A dispone di regole di instradamento per indirizzare il traffico ai VCN B e C tramite il GPL.
- VCN B dispone di regole di instradamento per indirizzare il traffico a VCN A attraverso il GPL e a VCN C tramite DRG.
- VCN C dispone di regole di instradamento per indirizzare il traffico ai VCN A e C tramite DRG.
Suggerimenti
Utilizzare i suggerimenti riportati di seguito come punto di partenza. Le vostre esigenze potrebbero differire dall'architettura descritta qui.
- Gestione identità e accesso (IAM)
È possibile configurare un criterio IAM per consentire agli utenti di un solo gruppo specifico di avviare connessioni da qualsiasi GPL nel compartimento del richiedente (compartimento Società A) a una tenancy specifica. Collegare il criterio alla tenancy del richiedente, ovvero al compartimento
root, e non al compartimento del richiedente. - VCN
Quando si crea VCN, determinare il numero di indirizzi IP necessari per le risorse cloud in ogni subnet. Utilizzando la notazione CIDR (Classless Inter-Domain Routing), specificare una maschera subnet e un intervallo di indirizzi di rete sufficientemente grande per gli indirizzi IP richiesti. Utilizzare un intervallo di indirizzi all'interno dello spazio degli indirizzi IP privati standard.
Selezionare un intervallo di indirizzi che non si sovrapponga a nessun'altra rete (in Oracle Cloud Infrastructure, nel data center in locale o in un altro provider cloud) a cui si intende impostare connessioni private.
- Regole di sicurezza
Per controllare il traffico di rete, è possibile utilizzare elenchi di sicurezza o gruppi di sicurezza di rete (NSG). Le regole specificate in una lista di sicurezza si applicano a tutte le VNIC nella subnet a cui si allega la lista di sicurezza. Se hai bisogno di firewall a un livello più granulare, usa i gruppi di sicurezza di rete (NSG). Le regole in un NSG si applicano solo alle VNIC specificate. Oracle consiglia di utilizzare gli NSG perché consentono di separare l'architettura della subnet dai requisiti di sicurezza del carico di lavoro.
Considerazioni
Quando si implementa questa architettura, prendere in considerazione i seguenti fattori:
- Scalabilità
Considerare i limiti di servizio per VCN e subnet per la tenancy. Se hai bisogno di più reti, richiedi un aumento dei limiti.
- Sicurezza
Utilizzare meccanismi di sicurezza appropriati per proteggere la topologia.
Nell'architettura distribuita utilizzando il codice Terraform fornito, la lista di sicurezza predefinita di VCN consente il traffico SSH da 0.0.0.0/0 e ICMP solo da entrambe le tenancies. Regolare la lista di sicurezza per consentire solo agli host e alle reti che devono disporre dell'accesso SSH (o dell'accesso ad altre porte di servizio richieste) all'infrastruttura.
- Prestazioni
In un'area, il numero di VCN non influisce sulle prestazioni. Quando si esegue il peer dei VCN in aree diverse, considerare la latenza.
Distribuisci
Il codice Terraform per distribuire questa architettura è disponibile in GitHub.
- Andare a GitHub.
- Duplicare o scaricare il repository nel computer locale.
- Seguire le istruzioni contenute nel documento
README.
Log delle modifiche
Questo log elenca le modifiche significative:
| 8 settembre 2020 |
|
| 31 maggio 2021 | Diagramma architettonico aggiornato per riflettere nuovi standard iconografici. |