Rampa remota

panoramica

In questo scenario, viene stabilita la connettività tra le reti VCN e la rete on premise, ma non tra le reti VCN. Questa scelta di criteri di instradamento viene implementata configurando le tabelle di instradamento del gateway di instradamento dinamico (DRG); in caso contrario, questo scenario è simile al peering remoto.

Questo scenario è disponibile solo per un DRG aggiornato.

Riepilogo dei componenti di networking per una singola rampa

Ad un livello elevato, i componenti del servizio di networking necessari per la singola rampa includono:

• Due VCN con CIDR non sovrapposti in aree diverse.

  Nota
  
  

  Nessun CIDR VCN può sovrapporsi

  I due VCN nella relazione di peering non possono 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.

  Se si sta configurando questo scenario, è necessario soddisfare questo requisito nella fase di pianificazione. È probabile che i problemi di instradamento si verifichino quando si sovrappongono i CIDR, ma le operazioni della console o dell'API non impediscono di creare una configurazione che causi problemi.

• Un gateway di instradamento dinamico (DRG) collegato a ogni VCN nella relazione di peering. La VCN dispone già di un gateway DRG se si utilizza la VPN site-to-site o un circuito virtuale privato Oracle Cloud Infrastructure FastConnect.
• Due tabelle di instradamento DRG personalizzate: una indirizza il traffico alle VCN e una indirizza il traffico alla rete on premise. Le tabelle di instradamento DRG predefinite (una per i collegamenti VCN locali e una per tutti gli altri collegamenti) non vengono utilizzate al termine della configurazione.
• Una connessione peering remoto (RPC) su ogni DRG nella relazione peering.
• Una connessione peering remoto stabilita 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. La VCN-1 è facoltativa se l'intento principale è quello di accedere alla VCN-2. Per abilitare il traffico, sono necessarie tabelle di instradamento e regole di sicurezza di supporto in ogni VCN.

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.

Concetti importanti sul 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:

• Condividi alcune informazioni di base tra loro.
• Coordina per impostare i criteri di Oracle Cloud Infrastructure Identity and Access Management necessari per abilitare il peering.
• Configurare le proprie VCN per il peering.

A seconda della situazione, un singolo amministratore potrebbe essere responsabile sia delle reti VCN che dei criteri correlati. I VCN possono trovarsi nella stessa tenancy o in tenancy diverse.

Per ulteriori informazioni sui criteri necessari e sulla configurazione della VCN, vedere Policy IAM per l'instradamento tra VCN.

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. Il richiedente deve disporre di informazioni per identificare ogni RPC (ad esempio, l'area dell'RPC e OCID ).

L'amministratore della VCN può arrestare un peering eliminando il proprio RPC. In tal caso, lo stato dell'altro RPC passa a REVOKED. L'amministratore potrebbe invece rendere la connessione non funzionale rimuovendo le regole di instradamento che consentono al traffico di fluire attraverso la connessione (vedere la sezione successiva).

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 la rete in locale, si aggiorna 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.

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.

Se si utilizzano i gruppi di sicurezza di rete (NSG) per implementare le regole di sicurezza, si noti che è possibile scrivere regole di sicurezza per un gruppo NSG che specifica un altro gruppo NSG come origine o destinazione del traffico. Tuttavia, i due gruppi NSG devono appartenere alla stessa VCN.

Impostazione di una singola rampa

Prima di tentare di implementare questo scenario, assicurarsi che:

1. La VCN-1 è collegata a DRG-1 nell'area 1 seguendo i passi descritti nella sezione Collegamento di una VCN a un DRG.
2. La VCN-2 è collegata a DRG-2 nell'area 2 seguendo i passi descritti nella sezione Collegamento di una VCN a un DRG.
3. La VCN-2 viene sottoposta a peering con VCN-1 seguendo i passi descritti nella sezione Peering VCN remoto tramite un DRG aggiornato
4. Entrambi i DRG sono altrimenti non modificati.
5. FastConnect il circuito virtuale 1 si trova nell'area 1, connesso a DRG-1 in base al metodo appropriato, a seconda dell'origine del circuito virtuale (partner Oracle, colocation Oracle, provider di terze parti), come descritto nella documentazione per FastConnect.

Il diagramma riportato di seguito mostra lo stato iniziale prima dell'implementazione di questo scenario. VCN-1 e VCN-2 sono sottoposti a peering. Il traffico proveniente da un'istanza nella subnet A (10.0.0.15) destinata a un'istanza nella VCN-2 (192.168.0.15) viene instradato a DRG-1 in base alla regola nella tabella di instradamento della subnet A. Da lì il traffico viene instradato attraverso gli RPC a DRG-2, e poi da lì, fino alla destinazione nella subnet X. La rete in locale può indirizzare le risorse nella rete VCN-1, ma non nella rete VCN-2.

Lo scenario onramp implementato descritto nel diagramma successivo non consente alle reti VCN di instradare il traffico tra loro. VCN-1 e VCN-2 sono sottoposti a peering. Il traffico proveniente da una risorsa in locale nella rete (172.16.0.10) destinata a un'istanza nella rete VCN-2 (192.168.0.15) viene instradato a DRG-1 in base alla regola nella tabella di instradamento dei collegamenti IPSEC_TUNNEL in locale. Da lì il traffico viene instradato attraverso il collegamento RPC a DRG-2, quindi alla destinazione nella subnet X.

Passi

Tutti i passi riportati di seguito vengono eseguiti su DRG-1.