Documentazione dell'infrastruttura Oracle Cloud

Accesso ad altri VCN: peering

Il peering VCN è il processo di connessione di molte reti cloud virtuali (VCN). Sono disponibili quattro tipi di peering VCN:

Puoi utilizzare il peering VCN per dividere una rete di grandi dimensioni in diverse reti VCN (ad esempio, in base a dipartimenti o linee di business), con ogni VCN che dispone di accesso diretto e privato alle altre. Il traffico non deve fluire su Internet o tramite una rete on-premise tramite la VPN site-to-site o FastConnect. Puoi anche collocare le risorse condivise in un'unica VCN a cui tutte le altre VCN possono accedere privatamente.

Ogni VCN può avere fino a 10 gateway peering locali e può collegarsi a un solo DRG. Un singolo DRG supporta fino a 300 collegamenti VCN, consentendo al traffico tra di loro di fluire secondo le indicazioni delle tabelle di instradamento del DRG. Si consiglia di utilizzare il gateway DRG se è necessario eseguire il peer con molte reti VCN. Se desideri la massima larghezza di banda possibile e il traffico a bassissima latenza tra due VCN nella stessa area, utilizza lo scenario descritto in Peering VCN locale mediante Local Peering Gateway. Il peering VCN locale tramite un DRG aggiornato ti offre maggiore flessibilità nell'instradamento a causa del maggior numero di collegamenti.

Poiché il peering VCN remoto attraversa le aree, puoi utilizzarlo (ad esempio) per eseguire il mirroring o il backup dei database in un'area a un'altra.

Panoramica del peering VCN locale

Il peering VCN locale è il processo di connessione di due VCN nella stessa area in modo che le risorse possano comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet o tramite una rete on-premise. I VCN possono trovarsi nella stessa tenancy di Oracle Cloud Infrastructure o in una diversa. Senza il peering, una VCN specifica avrebbe bisogno di un gateway Internet e di indirizzi IP pubblici per le istanze che devono comunicare con un'altra VCN.

Il peering VCN locale tramite un DRG aggiornato ti offre maggiore flessibilità nell'instradamento e nella gestione semplificata, ma ha il costo di un aumento della latenza (in microsecondi) derivante dall'instradamento del traffico attraverso un router virtuale, il DRG.

Importanti implicazioni del peering

Questa sezione contiene un riepilogo di alcune implicazioni relative a controllo dell'accesso, sicurezza e prestazioni per le reti VCN peer. In generale, puoi controllare l'accesso e il traffico tra due VCN in peer utilizzando i criteri IAM, le tabelle di instradamento in ogni VCN e gli elenchi di sicurezza in ogni VCN.

Controllo dell'istituzione di pari livello

Con i criteri IAM, puoi controllare:

Controllo del flusso di traffico sulla connessione

Anche se è stata stabilita una connessione peering tra una VCN e un'altra, puoi controllare il flusso di pacchetti sulla connessione con le tabelle di instradamento nella VCN. Ad esempio, puoi limitare il traffico solo a subnet specifiche nell'altra VCN.

Senza terminare il peering, puoi interrompere il flusso di traffico verso l'altra VCN rimuovendo le regole di instradamento che indirizzano il traffico da una VCN all'altra VCN. Puoi anche arrestare il traffico in modo efficace rimuovendo qualsiasi regola della lista di sicurezza che abiliti il traffico in entrata o in uscita con l'altra VCN. Ciò non arresta il flusso di traffico sulla connessione peering, ma lo arresta a livello di VNIC.

Per ulteriori informazioni sulle liste di routing e sicurezza, consultare le discussioni descritte nelle sezioni seguenti:

Peering VCN locale mediante gruppi di peering locali:

Peering VCN remoto utilizzando una connessione peering remoto:

Peering VCN locale mediante un gateway di instradamento dinamico (DRG):

Peering VCN remoto mediante un gateway di instradamento dinamico (DRG):

Controllo dei tipi specifici di traffico consentiti

Ogni amministratore della VCN garantisce che tutto il traffico in uscita e in entrata con l'altra VCN sia previsto o previsto e definito. In pratica, ciò significa implementare regole della lista di sicurezza che dichiarano in modo esplicito i tipi di traffico che una VCN può inviare all'altra e accettare dall'altra.

Importante

Le istanze di computazione che eseguono immagini della piattaforma dispongono anche di regole del firewall del sistema operativo che controllano l'accesso all'istanza. Durante la risoluzione dei problemi di accesso a un'istanza, assicurarsi che tutti gli elementi riportati di seguito siano impostati correttamente.

  • Le regole nei gruppi di sicurezza di rete in cui si trova l'istanza
  • Le regole negli elenchi di sicurezza associati alla subnet dell'istanza
  • Regole firewall del sistema operativo dell'istanza

Se un'istanza esegue Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 o Oracle Linux Cloud Developer 8, devi utilizzare firewalld per interagire con le regole iptables. Per riferimento, ecco i comandi per l'apertura di una porta (1521 in questo esempio):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Per le istanze con un volume di avvio iSCSI, il comando --reload precedente può causare problemi. Per informazioni dettagliate e una soluzione alternativa, vedere Instances experience system hang after running firewall-cmd --reload.

Oltre alle liste di sicurezza e ai firewall, valuta altre configurazioni basate sul sistema operativo sulle istanze nella VCN locale. Potrebbero essere presenti configurazioni predefinite che non si applicano al CIDR della VCN locale, ma si applicano inavvertitamente al CIDR dell'altra VCN.

Utilizzo delle regole dell'elenco di sicurezza predefinite

Se le subnet della VCN locale utilizzano la lista di sicurezza predefinita con le regole predefinite fornite, tenere presente due regole che consentono il traffico in entrata da qualsiasi luogo (0.0.0.0/0 e quindi l'altra VCN):

  • Regola di entrata con conservazione dello stato che consente il traffico della porta TCP 22 (SSH) da 0.0.0.0/0 e da qualsiasi porta di origine
  • Regola di entrata con conservazione dello stato che consente il traffico ICMP di tipo 3, codice 4 da 0.0.0.0/0 e da qualsiasi porta di origine

Valutare queste regole e se si desidera conservarle o aggiornarle. Come indicato in precedenza, assicurarsi che tutto il traffico in entrata o in uscita consentito sia previsto o previsto e definito.

Prepararsi all'impatto sulle prestazioni e ai rischi per la sicurezza

In generale, preparare la VCN locale per i modi in cui potrebbe essere interessata dall'altra VCN. Ad esempio, il carico sulla VCN locale o sulle relative istanze potrebbe aumentare. In alternativa, la VCN locale potrebbe subire un attacco dannoso direttamente da o tramite l'altra VCN.

Per quanto riguarda le prestazioni: se la VCN locale fornisce un servizio a un altro, essere pronti a eseguire lo scale-up del servizio per soddisfare le esigenze dell'altra VCN. Ciò potrebbe significare essere pronto a creare più istanze di computazione in base alle esigenze. In alternativa, se sei preoccupato per gli alti livelli di traffico di rete che arrivano alla VCN locale, considera l'uso di regole della lista di sicurezza senza stato per limitare il livello di monitoraggio della connessione che la VCN locale deve eseguire. Le regole della lista di sicurezza senza conservazione dello stato possono anche rallentare l'impatto di un attacco Denial-of-Service (DoS).

Per quanto riguarda i rischi per la sicurezza: non puoi necessariamente controllare se l'altra VCN è connessa a Internet, il che potrebbe esporre la VCN locale ad attacchi di mancato recapito in cui un host dannoso su Internet invia traffico alla VCN locale che sembra provenire dalla VCN di cui si sta eseguendo il peering. Per evitare questo problema, come accennato in precedenza, utilizzare le liste di sicurezza per limitare attentamente il traffico in entrata dall'altra VCN al traffico previsto e definito.