Peering VCN remoto tramite un DRG aggiornato
Questo argomento riguarda il peering VCN remoto.
In questo caso, remote indica che le reti cloud virtuali (VCN) sono collegate a un gateway di instradamento dinamico (DRG) diverso e che il DRG può risiedere in un'area diversa o, eventualmente, nella stessa area. Se le reti VCN che si desidera connettere si trovano nella stessa area e sono connesse allo stesso DRG, vedere Peering VCN locale tramite un DRG aggiornato.
Questo scenario è disponibile per un DRG aggiornato o legacy, con l'eccezione che i DRG legacy non supportano la connessione dei DRG in tenancy diverse o il collegamento di più VCN. Per informazioni dettagliate sulle versioni DRG, vedere Versioni DRG.
Prima di implementare questo scenario, assicurarsi che:
- La VCN A è collegata al gateway DRG A
- La VCN B è collegata al gateway DRG B
- La configurazione di instradamento in entrambi i DRG utilizza le tabelle di instradamento predefinite
- Le autorizzazioni IAM appropriate vengono applicate per le VCN che si trovano nella stessa tenancy o in tenancy diverse
Panoramica del peering VCN remoto
Il peering VCN remoto è il processo di connessione di due VCN in aree diverse. Il peering consente alle risorse delle VCN di comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet o attraverso una rete on-premise. I VCN possono trovarsi nella stessa tenancy di Oracle Cloud Infrastructure o in una diversa. Senza il peering, una VCN avrebbe bisogno di un gateway Internet e di indirizzi IP pubblici per le istanze che devono comunicare con un'altra VCN in un'area diversa.
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 che non si sovrappongono, in aree diverse.
Nota
Nessun CIDR VCN può sovrapporsi
Le due reti VCN nella relazione di peering non possono avere CIDR sovrapposti. Inoltre, se una particolare VCN dispone di diverse relazioni di peering, le altre VCN non possono avere CIDR che si sovrappongono tra loro. Ad esempio, se la VCN-1 viene gestita in peering con la VCN-2 e anche la VCN-3, la VCN-2 e la VCN-3 non devono avere CIDR sovrapposti.
Se si sta configurando questo scenario, è necessario soddisfare questo requisito nella fase di pianificazione. È probabile che si verifichino problemi di instradamento quando si verificano CIDR sovrapposti, ma non viene impedito dalle operazioni della console o dell'API di creare una configurazione che causi problemi.
- Gateway di instradamento dinamico (DRG) collegato a ciascuna VCN nella relazione di peering. Una VCN dispone già di un DRG se si utilizza un tunnel IPSec VPN da sito a sito 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 desiderato).
- 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 VCN può utilizzare le RPC connesse solo per raggiungere le VNIC nell'altra VCN o una rete in locale se il DRG dispone di una connessione in locale. Ad esempio, se la VCN-1 nel diagramma precedente disponeva di un gateway Internet, le istanze nella VCN-2 non potrebbero utilizzarla per inviare traffico agli endpoint su Internet. Per ulteriori informazioni, vedere Implicazioni importanti del peering.
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.
Le VCN di peering in tenancy diverse presentano alcune complicazioni delle autorizzazioni che devono essere risolte in entrambe le tenancy. Per i dettagli sulle autorizzazioni necessarie, vedere Criteri IAM per l'instradamento tra VCN.
spoke-to-supoke: peering remoto con instradamento transito (solo DRG precedenti)
Lo scenario menzionato in questa sezione è ancora supportato, ma si consiglia di utilizzare il metodo di instradamento del transito DRG descritto in Instradamento del traffico attraverso un'appliance virtuale di rete centrale.
Immagina di avere diverse reti VCN in un layout hub-and-spoke, come mostrato nel diagramma seguente. Questo tipo di layout all'interno di un'area viene descritto in dettaglio in Instradamento del transito all'interno di una VCN hub. Le reti VCN spoke in un'area vengono sottoposte a peering locale con la VCN hub nella stessa area, utilizzando i gateway peering locale .
È possibile impostare il peering remoto tra le due reti VCN hub. È inoltre possibile impostare l'instradamento del transito per i gateway DRG e LPG della VCN hub, come descritto in Instradamento del transito all'interno di una VCN hub. Questa impostazione consente a una VCN spoke in un'area di comunicare con una o più VCN spoke nell'altra area senza aver bisogno 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 hub. In questo modo, alla VCN 1-A non è richiesto di avere 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 nell'area 2, senza aver bisogno di peer remoti personalizzati.
spoke fino allo spoke: peering remoto con instradamento transito (DRG aggiornato)
Lo scenario in questa sezione utilizza il metodo di instradamento del transito DRG descritto in Instradamento del traffico tramite un'appliance virtuale di rete centrale.
Immagina di avere diverse reti VCN in un layout hub-and-spoke, come mostrato nel diagramma seguente. Questo tipo di layout all'interno di un'area viene descritto in dettaglio in Instradamento del transito all'interno di una VCN hub. Le reti VCN spoke nell'area vengono peered a livello locale con la coppia DRG/VCN hub nella stessa area mediante connessione reciproca al DRG.
È possibile impostare il peering remoto tra due reti VCN hub. Puoi anche impostare l'instradamento del transito per il gateway DRG della VCN hub, come descritto in Instradamento del traffico attraverso un'appliance virtuale di rete centrale. Questa impostazione consente a una VCN spoke in un'area di comunicare con una o più VCN spoke nell'altra area senza aver bisogno 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 hub. In questo modo, alla VCN 1-A non è richiesto di avere 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 nell'area 2, senza aver bisogno di peer remoti personalizzati.
Concetti importanti del peering remoto
I concetti riportati di seguito consentono di comprendere le nozioni di base del peering VCN e di stabilire un peering remoto.
- PEERING
- Un peering è una singola relazione di peering tra due VCN. Esempio: se esistono 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. Per questo metodo di peering remoto, le reti VCN possono trovarsi nella stessa tenancy o in tenancy diverse.
- AMMINISTRATORI VCN
- In generale, il peering VCN può verificarsi solo se entrambi gli amministratori della VCN lo accettano. In pratica, i due amministratori devono:
- ACCETTATORE E RICHIEDENTE
- Per implementare i criteri IAM necessari per il peering, i due amministratori della VCN devono selezionare 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, il responsabile accettazione deve creare un criterio IAM specifico che concede al richiedente l'autorizzazione per connettersi a RPC nel compartimento del responsabile accettazione. In assenza di tale criterio, la richiesta di connessione del richiedente non riesce.
- SOTTOSCRIZIONE AREA
- Per eseguire il peer con una VCN in un'altra area, una tenancy deve prima essere sottoscritta a tale area. Per informazioni sulla sottoscrizione, vedere Gestione delle aree.
- CONNESSIONE PEERING REMOTO (RPC)
- Una connessione peering remoto (RPC) è un componente creato nel DRG collegato alla VCN. Il compito dell'RPC consiste nell' fungere da punto di connessione per una VCN gestita in peering remoto. Nell'ambito della configurazione delle reti VCN, ciascun amministratore deve creare un RPC per il DRG nella propria VCN. Un DRG deve disporre di un RPC separato per ogni peering remoto stabilito per la VCN. Per continuare con l'esempio precedente: il DRG nella VCN-1 avrebbe due RPC di cui eseguire il peer con altre due VCN. Nell'API, RemotePeeringConnection è un oggetto che contiene informazioni sul peering. Non è possibile riutilizzare un RPC per stabilire 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. Il richiedente deve disporre di informazioni per identificare ogni RPC (ad esempio l'area RPC e l'OCID ).
- INSTRADAMENTO AL DRG
- Nell'ambito della configurazione delle reti VCN, ogni amministratore deve aggiornare l'instradamento della VCN per consentire il flusso di traffico tra le reti VCN. Per ogni subnet che deve comunicare con l'altra VCN, aggiorna la tabella di instradamento della subnet. La regola di instradamento specifica il CIDR del traffico di destinazione e il DRG come destinazione. Il gateway 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 1: 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 2: 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 una o più liste di sicurezza che controllano il traffico in entrata e in uscita dalle VNIC della subnet a livello di pacchetto. Puoi utilizzare le liste di sicurezza per controllare il tipo di traffico consentito con le altre VCN. Nell'ambito della configurazione delle reti VCN, ogni amministratore deve decidere quali subnet nella propria VCN devono comunicare con le VNIC nell'altra VCN e aggiornare in modo appropriato le liste di sicurezza della propria 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 del peering remoto
In questa sezione viene illustrato il processo generale di impostazione del peering tra due reti VCN in aree diverse.
Per la procedura seguente si presuppone che:
- La tenancy è sottoscritta all'area dell'altra VCN. In caso contrario, vedere Gestione delle aree.
- È già presente una VCN collegata al gateway DRG. In caso contrario, vedere Gateway di instradamento dinamico.
- Sono già stati impostati i criteri IAM necessari per la connessione. I criteri IAM per il peering remoto nella stessa tenancy e tra le tenancy sono diversi. Vedere Criteri IAM per l'instradamento tra VCN
Panoramica dei passi necessari:
- 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.
- 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 come previsto.
- Aggiorna regole di sicurezza: ogni amministratore aggiorna le regole di sicurezza della propria VCN per abilitare il traffico tra le VCN sottoposte a peering come previsto.
Se lo si desidera, gli amministratori possono eseguire i task 4 e 5 prima di stabilire la connessione. Ogni amministratore deve conoscere il blocco CIDR o subnet specifiche della VCN dell'altra e condividerle nel task 2.
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.
- Selezionare il DRG a cui si è interessati.
- In Risorse, selezionare Allegati connessioni peering remoto.
- Selezionare Crea connessione peering remoto.
-
Immettere quanto riportato di seguito.
- Nome: un nome descrittivo per RPC. Non deve essere univoco e non può essere modificato in un secondo momento nella console (ma puoi modificarlo con l'API). Evitare di fornire informazioni riservate.
- Crea nel compartimento: il compartimento in cui si desidera creare l'RPC, se diverso dal compartimento in cui si sta lavorando.
-
Selezionare 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.
- Se le due VCN si trovano in tenancy diverse, registrare l'OCID di questa tenancy (che si trova nella parte inferiore della pagina nella console). Fornire l'OCID all'altro amministratore in un secondo momento.
Questo task è specifico di una connessione cross-tenancy. Se la connessione si trova nella stessa tenancy, è possibile passare al task successivo.
-
Se sei l'accettante, fornisci queste informazioni al richiedente (ad esempio, via e-mail o altro metodo fuori banda):
- Area in cui si trova la VCN (la tenancy del richiedente deve essere sottoscritta a quest'area).
- OCID dell'RPC.
- I blocchi CIDR per le subnet nella VCN che si desidera siano disponibili per le altre VCN. Il richiedente ha bisogno di queste informazioni durante l'impostazione dell'instradamento per la VCN del richiedente.
- Se le VCN si trovano in tenancy diverse: l'OCID per la tenancy del responsabile accettazione.
-
Se sei il richiedente, fornisci queste informazioni all'accettante:
- Area in cui si trova la VCN (la tenancy del richiedente deve essere sottoscritta a quest'area).
- Se le VCN si trovano nella stessa tenancy: il nome del gruppo IAM ha concesso l'autorizzazione per creare una connessione nel compartimento del responsabile accettazione.
- Se le VCN si trovano in tenancy diverse: l'OCID per la tenancy del richiedente.
- I blocchi CIDR per le subnet nella VCN che si desidera siano disponibili per le altre VCN. Il responsabile dell'accettazione richiede queste informazioni durante l'impostazione dell'instradamento per la VCN del responsabile dell'accettazione.
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.
- OCID della tenancy del responsabile accettazione (solo se la VCN del responsabile accettazione si trova in una tenancy diversa)
Vedere le istruzioni in Connessione di due connessioni peering remoto. In Gestione peering remoto sono illustrati altri task che coinvolgono RPC.
Come accennato in precedenza, ogni amministratore può eseguire questo task prima o dopo la creazione della connessione.
Prerequisito: ogni amministratore deve conoscere il blocco CIDR o subnet specifiche per l'altra VCN.
Per ogni VCN, decidere quali subnet della VCN locale devono comunicare con le altre VCN. Quindi, aggiornare la tabella di instradamento per ciascuna di tali subnet in modo da includere una nuova regola che indirizza il traffico destinato per l'altra VCN al DRG locale. Vedere Aggiornamento delle regole di una tabella di instradamento VCN e aggiungere una regola di instradamento che utilizzi le impostazioni riportate di seguito.
- 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. L'esempio utilizza VCN con 10.0.0.0/16 e 192.68.0.0/16. Se lo desideri, puoi specificare una subnet o un particolare subset del CIDR della VCN sottoposta a peering.
- Descrizione: una descrizione facoltativa della regola.
Qualsiasi traffico della subnet con una destinazione che corrisponde alla regola viene instradato al DRG locale. Per ulteriori informazioni sull'impostazione delle regole di instradamento, vedere Tabelle di instradamento VCN.
Senza il routing richiesto, il traffico non scorre tra i DRG sottoposti a peering. Se si verifica una situazione in cui è necessario interrompere temporaneamente il peering, è possibile 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, utilizzare lo stesso blocco CIDR utilizzato nella regola della tabella di instradamento in Task D: Configurare le tabelle di instradamento.
Si consiglia di aggiungere le seguenti regole:
- Regole di entrata per i tipi di traffico che si desidera consentire dal CIDR dell'altra VCN o da subnet specifiche. L'esempio utilizza VCN con 10.0.0.0/16 e 192.68.0.0/16.
- Regola di uscita per consentire il traffico in uscita dalla VCN locale all'altra VCN. Se la subnet dispone già di una regola di uscita estesa per tutti i tipi di protocolli per tutte le destinazioni (0.0.0.0/0), non è necessario aggiungerne una 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 le risorse della sottorete in tale gruppo NSG.
Per ogni VCN, decidere quali subnet della VCN locale devono comunicare con le altre VCN. Successivamente, aggiorna la lista di sicurezza per ciascuna di tali subnet in modo da includere regole per consentire il traffico in uscita o in entrata previsto con il blocco CIDR o la subnet dell'altra VCN. Vedere Aggiornamento delle regole in una lista di sicurezza e anche Creazione di una lista di sicurezza (per i dettagli sulle opzioni disponibili per le regole di sicurezza).
Per informazioni generali sulle regole di sicurezza, vedere Regole di sicurezza.