Visión general de Networking

Cuando trabaja con Oracle Cloud Infrastructure, uno de los primeros pasos consiste en configurar una red virtual en la nube (VCN) para sus recursos en la nube. En este tema se proporciona una visión general de los componentes de Oracle Cloud Infrastructure Networking y los escenarios habituales para utilizar una VCN.

Consejo

Vea una introducción en vídeo al servicio.

Componentes de Networking

El servicio de Networking utiliza versiones virtuales de los componentes de red tradicionales con los que ya puede estar familiarizado:

RED VIRTUAL EN LA NUBE (VCN)
Red virtual privada que se configura en centros de datos de Oracle. Se parece mucho a una red tradicional, con reglas de firewall y tipos específicos de gateways de comunicación cuya utilización puede elegir. Una VCN reside en una única región de Oracle Cloud Infrastructure y abarca uno o más bloques de CIDR (IPv4 y IPv6, si están activados). Consulte Rangos de direcciones y tamaño de VCN permitidos. Los términos red virtual en la nube, VCN y red en la nube se utilizan indistintamente en esta documentación. Para obtener más información, consulte VCN y subredes.
SUBREDES

Subdivisiones que define en una VCN (por ejemplo, 10.0.0.0/24, 10.0.1.0/24 o 2001:DB8::/64). Las subredes contienen tarjetas de interfaz de red virtual (VNIC), que se conectan a las instancias. Cada subred está formada por un rango contiguo de direcciones IP (para IPv4 y IPv6, si están activadas) que no se solapan con otras subredes de la VCN. Puede designar una subred para que exista en un único dominio de disponibilidad o en toda una región (se recomiendan las subredes regionales). Las subredes actúan como una unidad de configuración en la VCN: todas las VNIC de una subred determinada utilizan las mismas tablas de rutas, listas de seguridad y opciones de DHCP (consulte las definiciones siguientes). Puede designar una subred como pública o privada al crearla. Privada significa que las VNIC de la subred no pueden tener direcciones IPv4 públicas y que se prohibirá la comunicación a través de internet con puntos finales IPv6. Pública significa que las VNIC de la subred pueden tener direcciones IPv4 públicas y que está permitida la comunicación a través de internet con puntos finales IPv6. Consulte Acceso a internet.

VNIC
Tarjeta de interfaz de red virtual (VNIC), que se conecta a una instancia y reside en una subred para permitir una conexión con la VCN de la subred. La VNIC determina cómo se conecta la instancia con los puntos finales dentro y fuera de la VCN. Cada instancia tiene una VNIC principal creada durante el inicio de la instancia y no se puede eliminar. Puede agregar VNIC secundarias a una instancia existente (en el mismo dominio de disponibilidad que la VNIC principal) y eliminarlas según desee. Cada VNIC secundaria puede estar en una subred de la misma VCN que la VNIC principal o en una subred diferente que esté en la misma VCN o en una diferente. Sin embargo, todas las VNIC deben estar en el mismo dominio de disponibilidad que la instancia. Para obtener más información, consulte Tarjetas de interfaz de red virtual (VNIC). A una VNIC asociada a una instancia informática y que reside en una subred con IPv6 activado se le puede asignar opcionalmente una dirección IPv6.
IP PRIVADA
Dirección de IPv4 privada e información relacionada para tratar una instancia (por ejemplo, un nombre de host para DNS). Cada VNIC tiene una IP privada principal, y puede agregar y eliminar IP privadas secundarias. La dirección IP privada principal de una instancia no cambia durante el ciclo vital de la instancia y no se puede eliminar de la instancia. Para obtener más información, consulte Direcciones IP privadas.
IP PÚBLICA
Dirección de IPv4 pública e información relacionada. Opcionalmente, puede asignar una IP pública a sus instancias u otros recursos que tengan una IP privada. Las IP públicas pueden ser efímeras o reservadas. Para obtener más información, consulte Direcciones de IP públicas.
IPV6
Dirección de IPv6 e información relacionada. Las direcciones IPv6 están soportadas para todas las regiones comerciales y gubernamentales. Para obtener más información, consulte Direcciones IPv6.
GATEWAY DE ENRUTAMIENTO DINÁMICO (DRG)
Un enrutador virtual opcional que puede agregar a la VCN. Proporciona una ruta de acceso para el tráfico de red privado entre su red local y la VCN. Puede utilizarla con otros componentes de Networking y un enrutador en la red local para establecer una conexión mediante una VPN de sitio a sitio u Oracle Cloud Infrastructure FastConnect. También puede proporcionar una ruta de acceso para el tráfico de red privada entre la VCN y otra VCN de una región diferente. Para obtener más información, consulte Acceso a la red local, Gateways de enrutamiento dinámico e Intercambio de tráfico de VCN remoto mediante un DRG heredado.
GATEWAY DE INTERNET
Otro enrutador virtual opcional que puede agregar a la VCN para obtener un acceso directo a internet. Para obtener más información, consulte Acceso a internet y también Escenario A: subred pública.
GATEWAY DE TRADUCCIÓN DE DIRECCIONES DE RED (NAT)
Otro enrutador virtual opcional que puede agregar a la VCN. Ofrece recursos en la nube sin el acceso de direcciones IP públicas a internet, sin exponer dichos recursos a las conexiones de internet entrantes. Para obtener más información, consulte Subredes públicas frente a privada y Gateway de NAT.
GATEWAY DE SERVICIO
Otro enrutador virtual opcional que puede agregar a la VCN. Proporciona una ruta de acceso para el tráfico de red privado entre su VCN y los servicios admitidos en Oracle Services Network (ejemplos: Oracle Cloud Infrastructure Object Storage y Autonomous Database). Por ejemplo, los sistemas de base de datos de una subred privada de la VCN pueden realizar una copia de seguridad de los datos en Object Storage sin necesidad de direcciones IP públicas ni acceso a internet. Para obtener más información, consulte Acceso a Oracle Services: gateway de servicios.
GATEWAY DE INTERCAMBIO DE TRÁFICO LOCAL (LPG)
Otro enrutador virtual opcional que puede agregar a la VCN. Permite utilizar un intercambio de tráfico de VCN con otra VCN en la misma región. El intercambio de tráfico significa que las VCN se comunican mediante direcciones IP privadas, sin el tráfico que atraviesa internet ni el enrutamiento a través de su red local. Una VCN determinada debe tener un LPG independiente por cada intercambio de tráfico que establezca. Para obtener más información, consulte Intercambio de trafico de VCN local mediante gateways de intercambio de tráfico local.
CONEXIÓN CON INTERCAMBIO DE TRÁFICO REMOTO (RPC)
Componente que puede agregar a un DRG. Permite utilizar un intercambio de tráfico de VCN con otra VCN en una región diferente. Para obtener más información, consulte Intercambio de tráfico de VCN remoto mediante un DRG heredado.
TABLAS DE RUTAS
Tablas de rutas virtuales para la VCN. Tienen reglas para enrutar el tráfico desde subredes hasta destinos fuera de la VCN mediante gateways o instancias de configuración especial. La VCN incluye una tabla de rutas por defecto vacía, y es posible agregar sus propias tablas de rutas personalizadas. Para obtener más información, consulte Tablas de rutas de VCN.
REGLAS DE SEGURIDAD
Reglas del firewall virtual para la VCN. Son reglas de entrada y salida que especifican los tipos de tráfico (protocolo y puerto) cuya entrada y salida de las instancias se permite. Puede elegir si una regla determinada tiene estado o no. Por ejemplo, puede permitir el tráfico SSH entrante desde cualquier lugar a un conjunto de instancias mediante la configuración de una regla de entrada con estado con CIDR 0.0.0.0/0 de origen y el puerto 22 de TCP de destino. Para implantar reglas de seguridad, puede utilizar grupos de seguridad de red o listas de seguridad. Un grupo de seguridad de red consta de un conjunto de reglas de seguridad que se aplican solo a los recursos de ese grupo. Compárese con una lista de seguridad, donde las reglas se aplican a todos los recursos de cualquier subred que utilice la lista. La VCN incluye una lista de seguridad por defecto con reglas de seguridad también por defecto. Para obtener más información, consulte Reglas de seguridad.
OPCIONES DE DHCP
Información de configuración que se proporciona automáticamente a las instancias al iniciarse. Para obtener más información, consulte Opciones de DHCP.

Rangos de direcciones y tamaño de VCN permitidos

Una VCN abarca uno o más bloques de CIDR IPv4 o prefijos IPv6 de su elección. El rango de tamaño de la VCN permitido es de /16 a /30. Ejemplo: 10.0.0.0/16. El servicio de Networking reserva las dos primeras direcciones IP y la última en el CIDR de cada subred. Puede activar IPv6 para las VCN al crearlas o puede activar IPv6 en las VCN solo con IPv4 existentes. Si decide utilizar un prefijo IPv6 asignado por Oracle, recibirá siempre uno de /56. También puede importar su propio prefijo IPv6 BYOIP, desde el que puede asignar cualquier prefijo de /64 o mayor a una VCN, o bien puede asignar un prefijo ULA de /64 o mayor. Los rangos de GUA pueden ser de hasta 2000::/3 y los rangos de ULA pueden ser de hasta fc00::/7. Las subredes IPv6 siempre tienen un tamaño de /64.

Para la VCN, Oracle recomienda utilizar los rangos de direcciones IP privadas especificados en RFC 1918 (el RFC recomienda 10.0/8 o 172.16/12, pero Oracle no soporta esos tamaños, por lo que debe utilizar 10.0/16, 172.16/16 y 192.168/16). Sin embargo, puede utilizar un rango enrutable públicamente. Independientemente de esto, esta documentación utiliza el término dirección IP privada al hacer referencia a direcciones IP en el CIDR de su VCN. Los rangos de direcciones no permitidos se describen en Direcciones IP reservadas para el uso de Oracle. Para las VCN con IPv6 activado, Oracle puede asignar un prefijo de dirección unidifusión global /56 o puede crear una VCN con un prefijo BYOIPv6.

Los bloques de CIDR de la VCN no se deben solapar entre sí, con los CIDR de la red local ni con los CIDR de otra VCN con la que se intercambia tráfico. Las subredes de una VCN específica no se deben superponer entre sí. Como referencia, aquí dispone de una calculadora de CIDR.

Las direcciones IPv6 están soportadas para todas las regiones comerciales y gubernamentales. Para obtener más información, consulte Direcciones IPv6.

Dominios de disponibilidad y la VCN

La VCN reside en una sola región de Oracle Cloud Infrastructure. Una región puede tener varios dominios de disponibilidad para proporcionar aislamiento y redundancia. Para obtener más información, consulte Regiones y dominios de disponibilidad.

Las subredes originales se han diseñado para cubrir solo un dominio de disponibilidad (AD) en una región. Todas son específicas de AD, lo que significa que los recursos de la subred debían residir en un dominio de disponibilidad determinado. Ahora, las subredes pueden ser específicas de AD o regionales. Debe elegir el tipo al crear la subred. Ambos tipos de subredes pueden coexistir en la misma VCN. En el diagrama siguiente, las subredes 1-3 son específicas de AD y la subred 4 es regional.

En esta imagen se muestra una VCN con una subred regional y tres subredes específicas de AD.

Además de la eliminación de la restricción de AD, las subredes regionales se comportan de la misma manera que las subredes específicas de AD. Oracle recomienda utilizar subredes regionales porque son más flexibles. Facilitan la división eficiente de la VCN en subredes, al tiempo que su diseño se orienta a los fallos del dominio de disponibilidad.

Al crear un recurso como una instancia informática, puede elegir el dominio de disponibilidad en el que se ubicará el recurso. Desde un punto de red virtual, también debe seleccionar en qué VCN y subred estará la instancia. Puede elegir una subred regional o elegir una subred específica de AD que coincida con el AD que desea para la instancia.

Componentes por defecto que se incluyen con la VCN

La VCN incluye automáticamente estos componentes por defecto:

No puede suprimir estos componentes predeterminados. Sin embargo, puede cambiar su contenido (por ejemplo, las reglas de la lista de seguridad predeterminada). También puede crear sus propias versiones personalizadas de cada tipo de componente de la VCN. Existen límites en cuanto al número que se puede crear y el número máximo de reglas. Para obtener más información, consulte Límites de servicio.

Cada subred siempre tiene estos componentes asociados:

  • Una tabla de rutas
  • Una o más listas de seguridad (para el número máximo, consulte Límites de servicio)
  • Un conjunto de opciones de DHCP

Durante la creación de la subred, puede elegir qué tabla de rutas, lista de seguridad y conjunto de opciones de DHCP utiliza la subred. Si no especifica ningún componente concreto, la subred utiliza automáticamente el componente predeterminado de la VCN. Puede cambiar los componentes que utiliza la subred en cualquier momento.

Consejo

Las listas de seguridad son una forma de controlar el tráfico que entra y sale de los recursos de la VCN. También puede utilizar grupos de seguridad de red, lo que le permite aplicar un conjunto de reglas de seguridad a un conjunto de recursos que tengan el mismo poste de seguridad.

Opciones de conectividad

Puede controlar si las subredes son públicas o privadas y si las instancias obtienen direcciones IP públicas. Puede configurar la VCN de forma que tenga acceso a internet si lo desea. También puede conectar de forma privada la instancia de la VCN a servicios públicos de Oracle Cloud Infrastructure, como Object Storage, a otra red local o a otra VCN.

Subredes públicas frente a privadas

Cuando crea una subred, esta se considera pública por defecto, lo que significa que las instancias de esa subred pueden tener direcciones IPv4 públicas y que se permite la comunicación a través de internet con los puntos finales IPv6. El usuario que inicia la instancia elige si esta debe tener una dirección IPv4 pública o especifica si se asignará una dirección IPv6 del prefijo asignado. Puede sustituir ese comportamiento al crear la subred y solicitar que esta sea privada, que no permite el uso de direcciones IPv4 públicas ni la comunicación a través de internet con puntos finales IPv6. Por lo tanto, los administradores de la red pueden asegurarse de que las instancias de la subred no tengan acceso a internet, incluso si la VCN tiene un gateway de internet en funcionamiento, y las reglas de seguridad y las reglas de firewall permiten el tráfico.

Modo de asignación de las direcciones IP

Cada instancia tiene una VNIC principal creada durante el inicio de la instancia y no se puede eliminar. Puede agregar VNIC secundarias a una instancia existente (en el mismo dominio de disponibilidad que la VNIC principal) y eliminarlas según lo desee.

Cada VNIC tiene una dirección IP privada del CIDR de la subred asociada. Puede elegir la dirección IP específica (durante el inicio de instancia o la creación de VNIC secundaria), o bien Oracle puede hacerlo por usted. La dirección IP privada no cambia durante el ciclo vital de la instancia y no se puede eliminar. También puede agregar direcciones IPv4 privadas secundarias o direcciones IPv6 secundarias a una VNIC.

Si la VNIC está en una subred pública, cada IP privada de esa VNIC puede tener una dirección IPv4 pública o una dirección IPv6 asignada según considere oportuno. Para IPv4, Oracle elige la dirección IP específica. Para IPv6, puede especificar la dirección IP. Hay dos tipos de IP públicas: efímeras y reservadas. Una IP pública efímera solo existe durante el ciclo de vida de la IP privada a la que está asignada. Por el contrario, existe una IP pública reservada siempre que lo desee. Puede mantener grupo de IP públicas reservadas y asignárselas a las instancias a su discreción. Puede moverlas de un recurso a otro en una región cuando sea necesario.

Acceso a internet

Hay dos gateways opcionales (enrutadores virtuales) que puede agregar a la VCN en función del tipo de acceso a internet que necesite:

  • Gateway de internet: para los recursos con direcciones IP públicas que precisan el acceso desde internet (por ejemplo: un servidor web) o el inicio de conexiones a internet.
  • Gateway de NAT: para los recursos sin direcciones IP públicas que necesitan iniciar conexiones a internet (por ejemplo, para las actualizaciones de software), si bien es necesario protegerlas de las conexiones entrantes de internet.

Disponer solo de un gateway de internet no muestra las instancias de las subredes de la VCN directamente a internet. También deben cumplirse los requisitos siguientes:

Consejo

Para acceder a servicios públicos como Object Storage desde la VCN sin el tráfico que pasa por internet, utilice un gateway de servicios.

Además, tenga en cuenta que el tráfico a través de un gateway de internet entre una VCN y una dirección IP pública que forma parte de Oracle Cloud Infrastructure (como Object Storage) se enruta sin enviarse a través de Internet.

También puede otorgar a una subred acceso indirecto a internet mediante la configuración de un servidor proxy de internet en la red local y, a continuación, la conexión de esa red a la VCN mediante DRG. Para obtener más información, consulte Acceso a su red local.

Acceso a servicios públicos de Oracle Cloud Infrastructure

Puede utilizar un gateway de servicios con la VCN para permitir el acceso privado a servicios públicos de Oracle Cloud Infrastructure como Object Storage. Por ejemplo, los sistemas de base de datos de una subred privada de la VCN pueden realizar una copia de seguridad de los datos en Object Storage sin necesidad de direcciones IP públicas ni acceso a internet. No es necesario el gateway de internet ni NAT. Para obtener más información, consulte Acceso a Oracle Services: gateway de servicios.

Acceso a la red local

Hay dos formas de conectar la red local a Oracle Cloud Infrastructure:

  • VPN de sitio a sitio: ofrece varios túneles IPSec entre el perímetro de la red existente y la VCN, mediante un DRG que haya creado y asociado a la VCN.
  • Oracle Cloud Infrastructure FastConnect: ofrece una conexión privada entre el perímetro de la red existente y Oracle Cloud Infrastructure. El tráfico no atraviesa internet. Se admite tanto el intercambio de tráfico privado como público. Esto significa que los hosts locales pueden acceder a direcciones IPv4 o IPv6 privadas en la VCN, así como a direcciones IPv4 o IPv6 públicas regionales en Oracle Cloud Infrastructure (por ejemplo, Object Storage o equilibradores de carga públicos en la VCN).

Puede utilizar uno o ambos tipos de conexiones anteriores. Si utiliza ambos, puede utilizarlos simultáneamente o en una configuración redundante. Estas conexiones se aplican a la VCN mediante un único DRG que se crea y se conecta a la VCN. Sin esa asociación al DRG y una regla de ruta para el DRG, el tráfico no fluye entre la red local y la VCN. En cualquier momento, puede desasociar el DRG de la VCN, pero manteniendo todos los componentes restantes que forman el resto de la conexión. A continuación, puede volver a conectar el DRG o asociarlo a otra VCN.

Acceso a otra VCN

Puede conectar la VCN a otra VCN mediante una conexión privada que no requiera que tráfico pase por internet. En general, este tipo de conexión se denomina intercambio de tráfico de la VCN. Cada VCN debe tener componentes específicos para activar el intercambio de tráfico. Las VCN también deben tener políticas de IAM, reglas de rutas y reglas de seguridad específicas que permitan que se realice la conexión y que fluya el tráfico de red deseado a través de la conexión. Para obtener más información, consulte Acceso a otras VCN: intercambio de tráfico.

Conexión a Oracle Cloud Infrastructure Classic

Puede configurar una conexión entre su entorno de Oracle Cloud Infrastructure y el entorno de Oracle Cloud Infrastructure Classic. Esta conexión puede facilitar despliegues híbridos entre los dos entornos o la migración de Oracle Cloud Infrastructure Classic a Oracle Cloud Infrastructure. Para obtener más información, consulte Acceso a Oracle Cloud Infrastructure Classic.

Conexión a Microsoft Azure

Oracle y Microsoft han creado una conexión entre varios sistemas en la nube entre Oracle Cloud Infrastructure y Microsoft Azure en determinadas regiones. Esta conexión permite configurar cargas de trabajo en varias nubes sin el tráfico que se produce entre ellas al gestionarlo mediante internet. Para obtener más información, consulte Acceso a Microsoft Azure.

Conexión con otras nubes con Libreswan

Puede conectar la VCN a otro proveedor en la nube mediante la VPN de sitio a sitio con una VM de Libreswan como equipo local de cliente (CPE). Para obtener más información, consulte Acceso a otras nubes con Libreswan.

Escenarios de redes

En esta documentación se incluyen algunos escenarios básicos de red para ayudarle a comprender el servicio de Networking y, por lo general, cómo funcionan juntos los componentes. Consulte los temas siguientes:

Enrutamiento en tránsito

Los escenarios A-C muestran su red local conectada a una o más VCN mediante un DRG y FastConnect o la VPN de sitio a sitio, y accediendo solo a los recursos de esas VCN.

Los siguientes escenarios de enrutamiento avanzado proporcionan a la red local acceso más allá de los recursos en la VCN conectada. El tráfico pasa de la red local al DRG y, a continuación, se transmite a través del DRG a su destino. Consulte los temas siguientes:

  • Enrutamiento de tránsito dentro de una VCN de hub: su red local tiene acceso a varias VCN de la misma región a través de un único circuito virtual privado FastConnect o la VPN de sitio a sitio. El DRG y las VCN asociadas tienen una topología de hub y radios, con la red local conectada al DRG que actúa como hub. Las VCN radiales intercambian tráfico.
  • Acceso privado a los servicios de Oracle: su red local tiene acceso privado a los servicios de Oracle en Oracle Services Network mediante una VCN conectada y el gateway de servicio de la VCN. El tráfico no pasa por internet.

Regiones y dominios de disponibilidad

La VCN reside en una sola región de Oracle Cloud Infrastructure. Cada subred reside en un único dominio de disponibilidad (AD). Los dominios de disponibilidad están diseñados para proporcionar aislamiento y redundancia en la VCN, según se ilustra en el escenario B y el escenario C mencionados anteriormente. Por ejemplo, puede configurar el conjunto principal de subredes en un único AD y, a continuación, configurar un conjunto duplicado de subredes en un AD secundario. Los dos dominios de disponibilidad se aíslan entre sí en los centros de datos de Oracle; por lo tanto, si uno falla, se puede realizar una conmutación con el otro AD. Para obtener más información, consulte Regiones y dominios de disponibilidad.

Rangos de direcciones IP públicas

Para obtener una lista de rangos de IP públicas de Oracle Cloud Infrastructure, consulte Rangos de direcciones IP.

Direcciones IP reservadas para el uso de Oracle

Algunas direcciones IP están reservadas para el uso de Oracle Cloud Infrastructure, por lo que es posible que no puedan utilizarse en el esquema de numeración de direcciones.

169.254.0.0/16

Estas direcciones se utilizan para conexiones iSCSI a los volúmenes de inicio y de bloque, metadatos de instancia y otros servicios.

Clase D y Clase E

Todas las direcciones desde 224.0.0.0 hasta 239.255.255.255 (Clase D) están prohibidas para su uso en una VCN, ya que están reservadas para asignaciones de direcciones multidifusión en los estándares IP. Consulte RFC 3171 para obtener más información.

Todas las direcciones desde 240.0.0.0 hasta 255.255.255.255 (Clase E) están prohibidas para su uso en una VCN, ya que están reservadas para su uso futuro en los estándares IP. Consulte RFC 1112, Sección 4 para obtener más información.

Tres direcciones IP en cada subred

Estas direcciones constan de:

  • La primera dirección IP del CIDR (la dirección de red)
  • La última dirección IP del CIDR (la dirección de transmisión)
  • La primera dirección de host en el CIDR (la dirección del gateway predeterminada de la subred)

Por ejemplo, en una subred con CIDR 192.168.0.0/24, estas direcciones están reservadas:

  • 192.168.0.0 (la dirección de red)
  • 192.168.0.255 (la dirección de difusión)
  • 192.168.0.1 (la dirección de gateway predeterminada de la subred)

Las direcciones restantes del CIDR (192.168.0.2 a 192.168.0.254) están disponibles.

Creación de automatización con eventos

Puede crear la automatización basada en cambios de estado para los recursos de Oracle Cloud Infrastructure mediante el uso de tipos de eventos, reglas y acciones. Para obtener más información, consulte Visión general de eventos.

Identificadores de recursos

La mayoría de los tipos de recursos de Oracle Cloud Infrastructure tienen un identificador único asignado por Oracle denominado Oracle Cloud ID (OCID). Para obtener información sobre el formato de OCID y otras formas de identificar los recursos, consulte Identificadores de recursos.

Formas de acceder a Oracle Cloud Infrastructure

Puede acceder a Oracle Cloud Infrastructure (OCI) utilizando la consola (una interfaz basada en explorador), la API de REST o la CLI de OCI. A lo largo de esta documentación se incluyen temas con instrucciones para utilizar la consola, la API y la CLI. Para obtener una lista de los SDK disponibles, consulte Software development kits e interfaz de línea de comandos.

Para acceder a la Console, debe utilizar un explorador soportado. Para ir a la página de conexión de la consola, abra el menú de navegación situado en la parte superior de esta página y haga clic en Consola de Infrastructure. Se le solicitará que introduzca el inquilino en la nube, el nombre de usuario y la contraseña.

Para obtener información general sobre el uso de la API, consulte las API de REST.

Autenticación y autorización

Cada servicio de Oracle Cloud Infrastructure se integra con IAM con fines de autenticación y autorización para todas las interfaces (la consola, el SDK o la CLI, y la API de REST).

Un administrador de su organización precisa configurar grupos, compartimientos y políticas que controlan qué usuarios pueden acceder a qué servicios y recursos específicos, así como el tipo de acceso. Por ejemplo, las políticas controlan quién puede crear usuarios, crear y gestionar la red en la nube, iniciar instancias, crear cubos, descargar objetos, etc. Para obtener más información, consulte Introducción a las políticas. Para obtener detalles específicos sobre la escritura de políticas de los distintos servicios, consulte Referencia de políticas.

Si es un usuario normal (no un administrador) que necesita utilizar los recursos de Oracle Cloud Infrastructure que posee su compañía, póngase en contacto con el administrador para que configure su identificador de usuario. El administrador le confirmará qué compartimientos debe usar.

Políticas de IAM para Networking

El enfoque más sencillo para otorgar acceso al Networking es la política que se muestra en Permitir a los administradores de red gestionar una red en la nube. Abarca la red en la nube y todos los demás componentes de Networking (subredes, listas de seguridad, tablas de rutas, gateways y etc.). Además, para proporcionar a los administradores de red la capacidad de iniciar instancias (para probar la conectividad de red), consulte Permitir a los usuarios iniciar instancias informáticas.

Si es la primera vez que trabaja con políticas, consulte Introducción a las políticas y Políticas comunes.

Para obtener material de referencia para escribir políticas más detalladas para Networking, consulte Detalles para los servicios principales.

Tipos de recursos individuales

Si lo desea, puede crear políticas que se centren en tipos de recursos individuales (por ejemplo, solo listas de seguridad), en lugar del concepto más amplio virtual-network-family. El tipo de recurso instance-family también incluye varios permisos para las VNIC, que residen en una subred pero se conectan a una instancia. Para obtener más información, consulte Detalles de las combinaciones Verbo + Tipo de recurso y Tarjetas de interfaz de red virtual (VNIC).

Hay un tipo de recurso denominado local-peering-gateways que se incluye en virtual-network-family e incluye otros dos tipos de recursos relacionados con el intercambio de tráfico de la VCN local (dentro de la región):

  • local-peering-from
  • local-peering-to

El tipo de recurso local-peering-gateways abarca todos los permisos relacionados con gateways de intercambio de tráfico local (LPG). Los tipos de recursos local-peering-from y local-peering-to se utilizan para otorgar permisos para conectar dos LPG y definir una relación de intercambio de tráfico dentro de una sola región. Para obtener más información, consulte Intercambio de tráfico local mediante un LPG (VCN en el mismo arrendamiento) o Intercambio de tráfico local mediante un LPG (VCN en diferentes arrendamientos).

De manera similar, hay un tipo de recurso denominado remote-peering-connections incluido en virtual-network-family y que incluye otros dos tipos de recursos relacionados con el intercambio de tráfico remoto de VCN (entre regiones):

  • remote-peering-from
  • remote-peering-to

El tipo de recurso remote-peering-connections abarca todos los permisos relacionados con conexiones de intercambio de tráfico remoto (RPC). Los tipos de recursos remote-peering-from y remote-peering-to se utilizan para otorgar permisos para conectar dos RPC y definir una relación de intercambio de tráfico entre regiones. Para obtener más información, consulte Uso de intercambio de tráfico remoto con un DRG heredado y Uso de intercambio de tráfico remoto con un DRG actualizado.

Diferencias entre distintos verbos

Si lo desea, puede crear políticas que limiten el nivel de acceso mediante un verbo de política diferente (manage frente a use, etc.). Si se da el caso, existen algunas diferencias que deben comprenderse sobre los verbos de la política de Networking.

Tenga en cuenta que el verbo inspeccionar no solo devuelve información general sobre los componentes de la red en la nube (por ejemplo, el nombre y el OCID de una lista de seguridad o de una tabla de rutas). También incluye el contenido del componente (por ejemplo, las reglas reales de la lista de seguridad, las rutas de la tabla de rutas, etc.).

Además, los siguientes tipos de capacidades están disponibles solo con el verbo manage, no con el verbo use:

  • Actualizar (activar/desactivar) internet-gateways
  • Actualizar security-lists
  • Actualizar route-tables
  • Actualizar dhcp-options
  • Conecte un gateway de enrutamiento dinámico (DRG) a una red virtual en la nube (VCN)
  • Cree una conexión de IPSec entre un equipo de DRG y equipos locales de cliente (CPE)
  • VCN de peer
Importante

Cada VCN tiene varios componentes que afectan directamente al comportamiento de la red (tablas de rutas, listas de seguridad, opciones DHCP, Gateway de internet, etc.). Al crear uno de estos componentes, establezca una relación entre dicho componente y la VCN. Esto significará que debe permitir en una política tanto la creación del componente como la gestión de la propia VCN. Sin embargo, la capacidad de actualizar dicho componente (para cambiar las reglas de ruta, las reglas de la lista de seguridad, etc.) NO necesita permiso para gestionar la propia VCN, aunque el cambio de dicho componente pueda afectar directamente al comportamiento de la red. Se ha diseñado esta discrepancia para proporcionarle flexibilidad a la hora de otorgar menos privilegios a los usuarios y que no tenga que otorgar acceso excesivo a la VCN para que el usuario pueda gestionar otros componentes de la red. Tenga en cuenta que al otorgar a alguien la posibilidad de actualizar un tipo de componente en particular, está confiándole implícitamente el control del comportamiento de la red.

Para obtener más información sobre los verbos de política, consulte Aspectos básicos de políticas.

Políticas de intercambio de tráfico

Para conocer las políticas utilizadas para conectar un DRG a redes virtuales en la nube y DRG en otras regiones y arrendamientos, consulte Políticas de IAM para el enrutamiento entre redes virtuales en la nube.

Límites sobre los componentes de Networking

Consulte la sección Límites de servicio para obtener una lista de límites aplicables e instrucciones para solicitar un aumento del límite.