Configurar conectividad privada de interrelación entre arrendamientos
Por razones de negocio y técnicas, es posible que necesite habilitar la conectividad privada entre sus redes virtuales en la nube y asegurarse de que el tráfico entre las redes nunca atraviese Internet público. Por ejemplo, es posible que necesite conectividad privada entre redes en dos regiones dentro de su arrendamiento, o entre redes en su arrendamiento y las del arrendamiento de una organización que coopere.
Oracle Cloud Infrastructure admite dos modelos de búsqueda de red:
- Peering de VCN local
Las redes virtuales en la nube (VCN) dentro de una región se pueden peered mediante gateways de peering locales (LPG). Los recursos asociados a dichas VCN peered pueden comunicarse utilizando direcciones IP privadas sin enrutar el tráfico a través de Internet público. Las VCN pueden estar en el mismo arrendamiento o en diferentes arrendamientos.
- Peering remoto de VCN
Las VCN en diferentes regiones pueden comunicarse utilizando direcciones IP privadas sin enrutar el tráfico a través de Internet público. Puede configurar peering entre dos VCN en diferentes regiones configurando una conexión peering remota (RPC) en cada uno de los gateways de enrutamiento dinámicos (DRG) conectados a las VCN en la relación peering. El peering remoto de VCN se utiliza generalmente para conectar dos VCN entre regiones del mismo arrendamiento. En ciertos escenarios, es posible que necesite conectar VCN en dos arrendamientos diferentes entre regiones.
Arquitectura
En esta arquitectura, la conectividad de red privada se configura entre dos arrendamientos y entre dos regiones.
Descripción de la ilustración xregion-private-connectivity-oci.png
La arquitectura tiene los siguientes componentes:
- Arrendamiento
Un arrendamiento es una partición segura y aislada que Oracle configura en Oracle Cloud al registrarse en Oracle Cloud Infrastructure. Puede crear, organizar y administrar sus recursos en Oracle Cloud dentro de su arrendamiento.
Esta arquitectura tiene dos arrendamientos, uno para la empresa A y el otro para la empresa B.
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y grandes distancias pueden separarlas (entre países o incluso continentes).
Esta arquitectura tiene dos regiones. La compañía A tiene sus recursos en la nube en una sola región, Estados Unidos Este (Ashburn). Los recursos de la Compañía B se distribuyen entre dos regiones: Estados Unidos Este (Ashburn) e India Oeste (Mumbai).
- Red virtual en la nube (VCN)
VCN es una red privada personalizable que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes tradicionales de centros de datos, las VCN le proporcionan un control completo sobre su entorno de red. Puede segmentar VCN en subredes, que se pueden asignar a una región o a un dominio de disponibilidad. Tanto las subredes regionales como las subredes específicas del dominio de disponibilidad pueden coexistir en la misma VCN. Una subred puede ser pública o privada.
En esta arquitectura, la compañía A tiene VCN 10.0.0.0/16 en la región Este de Estados Unidos (Ashburn). La compañía B tiene dos VCN, cada una en una región diferente: VCN B 172.16.0.0/16 en US East (Ashburn) y VCN C 192.168.0.0/16 en India West (Mumbai). Tenga en cuenta que cada VCN de esta arquitectura de peering tiene un prefijo CIDR único.
- Gateway de enrutamiento dinámico (DRG)
DRG es un enrutador virtual que proporciona una ruta de acceso para el tráfico de red privada entre VCN y una red fuera de la región, como VCN en otra región de Oracle Cloud Infrastructure, una red local o una red en otro proveedor de nube.
En esta arquitectura, VCN B en Ashburn y VCN C en Mumbai se comparan de forma remota mediante DRG.
- Puerta de enlace de peering local (LPG)
Un LPG permite emparejar un VCN con otro VCN en la misma región. Peering significa que las VCN se comunican utilizando direcciones IP privadas, sin que el tráfico atraviese Internet o enrutamiento a través de su red local.
En esta arquitectura, VCN A y VCN B (ambos en la región de Ashburn) se comparan localmente mediante LPG.
- Mesas de ruta
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de VCN, normalmente a través de gateways.
Esta arquitectura incluye tablas de rutas para dirigir el tráfico a través de las VCN.- VCN A tiene reglas de ruta para dirigir el tráfico a VCNs B y C a través de LPG.
- VCN B tiene reglas de ruta para dirigir el tráfico a VCN A a través del LPG y a VCN C a través de DRG.
- VCN C tiene reglas de ruta para dirigir el tráfico a VCN A y C a través de DRG.
Recomendaciones
Utilice las siguientes recomendaciones como punto de partida. Sus requisitos pueden diferir de la arquitectura descrita aquí.
- Identity and Access Management (IAM)
Puede configurar una política de IAM para permitir que los usuarios de un grupo específico inicien conexiones desde cualquier LPG del compartimento del solicitante (compartimento Compañía A) a un arrendamiento específico. Asocie la política al arrendamiento del solicitante (es decir, al compartimento
root) y no al compartimento del solicitante. - VCN
Al crear VCN, determine cuántas direcciones IP necesitan sus recursos en la nube en cada subred. Mediante la notación Classless Inter-Domain Routing (CIDR), especifique una máscara de subred y un rango de direcciones de red lo suficientemente grande como para las direcciones IP necesarias. Utilice un rango de direcciones que esté dentro del espacio de direcciones IP privadas estándar.
Seleccione un rango de direcciones que no se superponga con ninguna otra red (en Oracle Cloud Infrastructure, el centro de datos local o en otro proveedor de nube) en la que desee configurar conexiones privadas.
- Reglas de seguridad
Para controlar el tráfico de red, puede utilizar listas de seguridad o grupos de seguridad de red (NSG). Las reglas que especifique en una lista de seguridad se aplican a todas las VNIC de la subred a la que adjunta la lista de seguridad. Si necesita cortafuegos a un nivel más granular, utilice grupos de seguridad de red (NSG). Las reglas de un NSG se aplican solo a las VNIC especificadas. Oracle recomienda utilizar NSG porque permiten separar la arquitectura de subred de los requisitos de seguridad de la carga de trabajo.
Consideraciones
Al implementar esta arquitectura, tenga en cuenta los siguientes factores:
- Escalabilidad
Considere los límites de servicio para VCN y subredes para su arrendamiento. Si necesita más redes, solicite un aumento en los límites.
- Seguridad
Utilice los mecanismos de seguridad adecuados para proteger su topología.
En la arquitectura que despliega mediante el código Terraform proporcionado, la lista de seguridad por defecto de VCN permite el tráfico SSH desde 0.0.0.0/0 e ICMP solo desde ambos arrendamientos. Ajuste la lista de seguridad para permitir solo los hosts y redes que deben tener acceso SSH (o acceso a otros puertos de servicio necesarios) a su infraestructura.
- Rendimiento
Dentro de una región, el número de VCN no afecta al rendimiento. Cuando pares VCN en diferentes regiones, considera latencia.
Desplegar
El código Terraform para desplegar esta arquitectura está disponible en GitHub.
- Vaya a GitHub.
- Clone o descargue el repositorio en su computadora local.
- Siga las instrucciones del documento
README.
Log de Cambios
Este log muestra cambios significativos:
| 8 de septiembre de 2020 |
|
| 31 de mayo de 2021 | Diagrama arquitectónico actualizado para reflejar nuevos estándares iconográficos. |