Nota
- Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriverti a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
- Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.
Impostare la connessione RPC tra due tenant e i relativi gateway di instradamento dinamico
Introduzione
In un ambiente Oracle Cloud Infrastructure (OCI) multi-tenant, consentire una comunicazione sicura ed efficiente tra tenant diversi è fondamentale per le architetture di rete ibride e distribuite. Un modo per raggiungere questo obiettivo è impostare una connessione RPC (Remote Peering Connection) tra due tenant e i gateway di instradamento dinamico (DRG) corrispondenti.
Obiettivi
- Configura un RPC tra due DRG in tenant OCI separati, garantendo una connettività perfetta tra le reti. Alla fine, avrai un'impostazione RPC funzionante che consente un flusso di traffico sicuro tra i tenant, aiutandoti a creare architetture multi-tenant solide in OCI.
Prerequisiti
-
Accesso a due tenant OCI: per configurare i componenti di rete, è necessario disporre delle autorizzazioni di amministratore o appropriate in entrambi i tenant OCI.
-
DRG in entrambi i tenant: ogni tenant deve disporre di un DRG già creato e collegato a una rete cloud virtuale (VCN).
-
Compatibilità delle aree: i DRG devono trovarsi nella stessa o in aree commerciali OCI diverse che supportano RPC. L'RPC tra più aree è supportato, ma entrambe le aree devono essere accessibili. Il richiedente deve essere sottoscritto all'area Accettatore.
-
Connettività pubblica o privata: decidere se consentire la comunicazione su IP privati e assicurarsi che siano pianificati i blocchi CIDR della subnet appropriati per evitare conflitti.
-
VCN e configurazione di instradamento: le VCN di entrambi i tenant devono disporre di tabelle di instradamento e liste di sicurezza configurate correttamente per consentire il traffico su RPC.
-
Criteri per il peering multi-tenant: assicurarsi che i criteri Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) siano in vigore per consentire il peering DRG tra tenant OCI diversi. Potrebbe essere necessario definire criteri per entrambi i tenant per stabilire la fiducia.
Task 1: determinazione del richiedente e del tenant accettante
In Oracle Cloud Infrastructure (OCI), quando si impostano le comunicazioni tra cloud o la condivisione delle risorse, è fondamentale definire quale tenant è il richiedente e quale è l'accettante in termini di criteri IAM OCI. Questi ruoli sono gestiti dai criteri IAM OCI, che definiscono le autorizzazioni per utenti, gruppi e compartimenti.
Definendo chiaramente i ruoli Richiedente e Accettatore all'interno dei criteri IAM OCI, assicurati che le autorizzazioni siano impostate correttamente per consentire l'accesso sicuro e controllato alle risorse tra tenant e compartimenti OCI. Entrambi i tenant devono collaborare per garantire che vengano concesse le autorizzazioni appropriate e che i criteri IAM OCI siano impostati in modo da rispettare le best practice di sicurezza.
-
Tenant richiesta: il richiedente è il tenant OCI (o un compartimento specifico all'interno di un tenant) che avvia una richiesta di accesso alle risorse da un altro tenant o compartimento OCI. I criteri IAM OCI del richiedente devono concedere le autorizzazioni necessarie per accedere alle risorse dell'accettante. Ad esempio, il richiedente potrebbe dover creare un criterio che consenta ai propri utenti di accedere a una risorsa nel tenant Accettatore.
Il richiedente deve inoltre assicurarsi che agli utenti o ai gruppi che effettuano la richiesta siano assegnati i ruoli IAM OCI corretti.
-
Tenant accettante: l'Accettante è il tenant (o compartimento) OCI che riceve la richiesta di accesso e concede le autorizzazioni necessarie al richiedente. I criteri IAM OCI dell'accettante devono definire le azioni che il richiedente può eseguire e le risorse a cui può accedere. I criteri dell'Accettante devono inoltre specificare gli utenti o i gruppi a cui è consentito accettare tali richieste, garantendo che l'accesso sia gestito in modo sicuro.
Oltre a concedere l'accesso, l'Accettante deve configurare i criteri IAM OCI per specificare le azioni che il richiedente è autorizzato a eseguire, garantendo il rispetto dell'ambito appropriato e dei principi dei privilegi minimi.
L'immagine seguente mostra un esempio di due tenant collegati tra loro con RPC in cui uno di essi è definito come Richiedente (REQ) e l'altro come Accettatore (ACC).
Task 2: sottoscrizione dell'area Accettatore all'area Richiedente
Nel contesto dell'impostazione di RPC tra due tenant OCI, il richiedente deve essere sottoscritto all'area dei tenant Acceptor, mentre non è necessario sottoscrivere l'accettazione all'area del richiedente. Ecco perché:
Perché il richiedente deve essere sottoscritto al tenant Acceptor:
-
Avvio della comunicazione: il tenant richiedente è l'entità che avvia l'RPC inviando richieste al tenant Acceptor. Per consentire questa comunicazione, il Richiedente deve essere sottoscritto all'Accettante, che gli consente di riconoscere e connettersi alla rete e ai servizi dell'Accettante.
-
Stabilire fiducia e connettività: con la sottoscrizione al tenant Acceptor, il tenant richiedente stabilisce la fiducia e la connettività necessarie per interagire con l'ambiente del Acceptor. La sottoscrizione garantisce che il richiedente possa instradare correttamente il traffico e le richieste ai servizi dell'accettante tramite la connessione peering.
Perché non è necessario sottoscrivere l'Accettante al tenant richiedente:
-
Ruolo passivo dell'accettante: il tenant dell'accettante riceve le richieste solo dal tenant del richiedente e non avvia alcuna comunicazione. Poiché l'Accettante risponde solo alle richieste del Richiedente, non è necessario sottoscrivere il Richiedente. Deve essere semplicemente accessibile e configurato per gestire le richieste in entrata.
-
Comunicazione unidirezionale: gli RPC vengono in genere impostati con un flusso di comunicazione unidirezionale in cui il richiedente è il responsabile avvio. L'Accettante non richiede una sottoscrizione al tenant richiedente, in quanto non è necessario avviare o gestire le connessioni in uscita.
In sintesi, il richiedente deve eseguire la sottoscrizione all'accettante per avviare gli RPC e stabilire la connettività, mentre l'accettante deve essere configurato solo per rispondere alle richieste e non richiede una sottoscrizione al tenant richiedente.
Nell'immagine seguente verrà visualizzato un esempio della console OCI dei richiedenti. Si noti che il richiedente è sottoscritto all'area Accettatori.
Nell'immagine seguente verrà visualizzato un esempio della console OCI Acceptors. Si noti che gli accettatori non sono sottoscritti all'area Richiedenti.
Task 3: Raccogliere i parametri richiesti
Raccogliere i parametri necessari per creare il criterio IAM OCI per il lato Richiedente e Accettatore. Di seguito è riportata la tabella che mostra i campi obbligatori nel criterio IAM OCI per i tenant Accettatore e Richiedente durante l'impostazione dell'accesso Chiamata procedura remota in OCI.
| Informazioni richieste | Tenant richiedente | Tenant accettante |
|---|---|---|
| OCID tenancy | S | S |
| Nome gruppo | S | |
| OCID gruppo | S | |
| Nome compartimento | S | S |
Prima di creare il criterio IAM OCI, assicurarsi che queste informazioni vengano raccolte da entrambe le parti.
Task 4: creare e configurare il criterio IAM OCI sul lato richiedente e Accettatore
La documentazione ufficiale sui criteri IAM OCI per rendere operativo l'RPC è disponibile qui: Peering remoto con un DRG aggiornato.
Quando analizzi i criteri, vedrai che nel criterio IAM OCI per il richiedente, sono necessarie alcune informazioni dall'accettante e, per il criterio IAM OCI dell'accettante, alcune informazioni sono richieste dal richiedente. Ciò rende a volte difficile creare i criteri e, se i criteri non sono corretti, l'RPC non verrà attivato e la risoluzione dei problemi sarà difficile.
Per risolvere questo problema, abbiamo creato lo strumento di criteri IAM RPC. Sono disponibili più architetture di rete RPC, ma lo strumento di criteri IAM RPC può essere utilizzato solo se si sta tentando di creare un RPC tra due tenant OCI diversi in cui ogni tenant dispone del proprio DRG.
Nell'immagine seguente verrà visualizzato il modulo che lo strumento di criteri IAM RPC fornirà per inserire tutti i dettagli richiesti. Il modulo richiederà ulteriori informazioni effettivamente necessarie, ma è buona norma disporre di tutte le informazioni in un'unica posizione prima di iniziare a configurare i criteri RPC e IAM OCI sul lato Accettatore e Richiedente.
Le informazioni e i parametri del richiedente sono contrassegnati con il colore rosso e le informazioni e i parametri dell'accettatore sono contrassegnati con il colore blu.
L'immagine seguente mostra un esempio di tutte le informazioni inserite. Immettere tutti i campi obbligatori e fare clic su Sottometti.
Lo strumento genererà le seguenti informazioni:
- Diagramma con i parametri utilizzati per mettere le cose in prospettiva.
- Una tabella con tutti i parametri utilizzati (in modo da poter fare uno screenshot o copiare e incollare questo nelle note per riferimento in un secondo momento).
- Il criterio IAM OCI per il richiedente.
- Il criterio IAM OCI per l'accettante.
Task 4.1: creare e configurare il criterio IAM OCI sul lato richiedente
-
Eseguire il login a OCI Console, passare a Identità e sicurezza e fare clic su Criteri.
-
Assicurarsi di selezionare il compartimento radice e fare clic su Crea criterio.
-
Immettere le informazioni riportate di seguito e fare clic su Crea.
- Immettere un nome e una descrizione per il criterio.
- Selezionare Mostra editor manuale.
- Copiare/incollare le istruzioni dei criteri per il lato Richiedente nel criterio.
Quando si crea il criterio, verranno visualizzate le istruzioni dei criteri configurate.
Quando si torna alla pagina di panoramica dei criteri, verrà visualizzato il criterio configurato.
Task 4.2: creare e configurare il criterio IAM OCI sul lato Acceptor
-
Eseguire il login a OCI Console, passare a Identità e sicurezza e fare clic su Criteri.
-
Assicurarsi di selezionare il compartimento radice e fare clic su Crea criterio.
-
Immettere le informazioni riportate di seguito e fare clic su Crea.
- Immettere un nome e una descrizione per il criterio.
- Selezionare Mostra editor manuale.
- Copiare/incollare le istruzioni dei criteri per il lato Richiedente nel criterio.
Quando si crea il criterio, verranno visualizzate le istruzioni dei criteri configurate.
Quando si torna alla panoramica dei criteri, verrà visualizzato il criterio configurato.
Task 5: configurare i collegamenti DRG nel DRG sul lato Richiedente e Accettatore
È necessario creare un RPC sul lato Richiedente e Accettatore.
Task 5.1: Crea RPC sul lato richiedente
-
Andare a OCI Console, andare a Networking e fare clic su Gateway di instradamento dinamico.
-
Fare clic su Collegamenti connessione peering remoto e su Crea connessione peering remoto.
-
Immettere il nome e fare clic su Crea connessione peering remoto.
Task 5.2: Crea RPC sul lato Accettatore
-
Andare a OCI Console, andare a Networking e fare clic su Gateway di instradamento dinamico.
-
Fare clic su Collegamenti connessione peering remoto e su Crea connessione peering remoto.
-
Immettere il nome e fare clic su Crea connessione peering remoto.
-
Raccogliere l'OCID RPC dal lato Acceptor in quanto è necessario utilizzare questo OCID per stabilire la connessione RPC dal lato Requestor.
Task 6: Stabilire la connessione dal lato richiedente
-
Andare alla console OCI dal lato richiedente, andare a Networking, Dynamic Routing Gateway e fare clic su Collegamenti di connessione peering remoto.
-
Fare clic sulla connessione di peering remoto (configurata per il lato Acceptor) creata nel task 5.
-
Fare clic su Stabilisci connessione.
-
Immettere le informazioni riportate di seguito e fare clic su Stabilisci connessione.
- Selezionare l'area dell'accettante.
- Incollare l'OCID RPC raccolto nel task 5.
Se il richiedente è sottoscritto all'area Acceptor e vengono configurati i criteri IAM OCI corretti, nonché l'infrastruttura RPC corretta, lo stato del peering deve essere modificato in Peered sul lato del richiedente.
È possibile fare clic sull'RPC per esaminare ulteriori informazioni sul peering.
- Si noti che lo Stato peer è Peered.
- Si noti che l'area peer è Jeddah.
- Si noti che si tratta di un peering tra tenancy.
-
Possiamo anche verificare lo stato del peering sul lato Acceptor.
-
Andare alla console OCI dal lato Acceptor, passare a Networking, Dynamic Routing Gateway e fare clic su Collegamenti di connessione peering remoto.
-
Fare clic sulla connessione peering remoto configurata per il lato Richiedente.
-
Si noti che lo stato Peering è anche impostato su Peered sul lato Acceptor.
È possibile fare clic sull'RPC per esaminare ulteriori informazioni sul peering.
- Si noti che lo Stato peer è Peered.
- Si noti che l'area peer è Riyadh.
- Si noti che si tratta di un peering tra tenancy.
-
Task 7: Progettare architetture RPC con tre o più inquilini
È anche possibile creare connessioni RPC tra più di due siti o tenant.
-
Nella seguente immagine potete vedere che abbiamo usato tre diversi inquilini:
- OCI Riyadh (richiedente)
- OCI Jeddah (accettore)
- OCI Dubai (accettore)
In questo esempio, Riyadh sarà una sorta di sito hub che fungerà da Richiedente per due Accettatori.
-
Nella seguente immagine potete vedere che abbiamo usato tre diversi inquilini:
- OCI Riyadh (richiedente)
- Jeddah OCI (richiedente + accettante)
- OCI Dubai (accettore)
In questo esempio, Riyadh sarà il richiedente di Jeddah e Jeddah sarà il richiedente di Dubai.
-
Nella seguente immagine potete vedere che abbiamo usato tre diversi inquilini:
- OCI Riyadh (richiedente + accettante)
- OCI Jeddah (accettore)
- OCI Dubai (richiedente)
In questo esempio, Riyadh sarà il Richiedente per Jeddah e l'Accettore per Dubai.
Conclusione
L'impostazione di un RPC tra due tenant OCI richiede un'attenta pianificazione, una configurazione precisa e i criteri IAM OCI corretti. Seguendo questa esercitazione dettagliata, è stato stabilito con successo un RPC sicuro e funzionale tra due DRG in tenant separati. Questa connessione consente una comunicazione perfetta tra le reti, un componente cruciale per la creazione di architetture OCI scalabili e multi-tenant.
Per semplificare il processo ed eliminare potenziali errori dei criteri, lo strumento di criteri IAM RPC fornisce un modo semplice per generare i criteri IAM OCI necessari sia per i tenant richiedente che per quelli accettanti. Garantire che i criteri, i collegamenti DRG e le sottoscrizioni regionali siano configurati correttamente garantirà un'impostazione di peering uniforme.
Oltre alle configurazioni RPC di base, la progettazione di architetture multi-tenant con tre o più tenant aggiunge ulteriore flessibilità e scalabilità alla rete OCI. Comprendere il ruolo di ciascun tenant, sia come richiedente, accettante o entrambi, consente di creare ambienti solidi e interconnessi che supportano carichi di lavoro ibridi e distribuiti in modo efficiente.
Sfruttando le funzionalità di rete di OCI, puoi creare architetture cross-tenant sicure, scalabili e ad alte prestazioni in linea con le best practice di rete aziendali. In caso di problemi, la revisione dei criteri IAM OCI e delle configurazioni DRG è un ottimo primo passo nella risoluzione dei problemi.
Con queste conoscenze a portata di mano, ora sei ben attrezzato per stabilire ed espandere le connessioni RPC in Oracle Cloud Infrastructure per soddisfare i requisiti di rete della tua organizzazione.
Conferme
- Autore - Iwan Hoogendoorn (esperto di rete OCI)
Altre risorse di apprendimento
Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.
Per la documentazione del prodotto, visita l'Oracle Help Center.
Set up RPC Connection between Two Tenants and their Dynamic Routing Gateways
G30590-02
Copyright ©2025, Oracle and/or its affiliates.