Intercambio de tráfico remoto de VCN mediante un DRG heredado

En este tema, se trata el intercambio de tráfico remoto de VCN. En este caso, remoto significa que las VCN residen en distintas regiones.Si las VCN que desea conectar están en la misma región, consulte Intercambio de trafico de VCN local mediante gateways de intercambio de tráfico local.

Nota

En este artículo se asume que el DRG es un DRG heredado y se recomienda el método descrito en Intercambio de tráfico de VCN remoto a través de un DRG actualizado para cualquier DRG actualizado. Consulte Versiones de DRG para obtener una explicación de las versiones de DRG.

Visión general del intercambio de tráfico remoto de VCN

El intercambio de tráfico remoto de VCN es el proceso de conexión de dos VCN en distintas regiones (pero el mismo arrendamiento). El intercambio de tráfico permite que los recursos de las redes virtuales en la nube se comuniquen mediante direcciones IP privadas sin enrutar el tráfico a través de Internet o a través de una red local. Sin intercambio de tráfico, una VCN necesitaría una gateway de Internet y direcciones IP públicas para las instancias que necesitan comunicarse con otra VCN en una región diferente.

Resumen de componentes de Networking para el intercambio de tráfico remoto

En un nivel superior, los componentes del servicio de Networking requeridos para un intercambio de tráfico remoto incluyen:

  • Dos redes virtuales en la nube con CIDR que no se solapan, en diferentes regiones que admiten el intercambio de tráfico remoto.

    Nota

    No deben superponerse todos los CIDR de las VCN.

    Las dos VCN de la relación de intercambio de tráfico no deben tener CIDR superpuestos. Also, if a particular VCN has several peering relationships, those other VCNs must not have overlapping CIDRs with each other. Por ejemplo, si la VCN-1 está asociada con la VCN-2 y también con la VCN-3, la VCN-2 y la VCN 3 no deben tener CIDR superpuestos.

  • Un gateway de direccionamiento dinámico (DRG) conectado a cada VCN en la relación de intercambio de tráfico. Una VCN ya tiene un DRG si está utilizando un túnel de IPSec de la VPN de sitio a sitios o un circuito virtual privado de Oracle Cloud Infrastructure FastConnect.
  • Una conexión de intercambio de tráfico remoto (RPC) en cada DRG de la relación de intercambio de tráfico.
  • Una conexión entre estos dos RPC.
  • Admitir reglas de rutas para permitir que el tráfico fluya a través de la conexión, y solo hacia y desde subredes seleccionadas en las respectivas VCN (si es necesario).
  • Admitir reglas de seguridad para controlar los tipos de tráfico permitidos entre las instancias de las subredes que deben comunicarse con la otra VCN.

En el diagrama siguiente se ilustran los componentes.

En esta imagen se muestra el diseño básico de dos VCN cuyo tráfico se ha intercambiado de forma remota, cada una con una conexión de intercambio de tráfico remoto en el DRG.
Nota

Una VCN solo puede utilizar las RPC conectadas para acceder a las VNIC de la otra VCN o de una red local, y no destinos fuera de las redes virtuales en la nube, como Internet. Por ejemplo, si el VCN-1 del diagrama anterior tuviera un Gateway de Internet, las instancias de la VCN-2 no pudieran usarlo para enviar tráfico a puntos finales en Internet. Para obtener más información, consulte Implicaciones importantes del intercambio de tráfico.

De radio a radio: intercambio de tráfico remoto con enrutamiento en tránsito

Nota

El escenario que se menciona en esta sección sigue estando soportado, pero está en desuso. Recomendamos utilizar el método de enrutamiento de tránsito de DRG que se describe en Enrutamiento del tráfico a través de un dispositivo virtual de red central.

Imagine que en cada región tiene varias redes virtuales en la nube en un diseño de hub y radios, como se muestra en el siguiente diagrama. Este tipo de diseño dentro de una región se trata en detalle en Enrutamiento de tránsito dentro de una VCN de hub. Las redes virtuales en la nube radiales de una región concreta se conectan de forma local con la VCN de hub de la misma región, mediante gateways de intercambio de tráfico locales.

Puede configurar el intercambio de tráfico remoto entre las dos VCN de hub. A continuación, también puede configurar el enrutamiento en tránsito para el DRG y los LPG de la VCN de hub, como se describe en Enrutamiento de tránsito dentro de una VCN de hub. Esta configuración permite que una VCN radial de una región se comunique con una o varias redes virtuales en la otra región sin necesidad de establecer una conexión de intercambio de tráfico remoto directamente entre dichas redes virtuales.

Por ejemplo, puede configurar el enrutamiento de modo que los recursos de la VCN-1-A se puedan comunicar con los recursos de la VCN-2-A y la VCN-2-B mediante las VCN de los hubs. De esta forma, no es necesario que la VCN 1-A tenga un intercambio de tráfico remoto separado con cada una de las VCN radiales de la otra región. También puede configurar el enrutamiento para que la VCN-1-B se pueda comunicar con las VCN radiales de la región 2, sin necesidad de realizar sus propios intercambios de tráfico remotos con ellas.

En esta imagen se muestra el diseño básico de dos regiones con VCN en un diseño de hub y radios, con intercambio de tráfico remoto entre las VCN de hub.

Acuerdo explícito necesario por ambas partes

El intercambio de tráfico implica a dos VCN del mismo arrendamiento que pueden estar administradas por la misma parte o por dos partes diferentes. Las dos partes pueden estar en la misma compañía, pero en diferentes departamentos.

El intercambio de tráfico entre dos redes virtuales en la nube requiere un acuerdo explícito de ambas partes en forma de políticas de Oracle Cloud Infrastructure Identity and Access Management que cada parte implanta para su compartimento de su propia VCN.

Conceptos importantes del intercambio de tráfico remoto

Los siguientes conceptos ayudan a comprender los conceptos básicos del intercambio de tráfico y cómo establecerlo.

INTERCAMBIO DE TRÁFICO
Un intercambio de tráfico es una única relación de intercambio de tráfico entre dos VCN. Ejemplo: si la VCN-1 interactúa con otras dos redes virtuales en la nube, existen dos intercambios. La parte remota del intercambio de tráfico remoto indica que las VCN están en distintas regiones.
ADMINISTRADORES DE VCN
En general, el intercambio de tráfico de VCN solo se puede producir si ambos administradores de VCN están de acuerdo. En la práctica, esto significa que los dos administradores deben:
  • Compartir información básica entre sí.
  • Coordinarse para configurar las políticas de Oracle Cloud Infrastructure Identity and Access Management necesarias para activar el intercambio de tráfico.
  • Configurar sus VCN para el intercambio de tráfico.
Dependiendo de la situación, un único administrador puede ser responsable de las dos VCN y las políticas relacionadas.
Para obtener más información sobre las políticas necesarias y la configuración de la VCN, consulte Configuración de una función de intercambio de tráfico remoto.
ACEPTANTE Y SOLICITANTE
Para implementar las políticas de IAM necesarias para el intercambio del tráfico, los dos administradores VCN deben seleccionar un administrador como solicitante y el otro como aceptante. El solicitante debe ser el que inicie la solicitud para conectar las dos RPC. A su vez, el aceptante debe crear una política de IAM concreta que proporcione al solicitantes permiso para conectarse a las RPC del compartimiento del aceptante. Sin esa política, se produce un error en la solicitud del solicitante de conexión.
SUSCRIPCIÓN A LA REGIÓN
Para realizar intercambios con una VCN en otra región, primero se debe suscribir un arrendamiento a esa región. Para obtener más información sobre la suscripción, consulte Gestión de regiones.
CONEXIÓN CON INTERCAMBIO DE TRÁFICO REMOTO (RPC)
Una conexión de intercambio de tráfico remoto (RPC) es un componente que se crea en el DRG conectado a una VCN. El trabajo de RPC debe actuar como un punto de conexión para una VCN con intercambio de tráfico remoto. Como parte de la configuración de las VCN, cada administrador debe crear una RPC para el DRG de su VCN. Un DRG determinado debe tener una RPC independiente para cada intercambio de transporte remoto que establece para la VCN. Para continuar con el ejemplo anterior: el DRG de la VCN-1 tendría dos RPC para realizar el intercambio de tráfico con otras dos VCN. En la API, un RemotePeeringConnection es un objeto que contiene información sobre el intercambio de tráfico. No puede reutilizar una RPC para establecer más adelante otro intercambio de tráfico con él.
CONEXIÓN ENTRE DOS RPC
Cuando el solicitante comienza la solicitud para intercambiar tráfico (en la consola o la API), está pidiendo realmente conectar las dos RPC. Esto significa que el solicitante debe tener información para identificar cada RPC (como la región y el OCID  de la RPC).
Cualquier administrador de VCN puede finalizar un intercambio de tráfico suprimiendo su RPC. En ese caso, el otro estado de RPC cambia a REVOCADO. En su lugar, el administrador podría desactivar la conexión eliminando las normas de ruta que permiten que la conexión fluya a través de la conexión (consulte la siguiente sección).
ENRUTAMIENTO AL DRG
Como parte de la configuración de las VCN, cada administrador debe actualizar el enrutamiento de la VCN para permitir que el tráfico fluya entre las VCN. Para cada subred que necesite comunicarse con la otra VCN, actualice la tabla de rutas de la subred. La regla de ruta especifica el CIDR del tráfico del destino y el DRG como destino. El DRG enruta un tráfico que coincide con esa regla al otro DRG, que a su vez enruta un tráfico al siguiente salto en la otra VCN.
En el diagrama siguiente, la VCN-1 y la VCN-2 se intercambian tráfico. El tráfico de una instancia de la subred A (10.0.0.15) destinado a una instancia de VCN-2 (192.168.0.15) se enruta a DRG-1 según la regla de la tabla de rutas de la subred A. A partir de ahí, el tráfico se enruta a través de las RPC a DRG-2 y, a continuación, desde allí, hasta el destino de la subred X.
En esta imagen se muestran las tablas de rutas y la ruta de tráfico enrutado de un dispositivo DRG a otro.
Referencia 3: Tabla de rutas de la subred A
CIDR de destino Destino de ruta
0.0.0.0/0 Gateway de internet
192.168.0.0/16 DRG-1
Referencia 4: Tabla de rutas de la subred X
CIDR de destino Destino de ruta
10.0.0.0/16 DRG-2
Nota

As mentioned earlier, a VCN can only use the connected RPCs to reach VNICs in the other VCN, and not destinations outside of the VCNs (such as the internet or an on-premises network). Por ejemplo, en el diagrama anterior, la VCN-2 no se puede utilizar el gateway de internet asociado a VCN-1.

REGLAS DE SEGURIDAD
Cada subred de una VCN tiene una o varias listas de seguridad que controlan el tráfico de entrada y salida de las VNIC de la subred en el nivel de paquetes. Puede utilizar listas de seguridad para controlar el tipo de tráfico permitido con la otra VCN. As part of configuring the VCNs, each administrator must decide which subnets in their own VCN need to communicate with VNICs in the other VCN and update their subnet's security lists to allow the traffic.
Si usa grupos de seguridad de red (NSG) para implementar reglas de seguridad, tenga en cuenta que tiene la opción de escribir reglas de seguridad para un NSG que especifica otro NSG como origen o destino de tráfico. Sin embargo, los dos NSG deben pertenecer a la misma VCN.

Implicaciones importantes del intercambio de tráfico

Si aún no lo ha hecho, lea las Implicaciones importantes del intercambio de tráfico para comprender las importantes implicaciones de control de acceso, seguridad y rendimiento para las VCN de intercambio de tráfico.

Configuración de un intercambio de tráfico remoto

En esta sección se trata el proceso general de configurar un intercambio de tráfico entre dos VCN de distintas regiones.

Importante

En el siguiente procedimiento, se supone que:

  1. Crear las RPC: cada administrador de VCN crea una RPC para su propio DRG de VCN.
  2. Compartir información: los administradores comparten la información básica necesaria.
  3. Configurar las políticas de IAM necesarias para la conexión: los administradores configuran las políticas de IAM para permitir que se establezca la conexión.
  4. Establecer la conexión: el solicitante conecta las dos RPC (consulte Conceptos importantes del intercambio de tráfico remoto para la definición de solicitante y de aceptante).
  5. Actualizar tablas de rutas: cada administrador actualiza las tablas de rutas de su VCN para permitir el tráfico entre las redes virtuales en la nube o las subredes intercambiadas.
  6. Actualizar reglas de seguridad: cada administrador actualiza las reglas de seguridad de su VCN para activar el tráfico entre las redes virtuales en la nube o las subredes con intercambio de tráfico.

Los administradores pueden realizar antes de establecer la conexión las tareas E y F. Cada administrador debe conocer el bloque CIDR o la subredes específicas de la otra la VCN y compartirlo en la tarea B.

Tarea A: Creación de las RPC

Cada administrador de aceptador o solicitante crea una RPC para su propio DRG de la VCN.

Nota

Política de IAM necesaria para crear RPC

Si los administradores ya tienen amplios permisos de administrador de red (consulte Permitir a los administradores de red gestionar una red en la nube), tienen permiso para crear, actualizar y eliminar RPC. De lo contrario, se muestra una política de ejemplo que proporciona los permisos necesarios a un grupo denominado RPCAdmins. La segunda declaración es necesaria porque la creación de una RPC afecta al DRG al que pertenece, por lo que el administrador debe tener permisos para gestionar los DRG.

Allow group RPCAdmins to manage remote-peering-connections in tenancy
Allow group RPCAdmins to manage drgs in tenancy

Consulte Creación de una conexión de intercambio de tráfico remoto y Gestión de intercambio de tráfico remoto para obtener instrucciones generales sobre la creación y el trabajo con RPC. Si es el aceptante, registre la región y el OCID de RPC y comparta esa información con el solicitante. Si las dos VCN están en arrendamientos diferentes, cada administrador debe registrar su OCID de arrendamiento (que se encuentra en la parte inferior de la página de la consola) y proporcionar esta información al otro administrador.

Tarea B: Compartir información
  • Si es el aceptante, proporcione esta información al solicitante (por ejemplo, por correo electrónico u otro método fuera de banda):

    • Región en las que se encuentra la VCN (el arrendamiento del solicitantes debe estar suscrito a esta región).
    • OCID de RPC.
    • Bloques CIDR para subredes de la VCN para que estén disponibles para la otra VCN. El solicitante necesita esta información al configurar el enrutamiento de la VCN del solicitante.
  • Si es el solicitante, proporcione esta información al aceptante:

    • Región en que se encuentra la VCN (el arrendamiento del aceptante debe estar suscrito a esta región).
    • Nombre del grupo de IAM al que otorgar permiso para crear una conexión en el compartimento del aceptante.
    • Bloques CIDR para subredes de la VCN para que estén disponibles para la otra VCN. El aceptante necesita esta información al configurar el enrutamiento de la VCN del aceptante.
Tarea C: Configurar las políticas de IAM

Cuando ambas redes virtuales en la nube estén en el mismo arrendamiento, pero en regiones diferentes, utilice las políticas proporcionadas en Intercambio de tráfico remoto con un DRG heredado.

Si ambas redes virtuales en la nube están en distintos arrendamientos pero en la misma región, utilice las políticas proporcionadas en Asociación a redes virtuales en la nube en otros arrendamientos.

Tarea D: Establecer la conexión

El solicitante debe realizar esta tarea.

Previo necesario: el solicitante debe tener:

  • La región en la que está la VCN del aceptante (el arrendamiento del solicitante debe estar suscrito a la región).
  • El OCID de la RPC del aceptante.

Consulte Creación de una conexión de intercambio de tráfico remoto para obtener instrucciones generales y utilice la información proporcionada para el aceptante. Consulte Gestión de intercambio de tráfico remoto para obtener instrucciones generales sobre cómo trabajar con RPC.

Tarea E: configurar las tablas de rutas

Como ya se ha mencionado, cada administrador puede realizar esta tarea antes o después de que se establezca la conexión.

Previo necesario: Cada administrador debe tener el bloque CIDR de la VCN o el bloque CIDR para subredes específicas de la otra VCN.

Para cada VCN, decida qué subredes de la VCN deben comunicarse con la otra VCN y actualice la tabla de rutas (consulte Actualización de reglas de una tabla de rutas de VCN) para que cada una de esas subredes incluya una nueva regla de ruta que dirija el tráfico destinado a la otra VCN al DRG:

  • Tipo de destino: gateway de enrutamiento dinámico. El DRG asociado de la VCN se selecciona automáticamente como destino y no tiene que especificarlo usted mismo.
  • Bloque CIDR de destino: el bloque CIDR de la otra VCN. Si lo desea, puede especificar una subred o un subconjunto concreto del CIDR de la VCN con intercambio de tráfico.
  • Descripción: descripción opcional de la regla.

Cualquier tráfico del subred con un destino que coincide con la regla se direcciona al DRG. Para obtener más información sobre las tablas de rutas de VCN y las reglas, consulte Tablas de rutas de VCN.

Sugerencia

Sin el enrutamiento requerido, el tráfico no fluye entre los DRG con intercambio de tráfico. Si se produce una situación en las que sea necesario detener temporalmente el intercambio de comercio, elimine temporalmente las reglas de ruta que activan la actividad de tráfico. No es necesario eliminar las RPC.
Tarea F: configurar las reglas de seguridad

Como ya se ha mencionado, cada administrador puede realizar esta tarea antes o después de que se establezca la conexión.

Requisito previo: cada administrador debe conocer el bloque CIDR o las subredes específicas para compartir con la otra VCN. En general, utilice el mismo bloque de CIDR que ha utilizado en la regla de tabla de rutas en la Tarea E: configurar las tablas de rutas.

Agregue las siguientes reglas:

  • Reglas de entrada para los tipos de tráfico que desea permitir desde la otra VCN, concretamente, desde el CIDR de la VCN o solo las subredes específicas.
  • Regla de salida para permitir el tráfico saliente de la VCN local a otra VCN. Si la subred ya tiene una regla a todos los tipos de protocolos a todos los destinos (0.0.0.0/0), no es necesario agregar una especial para el resto de la VCN.
Nota

El siguiente procedimiento utiliza listas de seguridad, pero en su lugar puede implantar las reglas de seguridad en un grupo de seguridad de red y, a continuación, crear los recursos de la subred en ese NSG.

Para la VCN local, decida qué subredes de la VCN deben comunicarse con la otra VCN y actualice la lista de seguridad para que cada una de esas subredes incluya reglas que permitan el tráfico de salida o entrada con el bloque o la subred de CIDR de la otra VCN:

Para obtener más información sobre las reglas de seguridad, consulte Reglas de seguridad.

Ejemplo

Supongamos que desea agregar una regla de estado que permite el tráfico HTTPS (puerto 443) desde el CIDR de la otra VCN. A continuación, se muestran los pasos básicos que debe realizar al agregar una regla:

  1. En la sección Permitir reglas para entrada, seleccione Regla +Add.
  2. Deje desactivada la casilla Sin estado.
  3. Tipo de origen: Dejar como CIDR.
  4. CIDR de origen: Introduzca el mismo bloque CIDR que utilizan las reglas de ruta (consulte Tarea E: Configuración de las tablas de rutas).
  5. Protocolo IP: Dejar como TCP.
  6. Rango de puertos de origen: déjelo como Todos.
  7. Rango de puertos de destino: Introducir 443.
  8. Descripción: descripción opcional de la regla.