Accesso ad altri VCN: peering
Il peering VCN è il processo di connessione di più reti cloud virtuali (VCN, Virtual Cloud Network). Sono disponibili quattro tipi di peering VCN:
- Peing VCN locale (all'interno di un'area) utilizzando LPG
- Peering VCN remoto (in più aree) utilizzando RPC
- Peering VCN locale tramite un DRG aggiornato
- Peering VCN remoto tramite un DRG aggiornato
Puoi utilizzare il peering VCN per dividere la tua rete in più VCN (ad esempio, in base ai reparti o alle linee di business), con ogni VCN che ha accesso diretto e privato alle altre. Non è necessario che il traffico fluisca su Internet o attraverso la rete on premise tramite una VPN site-to-site o FastConnect. Puoi anche inserire risorse condivise in una singola VCN a cui tutte le altre VCN possono accedere in privato.
Ogni VCN può avere fino a 10 gateway di peering locali e può collegarsi a un solo DRG. Un singolo DRG supporta fino a 300 collegamenti VCN, consentendo il flusso del traffico tra di essi secondo quanto indicato dalle tabelle di instradamento del DRG. Si consiglia di utilizzare il gateway DRG se è necessario eseguire il peer con un numero elevato di VCN. Se desideri una larghezza di banda estremamente elevata e un 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 una maggiore flessibilità nell'instradamento a causa del maggior numero di collegamenti.
Poiché il peering VCN remoto attraversa aree, puoi utilizzarlo (ad esempio) per eseguire il mirroring o il backup dei database da un'area all'altra.
Panoramica del peering VCN locale
Il peering VCN locale è il processo di connessione di due VCN nella stessa area in modo che le relative risorse possano comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet o attraverso la rete on premise. I VCN possono trovarsi nella stessa tenancy di Oracle Cloud Infrastructure o in altri ambienti. Senza il peering, una determinata VCN avrebbe bisogno di un gateway Internet e indirizzi IP pubblici per le istanze che devono comunicare con un'altra VCN.
Il peering VCN locale tramite un DRG aggiornato ti offre una maggiore flessibilità nell'instradamento e nella gestione semplificata, ma comporta il costo di un aumento della latenza (di microsecondi) dovuto all'instradamento del traffico tramite 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:
- Chi può sottoscrivere la tenancy in un'altra area (obbligatorio per il peering VCN remoto)
- Chi nell'organizzazione ha l'autorità di stabilire i peer VCN (ad esempio, vedere i criteri IAM in Impostazione di un peering locale e Impostazione di un peering remoto). L'eliminazione di questi criteri IAM non influisce sui peer esistenti, ma solo sulla possibilità di creare peer futuri.
- Chi può gestire le tabelle di instradamento e gli elenchi di sicurezza
Controllo del flusso di traffico sulla connessione
Anche se è stata stabilita una connessione di peering tra la VCN e un'altra, è possibile controllare il flusso di pacchetti tramite la connessione con le tabelle di instradamento nella VCN. Ad esempio, puoi limitare il traffico solo a subnet specifiche nell'altra VCN.
Senza arrestare il peering, puoi arrestare il flusso di traffico verso l'altra VCN semplicemente rimuovendo le regole di instradamento che indirizzano il traffico dalla tua VCN all'altra VCN. Puoi anche interrompere il traffico in modo efficace rimuovendo qualsiasi regola della lista di sicurezza che abilita il traffico in entrata o in uscita con l'altra VCN. Ciò non impedisce il flusso di traffico sulla connessione di peering, ma la 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:
- Importanti concetti di peering locale
- Task E: configurare le tabelle di instradamento
- Task F: Configurare le regole di sicurezza
Peering VCN remoto utilizzando una connessione peering remoto:
- Concetti importanti del peering remoto
- Task E: configurare le tabelle di instradamento
- Task F: Configurare le regole di sicurezza
Peering VCN locale mediante un gateway di instradamento dinamico (DRG):
- Importanti concetti di peering locale
- Task D: configurare le tabelle di instradamento nella VCN-A per inviare il traffico destinato al CIDR della VCN-B al collegamento DRG
- Task E: configurare le tabelle di instradamento nella rete VCN-B per inviare il traffico destinato alla rete VCN-A sul collegamento DRG
- Task F: Aggiorna regole di sicurezza
Peering VCN remoto mediante un gateway di instradamento dinamico (DRG):
Controllo dei tipi specifici di traffico consentiti
È importante che ogni amministratore VCN garantisca che tutto il traffico in uscita e in entrata con l'altra VCN sia inteso o previsto e ben definito. In pratica, ciò significa implementare regole della lista di sicurezza che specificano in modo esplicito i tipi di traffico che la VCN può inviare all'altra e accettare dall'altra.
Le istanze che eseguono immagini della piattaforma dispongono anche di regole 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 agli elenchi di sicurezza e ai firewall, dovresti valutare altre configurazioni basate sul sistema operativo nelle istanze nella tua VCN. Potrebbero essere disponibili configurazioni predefinite che non si applicano al CIDR della tua VCN, ma che si applicano inavvertitamente al CIDR dell'altra VCN.
Utilizzo delle regole dell'elenco di sicurezza predefinite
Se le subnet della VCN utilizzano la lista di sicurezza predefinita con le regole predefinite in essa contenute, tenere presente che esistono due regole che consentono il traffico in entrata da qualsiasi posizione (ovvero, 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 mantenerle o aggiornarle. Come affermato in precedenza, assicurati che tutto il traffico in entrata o in uscita consentito sia previsto/previsto e ben definito.
Prepararsi all'impatto sulle prestazioni e ai rischi per la sicurezza
In generale, prepara la tua VCN per le modalità in cui potrebbe essere interessata dall'altra VCN. Ad esempio, il carico sulla tua VCN o sulle sue istanze potrebbe aumentare. In alternativa, la tua VCN potrebbe subire un attacco dannoso direttamente da o tramite l'altra VCN.
Per quanto riguarda le prestazioni: se la tua VCN fornisce un servizio a un'altra, preparati a eseguire lo scale-up del tuo servizio per soddisfare le esigenze dell'altra VCN. Ciò potrebbe significare essere pronti ad avviare più istanze, se necessario. In alternativa, se sei preoccupato per gli elevati livelli di traffico di rete che arrivano alla tua rete VCN, prendi in considerazione l'utilizzo di regole della lista di sicurezza senza conservazione dello stato per limitare il livello di monitoraggio della connessione che la tua VCN deve eseguire. Le regole delle liste di sicurezza senza conservazione dello stato possono anche contribuire a rallentare l'impatto di un attacco di tipo Denial of Service (DoS).
Per quanto riguarda i rischi per la sicurezza: non puoi necessariamente controllare se l'altra VCN è connessa a Internet. In tal caso, la tua rete VCN può essere esposta ad attacchi di mancato recapito in cui un host malintenzionato su Internet può inviare traffico alla tua rete VCN, ma farla apparire come se provenisse dalla rete VCN di cui si è eseguito il peering. Per evitare questo problema, come accennato in precedenza, utilizza le liste di sicurezza per limitare attentamente il traffico in entrata dall'altra VCN al traffico previsto e ben definito.