Esta página ha sido traducida por una máquina.

Intercambio de tráfico de VCN remoto a través de un DRG actualizado

En este tema, se trata el intercambio de tráfico remoto de VCN.

En este caso, remoto significa que las redes virtuales en la nube (VCN) están conectadas a un gateway de enrutamiento dinámico (DRG) diferente que reside en una región diferente. Si las VCN que desea conectar están en la misma región, consulte Intercambio de tráfico de VCN local a través de un DRG actualizado.

Nota:

Este escenario está disponible para un DRG actualizado o heredado, con la excepción de que los DRG heredados no admitirán la conexión de DRG en distintos arrendamientos. Consulte Versiones de DRG para obtener un desglose de las posibles versiones de DRG.

Antes de intentar implantar este escenario, asegúrese de que:

  • La VCN A está asociada al DRG A en la región 1
  • La VCN B está asociada al DRG B en la región 2
  • La configuración de enrutamiento en ambos DRG no se ha modificado
  • Los permisos de IAM adecuados se aplican a las VCN que estén en el mismo arrendamiento o en distintos arrendamientos.

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

El intercambio de VCN remoto es el proceso de conectar dos redes virtuales en la nube en distintas regiones. El intercambio de tráfico permite a los recursos de las VCN comunicarse mediante direcciones IP privadas sin enrutar el tráfico a través de internet o a través de la red local. Las VCN pueden estar en el mismo arrendamiento de Oracle Cloud Infrastructure o en otros diferentes. Sin intercambio de tráfico, una determinada VCN necesitaría un 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 VCN con CIDR no solapados en diferentes regiones.

    Nota

    No se puede solapar ningún CIDR de VCN

    Las dos VCN de la relación de intercambio de tráfico no pueden tener CIDR solapados. Además, si una determinada VCN tiene varias relaciones de intercambio de tráfico, esas otras VCN no deben tener CIDR superpuestos entre sí. 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.

    Si configura este escenario, tendrá que cumplir este requisito en la etapa de planificación. Es probable que surjan problemas de enrutamiento si se produce un solapamiento de CIDR, pero las operaciones de la consola o de API no le impedirán crear una configuración que cause incidencias.

  • Un gateway de enrutamiento dinámico (DRG) conectado a cada VCN en la relación de intercambio de tráfico. Su VCN ya tiene un DRG si utiliza un túnel de VPN de sitio a sitio IPSec 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.
  • Soporte de reglas de ruta para permitir que el tráfico fluya por la conexión y solo hacia y desde subredes determinadas en las VCN respectivas (si se desea).
  • 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 determinada puede utilizar las RPC conectadas para acceder solo a las VNIC de la otra VCN o a su red local si el DRG tiene una conexión a un CPE local. Por ejemplo, si la VCN-1 del diagrama anterior tuviera un gateway de internet, las instancias de la VCN-2 NO podrían usarlo para enviar tráfico a puntos finales en internet. Para obtener más información, consulte Implicaciones importantes del intercambio de tráfico.

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.

El intercambio de tráfico de VCN de diferentes arrendamientos tiene algunas complicaciones de permisos que deben resolverse en ambos arrendamientos. Consulte Políticas de IAM para el enrutamiento entre redes virtuales en la nube para obtener más información sobre los permisos necesarios.

De radio a radio: intercambio de tráfico remoto con enrutamiento en tránsito (solo DRG heredados)

Nota

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

Imagine que, en cada región, tiene varias VCN en un diseño de hub y radios, tal y 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. El tráfico de las VCN radiales de una determinada región se intercambia localmente con la VCN de hub de la misma región mediante gateways de intercambio de tráfico local.

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 más VCN radiales de la otra región sin necesidad de establecer una conexión de intercambio de tráfico remoto directamente entre esas VCN.

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 este modo, no es necesario que VCN 1-A tenga un intercambio remoto independiente 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.

De radio a radio: intercambio de datos remoto con enrutamiento en tránsito (DRG actualizado)

Nota

El escenario de esta sección utiliza el método de enrutamiento en 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 VCN en un diseño de hub y radios, tal y 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 VCN radiales de una región determinada se conectan localmente al par DRG/VCN de hub de la misma región mediante conexión mutua al DRG.

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 de la VCN de hub, como se describe en Enrutamiento del tráfico a través de un dispositivo virtual de red central. Esta configuración permite que una VCN radial de una región se comunique con una o más VCN radiales de la otra región sin necesidad de establecer una conexión de intercambio de tráfico remoto directamente entre esas VCN.

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 este modo, no es necesario que VCN 1-A tenga un intercambio remoto independiente 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.

Conceptos importantes del intercambio de tráfico remoto

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

INTERCAMBIO DE TRÁFICO
Un intercambio de tráfico es una única relación de intercambio de tráfico entre dos VCN. Ejemplo: si VCN-1 intercambia tráfico con otras dos VCN, hay dos intercambios de tráfico. La parte remota del intercambio de tráfico remoto indica que las VCN están en distintas regiones. Para este método de intercambio de tráfico remoto, las VCN pueden estar en el mismo arrendamiento o en distintos arrendamientos.
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, 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. Las VCN pueden estar en el mismo arrendamiento o en distintos arrendamientos.
Para obtener más información sobre las políticas necesarias y la configuración de la VCN, consulte Políticas de IAM para el enrutamiento entre redes virtuales en la nube.
ACEPTANTE Y SOLICITANTE
Para implementar las políticas de IAM necesarias para el intercambio de tráfico, los dos administradores de la VCN deben designar 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 solicitante 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 de tráfico con una VCN de otra región, su arrendamiento debe estar suscrito en primer lugar 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 creado en el dispositivo DRG conectado su 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 tráfico 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 inicia la solicitud de intercambio de tráfico (en la consola o la API), está pidiendo realmente conectar las dos RPC. 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 terminar un intercambio de tráfico suprimiendo su RPC. En ese caso, el otro estado de RPC cambia a REVOCADO. En cambio, el administrador podría representar la conexión como no funcional eliminando las reglas de ruta que permiten que el tráfico 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 otro VCN, actualice la tabla de rutas de la subred. La regla de ruta especifica el CIDR del tráfico de destino y su DRG como destino. Su dispositivo DRG enruta el tráfico que coincide con la regla con el otro DRG, que a su vez, enruta el 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 1: 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 2: Tabla de rutas de la subred X
CIDR de destino Destino de ruta
10.0.0.0/16 DRG-2
Nota

Como se ha mencionado anteriormente, una VCN determinada puede utilizar las RPC conectadas para llegar solo a las VNIC de la otra VCN o de la red local, y no a destinos en internet. Por ejemplo, en el diagrama anterior, la VCN-2 no puede utilizar el gateway de internet asociado a la 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. Como parte de la configuración de las VCN, cada administrador debe determinar qué subredes de su propia VCN deben comunicarse con las VNIC de la otra VCN y actualizar las listas de seguridad de la subred según corresponda.
Si utiliza grupos de seguridad de red (NSG) para implantar reglas de seguridad, tenga en cuenta que puede escribir reglas de seguridad para un NSG que especifique 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:

Visión general de los pasos necesarios:

  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. 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).
  4. Actualizar tablas de rutas: cada administrador actualiza las tablas de rutas de su VCN para activar el tráfico entre las VCN conectadas según lo previsto.
  5. Actualizar reglas de seguridad: cada administrador actualiza las reglas de seguridad de su VCN para activar el tráfico entre las VCN conectadas según lo previsto.

Si lo desea, los administradores pueden realizar las tareas 4 y 5 antes de establecer la conexión. Cada administrador debe conocer el bloque de CIDR o las subredes específicas de la otra VCN y compartirlo en la tarea 2.

¿Le ha resultado útil este artículo?