Peering VCN remoto mediante un DRG legacy
Questo argomento riguarda il peering VCN remoto. In questo caso, remoto indica che le reti VCN risiedono in aree diverse. Se le reti VCN che si desidera connettere si trovano nella stessa area, vedere Peering VCN locale mediante Local Peering Gateway.
Questo articolo si riferisce in modo specifico all'uso di un DRG precedente. Le informazioni contenute in Peering VCN remoto tramite un DRG aggiornato utilizzando un DRG aggiornato sono il suggerimento corrente di Oracle. Per un'analisi dettagliata delle possibili versioni del DRG, vedere Versioni DRG.
Panoramica del peering VCN remoto
Il peering VCN remoto è il processo di connessione di due VCN in aree diverse (ma la stessa tenancy ). Il peering consente alle risorse VCN di comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet o attraverso la rete on premise. 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 in un'altra area.
Riepilogo dei componenti di networking per il peering remoto
Ad un livello elevato, i componenti del servizio di networking necessari per un peering remoto includono:
-
Due VCN con CIDR non sovrapposti, in aree diverse che supportano il peering remoto.
Nota
Tutti i CIDR VCN non devono sovrapporsi
I due VCN nella relazione di peering non devono avere CIDR sovrapposti. Inoltre, se una determinata VCN dispone di più relazioni di peering, le altre VCN non devono avere CIDR sovrapposti tra loro. Ad esempio, se la rete VCN-1 è sottoposta a peering con VCN-2 e anche con VCN-3, la rete VCN-2 e la rete VCN-3 non devono avere CIDR sovrapposti.
- Un gateway di instradamento dinamico (DRG) collegato a ogni VCN nella relazione di peering. La VCN dispone già di un DRG se si utilizza un tunnel IPSec VPN site-to-site o un circuito virtuale privato Oracle Cloud Infrastructure FastConnect.
- Una connessione peering remoto (RPC) su ogni DRG nella relazione peering.
- Una connessione tra questi due RPC.
- Supporto delle regole di instradamento per consentire il flusso del traffico sulla connessione e solo verso e da subnet selezionate nelle rispettive VCN (se lo si desidera).
- Supporto di regole di sicurezza per controllare i tipi di traffico consentiti verso e dalle istanze nelle subnet che devono comunicare con l'altra VCN.
Il seguente diagramma descrive i componenti.
Una determinata VCN può utilizzare gli RPC connessi per raggiungere solo le VNIC nell'altra VCN o nella rete on premise e non le destinazioni al di fuori delle VCN come Internet. Ad esempio, se la VCN-1 nel diagramma precedente dovesse disporre di un gateway Internet, le istanze della VCN-2 NON potrebbero utilizzarla per inviare traffico agli endpoint su Internet. Per ulteriori informazioni, vedere Implicazioni importanti del peering.
Spoke-to-Spoke: peering remoto con instradamento del transito
Lo scenario menzionato in questa sezione è ancora supportato, ma non è più valido. Oracle consiglia di utilizzare il metodo di instradamento del transito DRG descritto nella sezione Instradamento del traffico tramite un'appliance virtuale di rete centrale.
Immaginate di avere in ogni regione più VCN in un layout hub-and-spoke, come mostrato nel seguente diagramma. Questo tipo di layout all'interno di un'area viene descritto in dettaglio nella sezione Instradamento transito all'interno di una VCN hub. Le VCN spoke in una determinata area sono peering locale con la VCN hub nella stessa area, utilizzando i peering gateway locali .
È possibile impostare il peering remoto tra le due VCN hub. Successivamente, puoi anche impostare l'instradamento del transito per il DRG e i GPL della VCN hub, come descritto nella sezione Instradamento del transito all'interno di una VCN hub. Questa impostazione consente a una VCN spoke in una region di comunicare con una o più VCN spoke nell'altra region senza dover disporre di una connessione peering remoto direttamente tra tali VCN.
Ad esempio, puoi configurare l'instradamento in modo che le risorse nella rete VCN-1-A possano comunicare con le risorse nella rete VCN-2-A e nella rete VCN-2-B tramite le reti VCN dell'hub. In questo modo, non è necessario che la VCN 1-A disponga di un peering remoto separato con ciascuna VCN spoke nell'altra area. Puoi anche impostare l'instradamento in modo che la rete VCN-1-B possa comunicare con le reti VCN spoke nella regione 2, senza dover disporre dei propri peer remoti.
Accordo esplicito richiesto da entrambi i lati
Il peering tra due VCN richiede l'accordo esplicito di entrambe le parti sotto forma di criteri di Oracle Cloud Infrastructure Identity and Access Management che ciascuna parte implementa per il proprio compartimento della VCN.
Concetti importanti del peering remoto
I concetti riportati di seguito consentono di comprendere le nozioni di base del peering e di stabilire un peering remoto.
- PEERING
- Un peering è una singola relazione di peering tra due VCN. Esempio: se i peer VCN-1 con altre due VCN, esistono due peer. La parte remota del peering remoto indica che le reti VCN si trovano in aree diverse.
- AMMINISTRATORI VCN
- In generale, il peering VCN può verificarsi solo se entrambi gli amministratori della VCN lo accettano. In pratica, ciò significa che i due amministratori devono:
- ACCETTATORE E RICHIEDENTE
- Per implementare i criteri IAM necessari per il peering, i due amministratori della VCN devono designare un amministratore come richiedente e l'altro come accettore. Il richiedente deve essere quello per avviare la richiesta di connessione dei due RPC. A sua volta, l'accettante deve creare un determinato criterio IAM che conceda al richiedente l'autorizzazione a connettersi agli RPC nel compartimento dell'accettante. Senza tale criterio, la richiesta di connessione del richiedente non riesce.
- SOTTOSCRIZIONE AREA
- Per eseguire il peer con una VCN in un'altra area, è necessario prima eseguire la sottoscrizione della tenancy a tale area. Per informazioni sulla sottoscrizione, vedere Gestione delle aree.
- CONNESSIONE PEERING REMOTO (RPC)
- Una connessione RPC (remote peering connection) è un componente creato nel gateway DRG collegato alla VCN in uso. Il job dell'RPC consiste nell'agire come punto di connessione per una VCN con peering remoto. Nell'ambito della configurazione delle reti VCN, ogni amministratore deve creare un RPC per il gateway DRG sulla propria rete VCN. Un determinato DRG deve disporre di un RPC separato per ogni peering remoto stabilito per la VCN. Per continuare con l'esempio precedente: il DRG sulla VCN-1 avrebbe due RPC da eseguire il peer con altre due VCN. Nell'API, RemotePeeringConnection è un oggetto che contiene informazioni sul peering. Impossibile riutilizzare un RPC per stabilire successivamente un altro peering con esso.
- CONNESSIONE TRA DUE RPCS
- Quando il richiedente avvia la richiesta di peer (nella console o nell'API), chiede effettivamente di connettere i due RPC. Ciò significa che il richiedente deve disporre di informazioni per identificare ogni RPC (ad esempio, l'area dell'RPC e OCID ).
- INSTRADAMENTO AL DRG
- Nell'ambito della configurazione delle VCN, ogni amministratore deve aggiornare l'instradamento della VCN per consentire il flusso del traffico tra le VCN. Per ogni subnet che deve comunicare con l'altra VCN, devi aggiornare la tabella di instradamento della subnet. La regola di instradamento specifica il CIDR del traffico di destinazione e il DRG come destinazione. Il tuo DRG instrada il traffico che corrisponde a tale regola all'altro DRG, che a sua volta instrada il traffico all'hop successivo nell'altra VCN.
-
Callout 3: Tabella di instradamento subnet A CIDR di destinazione Destinazione instradamento 0.0.0.0/0 Gateway Internet 192.168.0.0/16 DRG-1 Callout 4: Tabella di instradamento X subnet CIDR di destinazione Destinazione instradamento 10.0.0.0/16 DRG-2 - REGOLE DI SICUREZZA
- Ogni subnet in una VCN dispone di uno o più elenchi di sicurezza che controllano il traffico in entrata e in uscita dalle VNIC della subnet a livello di pacchetto. È possibile utilizzare gli elenchi di sicurezza per controllare il tipo di traffico consentito con l'altra VCN. Nell'ambito della configurazione delle VCN, ogni amministratore deve determinare quali subnet nella propria VCN devono comunicare con le VNIC nell'altra VCN e aggiornare di conseguenza gli elenchi di sicurezza della subnet.
Importanti implicazioni del peering
Se non lo si è ancora fatto, leggere Implicazioni importanti del peering per comprendere importanti implicazioni relative al controllo dell'accesso, alla sicurezza e alle prestazioni per le VCN sottoposte a peering.
Impostazione di un peering remoto
In questa sezione viene descritto il processo generale per l'impostazione di un peering tra due VCN in aree diverse.
Per la procedura seguente si presuppone che:
- La tenancy è sottoscritta all'altra area della VCN. In caso contrario, vedere Gestione delle aree.
- Hai già un DRG collegato alla tua VCN. In caso contrario, vedere Gateway di instradamento dinamico.
- Crea gli RPC: ogni amministratore della VCN crea un RPC per il DRG della propria VCN.
- Condividi informazioni: gli amministratori condividono le informazioni di base necessarie.
- Impostare i criteri IAM necessari per la connessione: gli amministratori impostano i criteri IAM per abilitare la connessione da stabilire.
- Stabilire la connessione: il richiedente connette i due RPC (vedere Concetti di peering remoto importanti per la definizione del richiedente e dell'accettore).
- Aggiorna tabelle di instradamento: ogni amministratore aggiorna le tabelle di instradamento della propria VCN in modo da abilitare il traffico tra le VCN sottoposte a peering in base alle esigenze.
- Aggiorna regole di sicurezza: ogni amministratore aggiorna le regole di sicurezza della propria VCN per abilitare il traffico tra le VCN sottoposte a peering in base alle esigenze.
Se lo si desidera, gli amministratori possono eseguire i task E e F prima di stabilire la connessione. Ogni amministratore deve conoscere il blocco CIDR o subnet specifiche della VCN dell'altra e condividerle nel task B.
Ogni amministratore crea un RPC per il gateway DRG della propria VCN. Per "utente corrente" si intende un amministratore (accettore o richiedente).
Criteri IAM necessari per creare RPC
Se gli amministratori dispongono già di autorizzazioni di amministratore di rete generiche (vedere Consenti agli amministratori di rete di gestire una rete cloud), dispongono dell'autorizzazione per creare, aggiornare ed eliminare gli RPC. In caso contrario, ecco un criterio di esempio che fornisce le autorizzazioni necessarie a un gruppo denominato RPCAdmins. La seconda istruzione è necessaria perché la creazione di un RPC influisce sul DRG a cui appartiene, pertanto l'amministratore deve disporre dell'autorizzazione per gestire i DRG.
Allow group RPCAdmins to manage remote-peering-connections in tenancy
Allow group RPCAdmins to manage drgs in tenancy
- Nella console, confermare che si sta visualizzando il compartimento contenente il DRG a cui si desidera aggiungere l'RPC. Per informazioni sui compartimenti e sul controllo dell'accesso, vedere Controllo dell'accesso.
- Aprire il menu di navigazione e selezionare Networking. In Connettività cliente, selezionare Gateway di instradamento dinamico.
- Fare clic sul DRG a cui si è interessati.
- In Risorse fare clic su Connessioni peering remoto.
- Fare clic su Crea connessione peering remoto.
-
Immettere quanto riportato di seguito.
- Nome: un nome descrittivo per l'RPC. Non deve essere univoco e non può essere modificato in seguito nella console (ma è possibile modificarlo con l'API). Evitare di inserire informazioni riservate.
- Crea nel compartimento: il compartimento in cui si desidera creare l'RPC, se diverso dal compartimento in cui si sta attualmente lavorando.
-
Fare clic su Crea connessione peering remoto.
L'RPC viene quindi creato e visualizzato nella pagina Connessioni peering remoto del compartimento scelto.
- Se sei il programma di accettazione, registra l'area e l'OCID dell'RPC da fornire in un secondo momento al richiedente.
Quando entrambi i VCN si trovano nella stessa tenancy ma in aree diverse, utilizzare i criteri forniti in Peering remoto con un DRG legacy.
Se entrambi i VCN si trovano in tenancy diverse ma nella stessa area, utilizzare i criteri forniti in Collegamento a VCN in altre tenancy.
Il richiedente deve eseguire questo task.
Prerequisito: il richiedente deve avere:
- Area in cui si trova la VCN del richiedente (la tenancy del richiedente deve essere sottoscritta all'area).
- OCID dell'RPC del programma di accettazione.
- Nella console visualizzare i dettagli relativi all'RPC del richiedente che si desidera connettere all'RPC del programma di accettazione.
- Fare clic su Stabilisci connessione.
-
Immettere quanto riportato di seguito.
- Area: l'area che contiene la VCN dell'accettante. L'elenco a discesa include solo le aree a cui è stata eseguita la sottoscrizione sia per il peering VCN remoto che per la tenancy in uso.
- OCID connessione al peering remoto: l'OCID dell'RPC del programma di accettazione.
-
Fare clic su Stabilisci connessione.
La connessione viene stabilita e lo stato dell'RPC cambia in PEERED.
Come accennato in precedenza, ogni amministratore può eseguire questo task prima o dopo la creazione della connessione.
Prerequisito: ogni amministratore deve disporre del blocco CIDR o di subnet specifiche per l'altra VCN.
Per la tua VCN:
- Determina quali subnet nella tua VCN devono comunicare con l'altra VCN.
-
Aggiornare la tabella di instradamento per ciascuna subnet in modo da includere una nuova regola che indirizza il traffico destinato per l'altra VCN al gateway DRG:
- Aprire il menu di navigazione , selezionare Networking, quindi selezionare Reti cloud virtuali.
- Fare clic sulla VCN a cui si è interessati.
- In Risorse fare clic su Tabelle di instradamento.
- Fare clic sulla tabella di instradamento a cui si è interessati.
-
Fare clic su Aggiungi regola di instradamento e immettere le informazioni seguenti.
- Tipo di destinazione: gateway di instradamento dinamico. Il gateway DRG collegato della VCN viene selezionato automaticamente come destinazione e non è necessario specificare manualmente la destinazione.
- Blocco CIDR di destinazione: il blocco CIDR dell'altra VCN. Se lo desideri, puoi specificare una subnet o un subset specifico del CIDR della VCN in peer.
- Descrizione: una descrizione facoltativa della regola.
- Fare clic su Add Route Rule.
Qualsiasi traffico della subnet con una destinazione che corrisponde alla regola viene instradato al gateway DRG in uso. Per ulteriori informazioni sull'impostazione delle regole di instradamento, consulta le tabelle di instradamento VCN.
Senza l'instradamento richiesto, il traffico non scorre tra i DRG sottoposti a peering. Se si verifica una situazione in cui è necessario arrestare temporaneamente il peering, è sufficiente rimuovere le regole di instradamento che abilitano il traffico. Non è necessario eliminare gli RPC.
Come accennato in precedenza, ogni amministratore può eseguire questo task prima o dopo la creazione della connessione.
Prerequisito: ogni amministratore deve disporre del blocco CIDR o di subnet specifiche per l'altra VCN. In generale, è consigliabile utilizzare lo stesso blocco CIDR utilizzato nella regola della tabella di instradamento in Task E: Configurare le tabelle di instradamento.
Quali regole aggiungere?
- Regole di entrata per i tipi di traffico che si desidera consentire dall'altra VCN, in particolare dal CIDR della VCN o da subnet specifiche.
- Regola di uscita per consentire il traffico in uscita dalla VCN all'altra VCN. Se la subnet dispone già di una regola di uscita estesa per tutti i tipi di protocolli a tutte le destinazioni (0.0.0.0/0), non è necessario aggiungere una regola speciale per l'altra VCN.
La procedura riportata di seguito utilizza liste di sicurezza, ma è possibile implementare le regole di sicurezza in un gruppo di sicurezza di rete, quindi creare tutte le risorse della sottorete in tale gruppo NSG.
Per la tua VCN:
- Determina quali subnet nella tua VCN devono comunicare con l'altra VCN.
-
Aggiornare la lista di sicurezza per ciascuna subnet in modo da includere regole che consentano il traffico in uscita o in entrata desiderato, in particolare con il blocco CIDR o la subnet dell'altra VCN:
- Nella console, durante la visualizzazione della VCN di interesse, fare clic su Elenchi di sicurezza.
- Fare clic sulla lista di sicurezza a cui si è interessati.
- In Risorse, fare clic su Regole di entrata o Regole di uscita a seconda del tipo di regola che si desidera utilizzare.
-
Se si desidera aggiungere una nuova regola, fare clic su Aggiungi regola di entrata (o su Aggiungi regola di uscita).
- Se si desidera eliminare una regola esistente, fare clic sul menu Azioni
e quindi su Rimuovi. - Se si desidera modificare una regola esistente, fare clic sul menu Azioni , quindi su Modifica.
Per ulteriori informazioni sulle regole di sicurezza, vedere Regole di sicurezza.
Si supponga di voler aggiungere una regola con conservazione dello stato che abilita il traffico HTTPS in entrata (porta 443) dal CIDR dell'altra VCN. Di seguito sono riportati i passi di base da eseguire quando si aggiunge una regola.
- Nella sezione Consenti regole per entrata fare clic su +Add Regola.
- Lasciare deselezionata la casella di controllo senza conservazione dello stato.
- Tipo di origine: lasciare come CIDR.
- CIDR di origine: immettere lo stesso blocco CIDR utilizzato dalle regole di instradamento (vedere Task E: Configurare le tabelle di instradamento).
- Protocollo IP: lasciare come TCP.
- Intervallo porte di origine: lasciare tutto.
- Intervallo di porte di destinazione: immettere 443.
- Descrizione: una descrizione facoltativa della regola.
Utilizzo di Console
Vedere le istruzioni in Task A: Creare gli RPC.
L'eliminazione di un RPC interrompe il peering. L'RPC sull'altro lato del peering passa allo stato REVOKED.
- Aprire il menu di navigazione e selezionare Networking. In Connettività cliente, selezionare Gateway di instradamento dinamico.
- Fare clic sul DRG a cui si è interessati.
- In Risorse fare clic su Connessioni peering remoto.
- Clicca sull'RPC a cui sei interessato.
- Fare clic su Cessa.
- Confermare quando richiesto.
Dopo aver eliminato un RPC e aver terminato un peering, si consiglia di rivedere le tabelle di instradamento e le regole di sicurezza per rimuovere le regole che hanno abilitato il traffico con l'altra VCN.