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 asociadas a un gateway de enrutamiento dinámico (DRG) diferente y que el DRG puede residir en una región diferente o posiblemente en la misma región. Si las redes virtuales en la nube que desea conectar están en la misma región y conectadas al mismo DRG, consulte Intercambio de tráfico de VCN local a través de un DRG actualizado.
Este escenario está disponible para un DRG actualizado o heredado, con la excepción de que los DRG heredados no admiten la conexión de DRG en distintos arrendamientos ni la asociación de varias VCN. Consulte Versiones de DRG para obtener más información sobre las versiones de DRG.
Antes de implantar este escenario, asegúrese de que:
- La VCN A está asociada al DRG A
- La VCN B está asociada al DRG B
- La configuración de enrutamiento en ambos DRG utiliza tablas de rutas por defecto
- 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 conexión de dos redes virtuales en distintas regiones. 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. Las redes virtuales en la nube pueden estar en el mismo arrendamiento de Oracle Cloud Infrastructure o en otras diferentes. 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 distintas regiones.
Nota
No se puede solapar ningún CIDR de VCN
Las dos redes virtuales en la nube de la relación de intercambio de tráfico no pueden tener CIDR solapados. Also, if a particular VCN has several peering relationships, those other VCNs can't have CIDRs that overlap 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.
Si está configurando este escenario, debe 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 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.
- 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.
Una VCN solo puede utilizar las RPC conectadas para acceder a las VNIC de la otra VCN o a una red local si el DRG tiene una conexión a un entorno local. Por ejemplo, si la la VCN-1 del diagrama anterior tenía un Gateway de internet, las instancias de la VCN-2 no podí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)
El escenario que se menciona en esta sección aún está soportado, pero le recomendamos que utilice el método de enrutamiento en tránsito de DRG descrito 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 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 más redes virtuales en la otra región sin necesidad de 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.
De radio a radio: intercambio de datos remoto con enrutamiento en tránsito (DRG actualizado)
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 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 la región se conectan de forma local con el par de DRG/VCN de hub en la misma región mediante una conexión mutua al DRG.
Puede configurar el intercambio de tráfico remoto entre dos redes virtuales en la nube de hub. You can then also set up transit routing for the hub VCN's DRG, as discussed in Routing traffic through a central network virtual appliance. Esta configuración permite que una VCN radial de una región se comunique con una o más redes virtuales en la otra región sin necesidad de 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.
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:
- ACEPTANTE Y SOLICITANTE
- Para implantar las políticas de IAM necesarias para la interconexión, los dos administradores de las 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 la 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 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. El solicitante debe tener información para identificar cada RPC (como la región y el OCID de la RPC).
- 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 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.
-
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 - 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 appropriately.
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 del intercambio de tráfico remoto
En esta sección, se trata el proceso general para configurar el intercambio de tráfico entre dos redes virtuales en la nube en diferentes regiones.
En el siguiente procedimiento, se supone que:
- El arrendamiento está suscrito a la otra región de la VCN. Si no lo está, consulte Gestión de regiones.
- Ya tiene una VCN asociada al DRG. Si no lo hace, consulte Gateways de enrutamiento dinámico.
- Ya ha configurado las políticas de IAM necesarias para la conexión. Las políticas de IAM para el intercambio de tráfico remoto en el mismo arrendamiento y entre arrendamientos son diferentes. Consulte Políticas de IAM para el enrutamiento entre redes virtuales en la nube
Visión general de los pasos necesarios:
- Crear las RPC: cada administrador de VCN crea una RPC para su propio DRG de VCN.
- Compartir información: los administradores comparten la información básica necesaria.
- 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).
- 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.
- 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.
Cada administrador crea una RPC para su propio DRG de VCN. "Usted" en el siguiente procedimiento significa un administrador (tanto el aceptante como el solicitante).
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
- En la consola, confirma que estás viendo el compartimiento que contiene el DRG al que deseas agregar el RPC. Para obtener más información sobre compartimentos y control de acceso, consulte Control de acceso.
- Abra el menú de navegación y seleccione Red. En Conectividad de cliente, seleccione Gateway de enrutamiento dinámico.
- Seleccione el DRG en el que esté interesado.
- En Recursos, seleccione Asociaciones de conexiones de intercambio de tráfico remoto.
- Seleccione Create Remote Peering Connection (Crear conexión de intercambio de tráfico remota).
-
Introduzca lo siguiente:
- Nombre: Nombre fácil de recordar para el RPC. No es necesario que sea único y no se puede cambiar posteriormente en la consola (pero puede cambiarlo con la API). Evite introducir información confidencial.
- Crear en compartimiento: el compartimiento en donde desea crear el RPC, si es diferente del compartimiento en donde está trabajando.
-
Seleccione Create Remote Peering Connection (Crear conexión de intercambio de tráfico remota).
A continuación, se crea el RPC y se muestra en la página Conexiones de intercambio de tráfico remoto en el compartimiento que haya elegido.
- Si es el aceptante, registre la región y el OCID de la RPC para proporcionarlos posteriormente al solicitante.
- Si las dos redes virtuales en la nube están en arrendamientos diferentes, registre el OCID de este arrendamiento (que se encuentra en la parte inferior de la página de la consola). Proporcione el OCID al otro administrador más adelante.
Esta tarea es específica de una conexión entre arrendamientos. Si las conexiones están en el mismo arrendamiento, puede pasar a la siguiente tarea.
-
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.
- Los bloques de CIDR para subredes de la VCN que desee que estén disponibles para la otra VCN. El solicitante necesita esta información al configurar el enrutamiento de la VCN del solicitante.
- Si las redes virtuales en la nube están en arrendamientos diferentes: el OCID del arrendamiento del aceptante.
-
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).
- Si las redes virtuales en la nube están en el mismo arrendamiento: nombre del grupo de IAM al que se ha otorgado permiso para crear una conexión en el compartimento del aceptador.
- Si las redes virtuales en la nube están en arrendamientos diferentes: el OCID del arrendamiento del solicitante.
- Los bloques de CIDR para subredes de la VCN que desee que estén disponibles para la otra VCN. El aceptante necesita esta información al configurar el enrutamiento de la VCN del aceptante.
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.
- El OCID del arrendamiento del aceptante (solo si la VCN del aceptante está en un arrendamiento diferente)
Consulte las instrucciones en Conexión de dos conexiones de intercambio de tráfico remoto. Otras tareas relacionadas con RPC se explican en Gestión de intercambio de tráfico remoto.
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 conocer el bloque CIDR o la subredes específicas de la otra VCN.
Para cada VCN, decida qué subredes de la VCN local deben comunicarse con la otra VCN. A continuación, actualice la tabla del enrutamiento para cada uno de esos subredes a fin de incluir una nueva regla que dirija al DRG local el tráfico destinado al otro VCN. Consulte Actualización de reglas de una tabla de rutas de VCN y agregue una regla de ruta que utilice la siguiente configuración:
- 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. El ejemplo utiliza las VCN con 10.0.0.0/16 y 192.68.0.0/16. 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 coincida a la regla se direcciona al DRG local. Para obtener más información sobre la configuración de reglas de ruta, consulte Tablas de rutas de VCN.
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 fuera necesario detener temporalmente el intercambio de transacciones, puede eliminar las reglas de ruta que activan la actividad de tráfico. No es necesario eliminar las RPC.
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 o las subredes específicas de la otra VCN. En general, utilice el mismo bloque CIDR que ha utilizado en la regla del cuadro de rutas de la Tarea D: configurar las tablas.
Recomendamos agregar las siguientes reglas:
- Reglas de entrada para los tipos de tráfico que desea permitir desde el CIDR de la otra VCN o subredes específicas. El ejemplo utiliza las VCN con 10.0.0.0/16 y 192.68.0.0/16.
- Regla de salida para permitir el tráfico saliente de la VCN local a otra VCN. Si la subred ya tiene una regla de salida amplia para todos los tipos de protocolos a todos los destinos (0.0.0.0/0), no tendrá que agregar una especial para el resto de las VCN.
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 cada VCN, decida qué subredes de la VCN local deben comunicarse con la otra VCN. A continuación, actualice la lista de seguridad de cada uno de estas subredes para incluir reglas que permitan el tráfico previsto de salida o entrada con el bloque o subred CIDR de la otra VCN. Consulte Actualización de reglas en una lista de seguridad y también Creación de una lista de seguridad (para obtener más información sobre las opciones disponibles para las reglas de seguridad).
Para obtener información general sobre las reglas de seguridad, consulte Reglas de seguridad.