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.
In questo articolo si presuppone che il DRG sia un DRG precedente e si consiglia il metodo descritto in Peering VCN remoto tramite un DRG aggiornato per qualsiasi DRG aggiornato. Per una spiegazione delle versioni di 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 delle reti VCN di comunicare utilizzando indirizzi IP privati senza instradare il traffico su Internet o attraverso una rete on-premise. 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 che supportano il peering remoto.
Nota
Tutti i CIDR VCN non devono sovrapporsi
Le due reti VCN nella relazione di peering non devono avere CIDR sovrapposti. Inoltre, se una determinata VCN dispone di diverse relazioni di peering, tali altre VCN non devono avere CIDR sovrapposti 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.
- 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 al traffico di fluire sulla connessione e solo a e da subnet selezionate nelle rispettive reti VCN (se necessario).
- 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 solo le RPC connesse per raggiungere le VNIC nell'altra VCN o in una rete on premise e non le destinazioni al di fuori delle VCN, come Internet. Ad esempio, se la VCN-1 nel diagramma precedente dovesse avere 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.
Spoke-to-Spoke: peering remoto con instradamento del transito
Lo scenario menzionato in questa sezione è ancora supportato, ma non è più valido. Ti consigliamo 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 una determinata area vengono peered a livello 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.
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 è un'unica relazione di peering tra due reti VCN. Esempio: se la VCN-1 esegue il peer 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 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 a una 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 specifico deve avere 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. Ciò significa che 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, aggiornare 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 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 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 le liste di sicurezza della propria subnet per consentire il traffico.
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:
- Questa tenancy è sottoscritta all'area dell'altra VCN. In caso contrario, vedere Gestione delle aree.
- Si dispone già di un DRG collegato alla 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 VCN per abilitare il traffico tra le reti VCN o le subnet sottoposte a peering.
- Aggiorna regole di sicurezza: ogni amministratore aggiorna le regole di sicurezza della propria VCN per abilitare il traffico tra le VCN o le subnet sottoposte a peering.
Gli amministratori possono eseguire i task E e F prima di stabilire la connessione. Ogni amministratore deve conoscere il blocco CIDR o subnet specifiche dell'altra VCN e condividerle nel task B.
Ogni amministratore di accettore o richiedente crea un RPC per il DRG della propria VCN.
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
Per istruzioni generali sulla creazione e l'utilizzo di RPC, vedere Creazione di una connessione peering remoto e Gestione peering remoto. Se si è il responsabile dell'accettazione, registrare l'area e l'OCID dell'RPC e condividere tali informazioni con il richiedente. Se le due VCN si trovano in tenancy diverse, ogni amministratore deve registrare il proprio OCID tenancy (che si trova nella parte inferiore della pagina della console) e fornire queste informazioni all'altro amministratore.
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.
Per istruzioni generali, vedere Creazione di una connessione peering remoto e utilizzare le informazioni fornite per l'accettatore. Per istruzioni generali sull'utilizzo di RPC, vedere Gestione peering remoto.
Come accennato in precedenza, ogni amministratore può eseguire questo task prima o dopo la creazione della connessione.
Prerequisito: ogni amministratore deve avere il blocco CIDR della VCN o il blocco CIDR per subnet specifiche nell'altra VCN.
Per ogni VCN, decidere quali subnet nella VCN devono comunicare con l'altra VCN e aggiornare la tabella di instradamento (vedere Aggiornamento delle regole di una tabella di instradamento VCN) per ciascuna di tali subnet in modo da includere una nuova regola di instradamento che indirizza il traffico destinato per l'altra VCN al DRG:
- 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.
Qualsiasi traffico della subnet con una destinazione che corrisponde alla regola viene instradato al DRG. Per ulteriori informazioni sulle tabelle e le regole di instradamento VCN, 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, rimuovere temporaneamente 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 conoscere il blocco CIDR o subnet specifiche da condividere con l'altra VCN. In generale, utilizzare lo stesso blocco CIDR utilizzato nella regola della tabella di instradamento in Task E: Configurare le tabelle di instradamento.
Aggiungere le regole riportate di seguito.
- Regole di entrata per i tipi di traffico che si desidera consentire dall'altra VCN, dal CIDR della VCN o solo da subnet specifiche.
- 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 (ad esempio 0.0.0.0/0), non è necessario aggiungerne una speciale per l'altra VCN.
La procedura seguente utilizza gli elenchi di sicurezza, ma è possibile implementare le regole di sicurezza in un gruppo di sicurezza di rete e quindi creare le risorse della sottorete in tale gruppo NSG.
Per la VCN locale, decidere quali subnet nella VCN devono comunicare con l'altra VCN e aggiornare la lista di sicurezza per ciascuna di tali subnet in modo da includere regole che consentano il traffico in uscita o in entrata con il blocco CIDR o la subnet delle altre VCN:
Per ulteriori informazioni sulle regole di sicurezza, vedere Regole di sicurezza.
Si supponga di voler aggiungere una regola con conservazione dello stato che consenta 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, selezionare +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.