Preguntas frecuentes sobre la red virtual en la nube

Para obtener una lista completa de componentes, consulte Descripción general de las redes.

Para obtener un tutorial rápido sobre cómo iniciar una instancia dentro de una VCN en Oracle Cloud Infrastructure, consulte la Guía de inicio.

Consulte también estos temas:

1. Descripción general de las redes
2. VCN y subredes

Cuando crea su VCN, asigna un bloque CIDR IPv4 contiguo de su elección. Se permiten tamaños de VCN que van desde /16 (65 533 direcciones IP) a /30 (1 dirección IP). Ejemplo: 10.0.0.0/16, 192.168.0.0/24.

Recomendamos usar un bloque CIDR de los intervalos de direcciones privadas especificados por RFC1918. Si utiliza un bloque CIDR no RFC1918, tenga en cuenta que todavía se trata como un intervalo de direcciones IP privadas y no se puede enrutar desde Internet a través de la puerta de enlace de Internet de Oracle.

Puede crear subredes si subdivide el intervalo de direcciones de VCN en bloques IPv4 CIDR contiguos. El bloque CIDR de una subred debe caer dentro del bloque CIDR de la VCN. Cuando inicia una instancia en una subred, la dirección IP privada de la instancia se asigna desde el bloque CIDR de la subred.

Sí. Al crear una subred, puede especificar el tipo de acceso: privado o público. Se crea una subred con acceso público de forma predeterminada, en cuyo caso se puede asignar una dirección IP pública a las instancias de la subred. Las instancias iniciadas en una subred con acceso privado no pueden incluir direcciones IP públicas, lo que garantiza que estas instancias no tengan acceso directo a Internet.

Sí.

Las subredes pueden abarcar múltiples dominios de disponibilidad, pero no múltiples VCN. Si crea una subred regional, los recursos de la subred pueden residir en cualquier dominio de disponibilidad de la región. Sin embargo, si crea una subred específica del dominio de disponibilidad, los recursos de la subred deben residir en el dominio de disponibilidad particular de la subred.

Sí. No obstante, si tiene la intención de conectar una VCN a su red local o a otra VCN, le recomendamos asegurarse de que los intervalos de direcciones IP no se superpongan.

Para conocer los límites actuales de todos los servicios y las instrucciones para solicitar un aumento del límite de servicio, consulte la documentación de ayuda de Límites de servicio.

Sí. Puede modificar el nombre de la subred y cambiar la tabla de rutas, las listas de seguridad y el conjunto de opciones de DHCP que están asociados a ella. Sin embargo, el bloque CIDR de la subred no se puede cambiar.

La nueva funcionalidad está disponible en el dominio comercial. Estará disponible en otros dominios en el futuro.

La nueva funcionalidad está disponible en todas las regiones comerciales de Oracle Cloud Infrastructure (OCI).

Sí. Sin embargo, debe actualizar la DRG mediante el proceso de actualización que se especifica en la documentación.

Las comunicaciones entre asociaciones de DRG (incluidas las VCN) se controlan mediante tablas de rutas y sus políticas de importación asociadas. La tabla de rutas de asociación de VCN predeterminada permite que todas las VCN asociadas se comuniquen entre sí. Puede cambiar la política de importación asociada para lograr el aislamiento de las VCN como se muestra aquí.

Sí. Sin embargo, esto requiere que se configuren políticas específicas de IAM.

La DRG admite el enrutamiento dinámico y estático entre redes conectadas. La DRG tiene dos tablas de rutas predeterminadas. Una para sus asociaciones de conexión de intercambio de tráfico de FastConnect, red privada virtual (virtual private network, VPN) con seguridad del protocolo de Internet (Internet Protocol security, IPsec) y llamada a procedimiento remoto (remote procedure call, RPC) y otra para las asociaciones de VCN. Puede crear tablas de rutas adicionales para un control más detallado del flujo de tráfico entre los archivos adjuntos. Las rutas deciden la asociación de siguiente salto en función de la dirección IP de destino del paquete.

Las rutas estáticas tienen mayor preferencia que las dinámicas. No puede crear varias rutas estáticas para el mismo enrutamiento entre dominios sin clase (classless inter-domain routing, CIDR). En el caso de las rutas dinámicas, los conflictos se resuelven de la siguiente manera:

1. En el caso de las rutas destinadas a asociaciones de VCN: si se importan CIDR idénticos de dos asociaciones de VCN, se toma una decisión de reenvío determinista y uniforme sobre la preferencia de ruta. El cliente no puede controlar este orden de preferencia.
2. En el caso de las rutas destinadas a circuitos virtuales de FastConnect o VPN con IPsec: si se importan varias rutas con la misma longitud de ruta de AS y CIDR a una tabla de rutas de DRG y el enrutamiento de rutas múltiples de igual costo (Equal Cost Multi-Path, ECMP) está desactivado, se selecciona la ruta con la dirección IP de siguiente salto más baja. Si el ECMP está activado, se utilizarán ambas rutas, y el tráfico destinado al CIDR se enrutará mediante ECMP. Si las rutas tienen CIDR idénticos pero longitudes de ruta de AS diferentes, solo se utilizará la ruta con la longitud de ruta de AS más corta.
3. En el caso de las rutas destinadas a asociaciones de RPC/intercambio de tráfico: si se importan CIDR idénticos de dos asociaciones RPC/intercambio de tráfico, se utiliza el que tenga la longitud de ruta de AS más corta. Si las dos rutas tienen la misma longitud que la ruta de AS, se selecciona la ruta con la menor distancia de red. La distancia de red hace referencia al número de DRG que recorrerá la ruta. Si dos rutas tienen distancias de red idénticas, la selección se basará en el siguiente orden: {Static, VCN, VC, IPSec}). Si todavía hay un conflicto, Oracle enrutará el tráfico a través de la ruta más eficiente de su red interna.

Puede especificar cómo se importan y exportan las rutas por tabla de rutas modificando las políticas de importación y exportación asociadas. Las rutas se propagan de la siguiente manera:

1. Rutas propagadas a/desde redes locales: al conectar VPN de IPsec o circuitos virtuales de FastConnect a una DRG, las rutas se propagan entre la DRG y el enrutador local mediante el protocolo de puerta de enlace de borde (Border Gateway Protocol, BGP). Las VPN con IPsec también admiten el enrutamiento estático, pero para garantizar una conmutación por error automática óptima para la redundancia, la mejor práctica es utilizar el BGP.
2. Rutas propagadas desde VCN: al asociar una VCN a una DRG, la tabla de rutas de la asociación se actualizará automáticamente para incluir rutas a todas las subredes de la VCN y todos los CIDR de la tabla de rutas de entrada de la VCN asociada a la asociación de la VCN.
3. Rutas propagadas a las VCN: las rutas de DRG no se propagan automáticamente a su VCN. Debe crear rutas estáticas en las tablas de rutas de VCN para el tráfico destinado a redes locales u otras VCN de OCI. Estas tablas de rutas se gestionan como parte de la configuración de la VCN.

Puede conectar dos VCN de OCI con CIDR solapados a la misma DRG. La tabla de rutas del DRG toma una decisión de reenvío determinista y uniforme para determinar qué asociación de VCN es el siguiente salto para los CIDR de subred en conflicto. El cliente no puede controlar este orden de preferencia. Debido a la complejidad de controlar este comportamiento, no se recomiendan CIDR solapados.

Sí, la DRG ahora permite utilizar FastConnect en una región para comunicarse con los recursos de una VCN de otra región.

Puede encontrar más información sobre los límites y las cuotas en nuestra documentación.
Si necesita exceder estos límites, cree un caso de soporte.

Sí. La DRG admite la conexión de VCN con CIDR IPv6.

El comportamiento predeterminado de la DRG no ha cambiado. Debe activar explícitamente las nuevas funciones.

La DRG tiene dos tablas de rutas predeterminadas. Una para sus asociaciones de conexión de intercambio de tráfico de FastConnect, red privada virtual (virtual private network, VPN) con seguridad del protocolo de Internet (Internet Protocol security, IPsec) y llamada a procedimiento remoto (remote procedure call, RPC) y otra para las asociaciones de VCN. Estas dos tablas de rutas predeterminadas implementan el comportamiento de la DRG existente.

Cada VCN puede tener hasta 10 puertas de enlace de intercambio de tráfico locales y una DRG. Una única DRG admite hasta 300 asociaciones de VCN. Recomendamos utilizar la DRG si necesita conectarse con un gran número de VCN. Además, si desea tener un ancho de banda extremadamente alto y un tráfico de latencia muy baja entre dos VCN de la misma región, utilice el escenario descrito en Intercambio de tráfico de VCN local mediante puertas de enlace de intercambio de tráfico locales. Intercambiar tráfico entre dos VCN de la misma región a través de una DRG brinda más flexibilidad en el enrutamiento, pero conlleva el costo de una mayor latencia y un ancho de banda potencialmente menor.

El límite actual es de 8 rutas.

Consulte la sección “Actualización de una DRG” aquí.

Los servidores de los centros de datos de Oracle Cloud Infrastructure cuentan con tarjetas de interfaz de red (NIC) físicas. Cuando inicia una instancia en uno de estos servidores, la instancia se comunica mediante las NIC virtuales (VNIC) del servicio de red asociadas con las NIC físicas. Una VNIC permite que una instancia de computación se conecte a una VCN y determina cómo se comunica la instancia con los puntos finales dentro y fuera de la VCN.

Cada VNIC reside en una subred y tiene la siguiente configuración:

• Una dirección IPv4 privada principal de la subred en la que se encuentra la tarjeta de interfaz de red virtual (virtual network interface card, VNIC) asignada por usted o por Oracle.
• Hasta 31 direcciones IPv4 privadas secundarias de la subred en la que se encuentra la VNIC asignadas por usted o por Oracle.
• Una dirección IPv4 pública opcional para cada dirección IP privada.
• Un nombre de host opcional para DNS en cada dirección IP privada (consulte DNS en su red virtual en la nube).
• Una dirección MAC.
• Una etiqueta de VLAN asignada por Oracle que está disponible cuando se completa la asociación de la VNIC a la instancia (esto es solo relevante para instancias Bare Metal).

Para más información, consulte Tarjetas de interfaz de red virtual (VNIC).

Cada instancia de la VCN se crea con una VNIC, que tiene una dirección IP privada (asignada por ti o por Oracle) desde la subred proporcionada en la creación de la instancia, y una dirección IP pública correspondiente. Esta VNIC se conoce como VNIC principal, y su dirección IP privada, como dirección IP privada principal.

La VNIC primaria no se puede separar de la instancia. Se elimina automáticamente cuando finaliza la instancia.

Cada instancia de la VCN tiene al menos una VNIC, que es su VNIC primaria. Puede asociar a una instancia VNIC adicionales, denominadas VNIC secundarias. Las VNIC secundarias pueden pertenecer a diferentes VCN o subredes.

El límite de VNIC que se pueden asociar a una instancia varía según la forma. Para conocer esos límites, consulte la documentación de soporte de Formas de computación.

Sí. Consulte el servicio de metadatos de instancia disponible en http://169.254.169.254/opc/v1/vnics/.

Sí. En el caso de la VNIC primaria, puede especificar la dirección IP privada al iniciar la instancia. En el caso de las VNIC secundarias, puede especificar una dirección IP privada cuando asocie la VNIC a una instancia. La dirección IP privada especificada debe pertenecer a la misma subred que la VNIC y no debe estar en uso.

No. Actualmente, las VNIC siempre están vinculadas a la instancia y no existen de forma independiente. La VNIC primaria se crea y se destruye a la vez que la instancia. Todas las VNIC secundarias se crean y se destruyen cuando se conectan y se desconectan, respectivamente.

Sí. No obstante, asociar múltiples VNIC del mismo bloque CIDR de subred a una instancia puede introducir un enrutamiento asimétrico, especialmente en las instancias que utilizan una variante de Linux. Si necesita este tipo de configuración, Oracle recomienda asignar varias direcciones IP privadas a una VNIC o usar el enrutamiento basado en políticas. Para obtener un ejemplo, consulte el script en Linux: configuración del sistema operativo para VNIC secundarias.

No. Todas las VNIC deben pertenecer a subredes que estén en el mismo dominio de disponibilidad que la instancia. Cuando se utilizan subredes regionales, las VNIC deben crearse en el mismo dominio de disponibilidad que la instancia.

Sí. Puede asociar VNIC secundarias que pertenezcan a una subred de una VCN diferente a la VCN de la VNIC primaria.

Cada instancia de computación de su VCN se crea con una tarjeta de interfaz de red virtual (VNIC) y se le asigna una dirección IP privada desde la subred proporcionada en el inicio de la instancia. Estas son la VNIC primaria y la dirección IP privada primaria, respectivamente. También puedes asociar a una instancia VNIC adicionales, denominadas VNIC secundarias, que también tienen una dirección IP privada primaria.

Puede dejar que Oracle elija la dirección IP privada o puede elegirla del grupo disponible de la subred. Si la dirección que especifique ya está en uso, la solicitud de inicio fallará.

Además, puedes asignar direcciones IP privadas secundarias a una VNIC. De forma similar a las direcciones IP privadas primarias, una dirección IP privada secundaria proporciona conectividad a destinos dentro de su VCN o en sus instalaciones (cuando hay conectividad a través de VPN u Oracle Cloud Infrastructure FastConnect).

Sí. Puede mover una dirección IP privada secundaria de una VNIC en una instancia a una VNIC en otra instancia, siempre que ambas VNIC pertenezcan a la misma subred y la autorización permita la operación. Cuando se utilizan subredes regionales, la IP privada secundaria también se puede mover a una VNIC en un dominio de disponibilidad diferente.

Actualmente, puede asignar hasta 31 direcciones IP privadas secundarias a una VNIC.

No. El sistema operativo no puede descubrir la dirección IP privada secundaria con mecanismos como DHCP. Debe configurar las direcciones IP privadas secundarias mediante un procedimiento específico del sistema operativo. Para obtener más información, consulte los scripts proporcionados en Tarjetas de interfaz de red virtual (VNIC).

Una dirección IP pública es una dirección IPv4 a la que se puede acceder desde Internet (una dirección IP enrutable por Internet). Una instancia de su VCN se comunica con los hosts en Internet a través de una dirección IP pública. Una dirección IP privada no es enrutable por Internet. Las instancias dentro de VCN se comunican entre sí mediante direcciones IP privadas.

Puede asignar una dirección IP pública a una dirección IP privada de una instancia de computación o a una instancia de equilibrador de carga, y permitir que se comuniquen con Internet. Para que una dirección IP pública sea accesible a través de Internet, la VCN donde se encuentra debe tener una puerta de enlace de Internet, y las tablas de rutas y listas de seguridad de la subred pública deben configurarse en consecuencia.

Hay dos tipos de direcciones IP públicas:

• Direcciones IP públicas efímeras: piense que son temporales y que existen durante toda la vida de la instancia. A petición suya, Oracle asignará una del grupo de direcciones IP públicas disponibles de Oracle. Esta dirección IP pública está vinculada al ciclo de vida de la dirección IP privada. Si desasigna la dirección IP pública explícitamente o desasigna la dirección IP privada de la VNIC, o bien si finaliza la instancia correspondiente, esta dirección IP pública se libera al grupo disponible. Si luego solicita asignar una dirección IP pública nuevamente, puede ser una dirección diferente a la anterior.
• Direcciones IP públicas reservadas: piense que son direcciones IP públicas flotantes que residen en el compartimento que elija. Son persistentes y existen más allá de la vida útil de las instancias a las que están asignadas. Pertenecen a una región específica. Puede mantener una dirección IP pública reservada sin asignar dentro de su compartimento o asignarla a una dirección IP privada de una instancia o a un equilibrador de carga dentro de la misma región en la que se creó. También puede moverla a cualquier otra dirección IP privada dentro de la misma región.

Para obtener más detalles y una tabla en la que se comparan los dos tipos, consulte la documentación de ayuda de Direcciones IP públicas.

Una dirección IP pública se convierte en la identidad de su servicio para los clientes que no pueden usar el FQDN de DNS. Una dirección IP pública reservada le permite mantener esta identidad independientemente de cualquier cambio en los recursos subyacentes. Aquí hay un par de escenarios específicos que pueden beneficiarse al usar una dirección IP pública reservada:

• Aísle a sus clientes de cualquier fallo específico de la instancia: puede asignar una dirección IP pública reservada a su instancia y moverla fácilmente a otra instancia si se produce un fallo. Sus clientes están aislados de este cambio mientras continúan conectándose a la misma dirección IP pública.
• Optimización del uso de recursos informáticos sin impacto para los usuarios: tanto si desea cambiar el tamaño de una instancia como finalizar las instancias basándose en los patrones de uso para ahorrar costos, una dirección IP pública reservada le permite exponer la misma dirección IP pública a sus clientes.

Puede asignar solo una dirección IP pública reservada a cualquier dirección IP privada (primaria o secundaria). Sin embargo, puede asignar múltiples direcciones IP privadas a cada VNIC asociada a su instancia. Luego puede asignar una dirección IP pública reservada a cada una de estas direcciones IP privadas.

Existe un límite en cuanto a la cantidad máxima de direcciones IP públicas reservadas que puede crear en su tenencia. Consulte la documentación de ayuda de Límites de servicio.

Puede asignar solo una dirección IP pública efímera a cualquier dirección IP privada primaria de la VNIC. Sin embargo, puede crear y asociar múltiples VNIC a su instancia. Luego puede asignar una dirección IP privada efímera a cada una de las direcciones IP primarias de cada VNIC.

Existe un límite en cuanto al número máximo de direcciones IP públicas efímeras que se pueden asignar a una instancia. Consulte la documentación de ayuda de Límites de servicio.

Sí, pero solo si está asignada a una IP secundaria privada en una VNIC. Si mueve esa IP privada secundaria a una VNIC diferente (que debe estar en la misma subred), la IP pública efímera va con ella.

Sí, y puede moverla de un dominio de disponibilidad o una VCN a otro. Las VCN deben estar en la misma región.

Hay dos formas de mover una IP pública reservada:

• Anule la asignación de la IP pública reservada y luego vuelva a asignarla a otra IP privada. La IP privada puede estar en una VNIC de un dominio de disponibilidad o una VCN diferentes a los de la VNIC original.
• Si la IP pública reservada se asigna a una IP privada secundaria, puede mover la IP privada a una VNIC diferente (que debe estar en la misma subred) y la IP pública reservada va con ella.

Cuando se anula la asignación explícitamente. Y al hacer lo siguiente:

• Cuando elimina una dirección IP privada, se libera su dirección IP pública efímera correspondiente.
• Cuando separa una VNIC secundaria, se liberan las direcciones IP públicas efímeras correspondientes.
• Cuando finaliza la instancia, se liberan las direcciones IP efímeras correspondientes.

Tenga en cuenta que cuando reinicia la instancia, no hay impacto en las direcciones IP públicas efímeras correspondientes.

Solo ve la dirección IP privada de su instancia de computación. Si se asigna una dirección IP pública a la instancia, el servicio de red proporciona una NAT individual (NAT estática) entre las direcciones IP privadas y públicas cuando la instancia intenta comunicarse con un destino en Internet (a través de la puerta de enlace de Internet).

En el nivel del sistema operativo de la instancia, solo verá la dirección IP privada de la VNIC asociada a la instancia. Cuando se recibe el tráfico enviado a la dirección IP pública, el servicio de red realiza una traducción de la dirección de red (NAT) de la dirección IP pública a la dirección IP privada correspondiente. El tráfico se muestra dentro de la instancia con la dirección IP de destino establecida en la dirección IP privada.

No. El servicio de red asigna la dirección MAC.

Sí. Es compatible con IPv6. Para más información, consulte Direcciones IPv6.

No, actualmente no.

No, actualmente no.

Bring your own IP (BYOIP) le permite importar bloques IPv4 CIDR enrutables públicamente a Oracle Cloud Infrastructure para que sus recursos puedan usarlos.

Las direcciones IP son activos que una organización gestiona y controla cuidadosamente. Algunas aplicaciones requieren una buena reputación de IP para enviar correo, otras han establecido políticas de accesibilidad en despliegues globales y otras cumplen los estándares en la arquitectura de sus direcciones IP. La migración de un prefijo IP desde una infraestructura on-premises a OCI le permite minimizar el impacto en sus clientes y aplicaciones a la vez que aprovecha todos los beneficios de Oracle Cloud Infrastructure. BYOIP en OCI le permitirá minimizar el tiempo de inactividad durante la migración al anunciar simultáneamente el prefijo de su dirección IP desde OCI y retirarlo del entorno on-premises.

El proceso de mover un prefijo IP para su uso en OCI comienza en el portal, en Redes>Gestión de IP, o puede iniciarse a través de la API. Solo hay que seguir unos pocos pasos sencillos.

  1 - Inicie la solicitud para traer un CIDR de IP a OCI (el CIDR de IP debe ser /24 o mayor y pertenecer a su organización).
  2 - Registre un token de validación generado a partir de la solicitud con el servicio de registro regional de Internet (regional Internet registry, RIR) (ARIN, RIPE o APNIC). Siga los pasos de la documentación.
  3. Después de registrar su token, vuelva a la consola y haga clic en “Validar bloque CIDR” para que Oracle pueda completar el proceso de validación. Oracle valida que su bloque CIDR se haya registrado correctamente para la transferencia y aprovisiona su BYOIP. Este paso puede tardar hasta 10 días hábiles. Se le notificará por correo electrónico cuando el proceso finalice. También puede comprobar el progreso de este paso en sus solicitudes de trabajo.

¿Qué se hace con el token de validación emitido por Oracle? Como parte de la importación de un bloque CIDR de BYOIP, Oracle emite un token de validación. Una vez que tenga su token, deberá modificarlo ligeramente, añadiendo la información que se muestra a continuación. Puede utilizar cualquier editor de texto para ello.

OCITOKEN:: <CIDRblock> : <validation_token>

Para enviar el token de validación a su RIR (Registro regional de Internet).

ARIN: agregue la cadena de token modificada en la sección “Comentarios públicos” de su rango de direcciones. No la agregue en la sección de comentarios de su organización.
RIPE: agregue la cadena de token modificada como un nuevo campo “descr” para su rango de direcciones. No la agregue en la sección de comentarios de su organización.
APNIC: agréguela al campo “Comentarios” para su rango de direcciones enviando por correo electrónico la cadena de token modificada a helpdesk@apnic.net. Envíe el correo electrónico utilizando el contacto autorizado de APNIC para las direcciones IP.

Una vez que el CIDR de IP se valida, tienes control total de él. Para gestionar el prefijo, divídalo en grupos de IP menores y cree direcciones IP reservadas para usarlas con sus recursos.

Puede asignar direcciones BYOIP para instancias de computación, puerta de enlace NAT y LBaaS. Puede gestionar el espacio IP mediante grupos de IP y crear direcciones IP reservadas.

Una vez que el prefijo IP se incorpora a OCI, usted controla el anuncio y la retirada del prefijo.

La validación y el aprovisionamiento de BYOIP pueden tardar hasta 10 días laborales. Se le notificará por correo electrónico cuando el proceso finalice.

No. El prefijo BYOIP está asignado a una región específica de OCI y solo se anunciará en la región en la que se ha incorporado.

El prefijo mínimo para BYOIP es /24 y el máximo es /8. No es necesario que lleve a OCI todo su espacio IP. Si tiene un bloque de IP mayor, puede elegir los prefijos que lleva a OCI.

Una vez incorporado el prefijo, controlas la distribución de las direcciones y la política dentro de tu cliente de OCI. Puede mantener el prefijo en un grupo de IP o rebajarlo hasta /28 para usarlo con sus recursos de OCI.

Sí. Puede crear direcciones IP reservadas a partir de un prefijo BYOIP. Consulte más información en “Direccionamiento IP” aquí: https://www.oracle.com/cloud/networking/virtual-cloud-network-faq.html

La prestación BYOIP solo admite prefijos IPv4.

Sí. Puede seguir usando direcciones IP reservadas y efímeras propiedad de Oracle junto con sus propias direcciones IP. Se aplican los límites estándar a las direcciones de Oracle.

Las instancias pueden conectarse a:

• Internet (a través de una puerta de enlace de Internet)
• Su centro de datos local mediante una conexión VPN IPSec o FastConnect (a través de una puerta de enlace de enrutamiento dinámico)
• Instancias en VCN interconectadas (en la misma región o en otra)
• Servicios de Oracle Cloud Infrastructure como Object Storage, ADW (a través de una puerta de enlace del servicio)

Una puerta de enlace de Internet es un enrutador tolerante a fallos, altamente disponible y definido por software que proporciona conectividad pública a Internet para los recursos dentro de su VCN. Al usar una puerta de enlace de Internet, una instancia de computación que tenga asignada una dirección IP pública puede comunicarse con hosts y servicios en Internet.

En lugar de utilizar una puerta de enlace de Internet, puede conectar la VCN al centro de datos local, desde donde el tráfico a Internet se puede enrutar a través de los puntos de salida de la red existente.

Una puerta de enlace NAT es un enrutador fiable y de alta disponibilidad que proporciona conectividad de Internet solo de salida para los recursos dentro de la VCN. Con una puerta de enlace NAT, las instancias privadas (con solo una dirección IP privada) pueden iniciar conexiones a hosts y servicios en Internet, pero no recibir conexiones entrantes iniciadas desde Internet.

No. El límite predeterminado es una puerta de enlace NAT por cada VCN. Esperamos que esto sea suficiente para la gran mayoría de las aplicaciones.

Si deseas asignar más de una puerta de enlace NAT en una VCN específica, solicita un aumento de límite. Para obtener instrucciones sobre cómo solicitar un aumento de los límites, consulte Límites de servicio.

Las instancias obtienen el mismo rendimiento con la puerta de enlace NAT que cuando el tráfico se enruta a través de una puerta de enlace de Internet. Además, un flujo de tráfico único a través de la puerta de enlace NAT está limitado a 1 Gbps (o menos para las formas de instancias pequeñas).

Sí. Hay un límite de aproximadamente 20 000 conexiones simultáneas a un solo puerto y dirección IP de destino. Este límite es la suma de todas las conexiones iniciadas por instancias a través de la VCN que utilizan la puerta de enlace NAT.

Una puerta de enlace de enrutamiento dinámico es un enrutador tolerante a fallos, altamente disponible y definido por software que se puede agregar a una VCN. Proporciona una ruta privada para el tráfico entre la VCN y otras redes fuera de la región de la VCN, como tu centro de datos local o una VCN interconectada en otra región. Para conectar la VCN con tu centro de datos local, puedes configurar una VPN IPSec o FastConnect para la DRG de VCN. La conexión permite que sus hosts e instancias locales se comuniquen de forma segura.

Este objeto se utiliza si configura una VPN IPSec. Es una representación virtual del enrutador real que se encuentra en las instalaciones de su sitio, al final de la VPN. Cuando cree este objeto como parte de la configuración de una VPN IPSec, especifique la dirección IP pública de su enrutador local.

No. Solo necesita aprovisionar una DRG, asociarla a su VCN, configurar el objeto CPE y la conexión IPSec y configurar las tablas de rutas.

Consulte la lista de configuraciones de dispositivos probados.

Sí. Puede usarlo si lo configura de acuerdo con la información de configuración de CPE genérico. Admitimos múltiples opciones de configuración para maximizar la interoperabilidad con diferentes dispositivos VPN.

Oracle aprovisiona dos túneles VPN como parte de la conexión IPSec. Asegúrese de configurar ambos túneles en su CPE para redundancia.

Además, puedes implementar dos enrutadores CPE en tu centro de datos local con cada uno configurado para ambos túneles.

VPN IPSec es un estándar abierto y las VPN IPSec de software pueden interoperar con Oracle Cloud Infrastructure. Debe verificar que su VPN IPSec de software admita al menos un parámetro IPSec Oracle compatible en cada grupo de configuración de acuerdo con la información de configuración de CPE genérico.

Sí. El tráfico entre dos direcciones IP públicas de OCI de la misma región permanece dentro de la región de OCI. El tráfico entre direcciones IP públicas de OCI de diferentes regiones viaja a través de la red troncal privada de OCI. En cualquier caso, el tráfico no atraviesa Internet. Puede encontrar la lista completa de direcciones IP públicas de OCI aquí: https://docs.cloud.oracle.com/en-us/iaas/tools/public_ip_ranges.json.

Oracle Services Network es una red conceptual de Oracle Cloud Infrastructure que está reservada para los servicios de Oracle. La red comprende una lista de bloques CIDR regionales. Cada servicio de Oracle Services Network expone un punto final de servicio que usa direcciones IP públicas de la red. Actualmente hay una gran cantidad de servicios de Oracle disponibles en esta red (consulte la lista completa) y se agregarán más servicios en el futuro a medida que se implementen en Oracle Cloud Infrastructure.

Una puerta de enlace de servicio permite que los recursos de su VCN accedan de manera privada y segura a los servicios de Oracle en Oracle Services Network, como Oracle Cloud Infrastructure Object Storage, ADW y ATP. El tráfico entre una instancia de la VCN y un servicio de Oracle compatible utiliza la dirección IP privada de la instancia para el enrutamiento, viaja a través del tejido de Oracle Cloud Infrastructure y nunca atraviesa Internet. Al igual que la puerta de enlace de Internet o la puerta de enlace NAT, la puerta de enlace de servicio es un dispositivo virtual que tiene un alto grado de disponibilidad y se escala dinámicamente para admitir el ancho de banda de red de la VCN.

Actualmente, puede configurar la puerta de enlace de servicio para acceder a los servicios de Oracle en Oracle Services Network. Actualmente hay una gran cantidad de servicios de Oracle disponibles en esta red (consulte la lista completa) y se agregarán más servicios en el futuro a medida que se implementen en Oracle Cloud Infrastructure.

• Cree una puerta de enlace de servicio para la VCN.
• Actualice el enrutamiento VCN para reenviar todo el tráfico de los servicios de Oracle a Oracle Services Network mediante la puerta de enlace de servicio, en lugar de usar la puerta de enlace de Internet o la puerta de enlace NAT.

Para obtener instrucciones, consulte la sección de Acceso a Object Storage: puerta de enlace de servicio. Tenga en cuenta que la puerta de enlace de servicio permite el acceso a los servicios de Oracle dentro de la región para proteger sus datos en Internet. Es posible que sus aplicaciones requieran acceso a los puntos finales o servicios públicos que la puerta de enlace de servicio no admite, por ejemplo, para actualizaciones o parches. Asegúrese de tener una puerta de enlace NAT u otro acceso a Internet si es necesario.

La puerta de enlace de servicio utiliza el concepto de etiqueta CIDR de servicio, que es una cadena que representa todos los intervalos de direcciones IP públicas regionales para el servicio o un grupo de servicios (por ejemplo, OCI IAD Services en Oracle Services Network es la etiqueta que asigna a los bloques CIDR regionales en la red de servicios de Oracle en us-ashburn-1). La etiqueta CIDR del servicio se utiliza al configurar la puerta de enlace de servicio y las reglas de ruta y de seguridad. Para obtener instrucciones, consulte la sección de Acceso a Oracle Services: puerta de enlace de servicio.

No. La puerta de enlace de servicio es regional y solo se puede acceder a los servicios que se ejecutan en la misma región.

Sí. Si está utilizando una puerta de enlace de servicio, puede definir una política de IAM que permita el acceso a un depósito solo si las solicitudes provienen de un intervalo específico de VCN o CIDR. La política de IAM solo funciona para el tráfico enrutado a través de la puerta de enlace de servicio. El acceso se bloquea si la política de IAM está en su lugar y el tráfico pasa a través de una puerta de enlace a Internet. Además, tenga en cuenta que la política de IAM le impide acceder al depósito a través de la consola. El acceso solo se permite mediante programación desde los recursos de la VCN.

Para obtener una política de IAM de ejemplo, consulte la sección de Acceso a Object Storage: puerta de enlace de servicio.

No. Una VCN solo puede tener una puerta de enlace de servicio en este momento.

No. Una VCN interconectada con otra VCN que tiene una puerta de enlace de servicio no puede usar esa puerta de enlace de servicio para acceder a los servicios de Oracle.

No. Sin embargo, puede usar la interconexión pública FastConnect para hacer esto (sin pasar por Internet).

No. Con la puerta de enlace de servicio, las instancias obtienen el mismo rendimiento que cuando el tráfico se enruta a través de una puerta de enlace de Internet.

La puerta de enlace de servicio es gratuita para todos los clientes de Oracle Cloud Infrastructure.

Una lista de seguridad proporciona un cortafuegos virtual para una instancia, con reglas de entrada y salida que especifican los tipos de tráfico permitidos dentro y fuera de la instancia. Puede proteger su instancia de computación utilizando listas de seguridad. Configure sus listas de seguridad en el nivel de subred, lo que significa que todas las instancias en la subred están sujetas al mismo conjunto de reglas de la lista de seguridad. Las reglas se aplican en el nivel de instancia y controlan el tráfico en el nivel de paquete.

Una VNIC dada en una instancia está sujeta a las listas de seguridad asociadas con la subred de la VNIC. Cuando cree una subred, especifique una o más listas de seguridad para asociarlas con ella. Esto puede incluir la lista de seguridad predeterminada de la VCN. Si no especifica al menos una lista de seguridad durante la creación de la subred, la lista de seguridad predeterminada de la VCN se asocia con la subred. Las listas de seguridad están asociadas a nivel de subred, pero las reglas se aplican al tráfico de la VNIC a nivel de paquete.

Sí. Puede editar las propiedades de la subred para agregar o eliminar listas de seguridad. También puede editar las reglas individuales en una lista de seguridad.

Existe un límite en cuanto al número de listas de seguridad que puede crear, al número de listas que puede asociar a una subred y al número de reglas que puede agregar a una lista determinada. Para conocer los límites de servicio actuales y las instrucciones sobre cómo solicitar un aumento en los límites, consulte la documentación de ayuda de Límites de servicio.

No. Las listas de seguridad solo usan reglas de "permitir". Todo el tráfico se deniega de manera predeterminada y solo se permite el tráfico de red que coincida con los atributos especificados en las reglas.

Cada regla tiene estado o no tiene estado, y puede ser una regla de entrada o de salida.

Mediante las reglas con estado, una vez que se permite un paquete de red que coincide con la regla, se utiliza el seguimiento de la conexión y todos los paquetes de red adicionales que pertenecen a esta conexión se permiten automáticamente. Por lo tanto, si crea una regla de ingreso con estado, tanto el tráfico entrante que coincide con la regla como el tráfico saliente (respuesta) correspondiente están permitidos.

Con reglas sin estado, solo se permiten los paquetes de red que coinciden con la regla. Por lo tanto, si crea una regla de ingreso sin estado, solo se permite el tráfico entrante. Debe crear una regla de salida sin estado correspondiente para que coincida con el tráfico de salida (respuesta) correspondiente.

Para más información, consulte la documentación de soporte de Listas de seguridad.

Los grupos de seguridad de red y las listas de seguridad son dos formas diferentes de implementar reglas de seguridad, que son reglas que controlan el ingreso permitido y el tráfico de salida hacia y desde las VNIC.

Las listas de seguridad le permiten definir un conjunto de reglas de seguridad que se aplican a todas las VNIC en una subred dada. Los grupos de seguridad de red (NSG) le permiten definir un conjunto de reglas de seguridad que se aplican a un grupo de VNIC de su elección. Por ejemplo, un grupo de instancias informáticas que tienen la misma estrategia de seguridad.

Para obtener más información, consulte:

• Reglas de seguridad
• Grupos de seguridad de red

No. Todo el tráfico se deniega de forma predeterminada. Las reglas de seguridad solo permiten el tráfico. El conjunto de reglas que se aplica a una VNIC determinada es la unión de estos elementos:

• Las reglas de seguridad en las listas de seguridad asociadas con la subred de la VNIC.
• Las reglas de seguridad en todos los NSG en los que se encuentra la VNIC.

Computación, equilibrio de carga y servicios de bases de datos. Esto significa que, cuando crea una instancia de computación, un equilibrador de carga o un sistema de base de datos, puede especificar uno o más grupos de seguridad de red para controlar el tráfico de esos recursos.

Con la introducción de los NSG, no hay cambios en el comportamiento de la lista de seguridad. La VCN todavía tiene una lista de seguridad predeterminada que puede usar opcionalmente con las subredes de la VCN.

Al escribir reglas para un NSG, tiene la opción de especificar un NSG como origen del tráfico (para las reglas de entrada) o como destino del tráfico (para las reglas de salida). La capacidad de especificar un NSG significa que puede escribir fácilmente reglas para controlar el tráfico entre dos NSG diferentes. Los NSG deben estar en la misma VCN.

No. Cuando escribe una regla de seguridad de NSG que especifica otro NSG como origen o destino, ese NSG debe estar en la misma VCN. Esto es cierto incluso si el otro NSG está en una VCN interconectada diferente de la lista de seguridad.

Las listas de seguridad le permiten definir un conjunto de reglas de seguridad que se aplican a todas las VNIC en una subred completa, mientras que los grupos de seguridad de red (NSG) le permiten definir un conjunto de reglas de seguridad que se aplican a un grupo de VNIC de su elección (incluidas las VNIC de los equilibradores de carga o sistemas de bases de datos) dentro de una VCN.

Una tabla de rutas de VCN contiene reglas para enrutar el tráfico que finalmente se destina a ubicaciones fuera de la VCN.

Cada regla de una tabla de rutas consta de un destino de ruta y un bloque CIDR de destino. Cuando el tráfico saliente de la subred coincide con el bloque CIDR de destino de la regla de ruta, el tráfico se enruta al destino de la ruta. Entre los ejemplos de destinos de rutas habituales se incluyen los siguientes: una puerta de enlace de Internet o una puerta de enlace de enrutamiento dinámico.

Para más información, consulte Tablas de rutas.

Una VNIC dada en una instancia está sujeta a la tabla de rutas asociadas con la subred de la VNIC. Cuando crea una subred, especifica una tabla de rutas para asociarla, que puede ser la tabla de rutas predeterminada de la VCN u otra que ya haya creado. Si no especifica una tabla de rutas durante la creación de la subred, la tabla de rutas predeterminada de VCN se asocia con la subred. La tabla de rutas está asociada a nivel de subred, pero las reglas se aplican al tráfico de la VNIC a nivel de paquete.

No. Actualmente, puede agregar una regla de ruta solo para un bloque CIDR que no se superpone con el espacio de direcciones de la VCN.

Sí. Puede editar las propiedades de subred para cambiar la tabla de rutas. También puede editar las reglas individuales en una tabla de rutas.

No, actualmente no.

Hay un límite en cuanto al número de reglas en una tabla de rutas. Consulte la documentación de ayuda de Límites de servicio.

Sí. Puede usar una IP privada como destino de una regla de ruta en situaciones en las que desea enrutar el tráfico de una subred a otra instancia en la misma VCN. Para conocer los requisitos y otros detalles, consulte Usar una IP privada como destino de ruta.

La interconexión de VCN es un proceso de conexión de dos VCN para permitir la conectividad privada y el flujo de tráfico entre ellas. Hay dos tipos generales de interconexión:

• Intercambio de tráfico de VCN local (o intercambio de tráfico dentro de la región): las dos VCN están en la misma región. Pueden estar en la misma tenencia (del mismo compartimento o de compartimientos diferentes) o en tenencias diferentes.
• Intercambio de tráfico de VCN remota (o intercambio de tráfico de VCN entre regiones): las dos VCN están en regiones diferentes.

Para obtener más información, consulte Acceso a otras VCN: intercambio de tráfico.

• La interconexión local de VCN (o interconexión dentro de la misma región) se admite en todas las regiones.
• Actualmente se admite la interconexión remota de VCN (o interconexión entre regiones). La lista de regiones admitidas se puede encontrar en la documentación del producto.

• Con la interconexión local de VCN, obtiene la flexibilidad para organizar sus recursos en VCN separadas y cumplir con los requisitos de gobernanza y presencia regional, al tiempo que permite la conectividad privada a través de estas VCN. Con la interconexión local de VCN entre tenencias, obtiene la flexibilidad para organizar sus recursos en VCN separadas de diferentes tenencias, al tiempo que permite la conectividad privada a través de estas VCN. También puede habilitar un modelo de proveedor de servicios al proporcionar acceso privado a sus servicios para múltiples VCN de consumidores (de diferentes tenencias) ubicadas en la misma región.
• Con la interconexión remota de VCN, obtiene la flexibilidad para organizar sus recursos en VCN separadas y cumplir con sus requisitos de gobernanza, de presencia en varias regiones y de enrutamiento dinámico, al tiempo que permite la conectividad privada entre estas VCN en diferentes regiones.

• Una alternativa fiable y sin costo a los modelos de conectividad como VPN que elimina las puertas de enlace de Internet, las IP públicas para las instancias, el cifrado y los cuellos de botella de rendimiento.
• Facilidad de habilitación de la interconexión entre dos VCN sin tiempo de inactividad programado.
• Conectividad privada para recursos en VCN interconectadas que utilizan los enlaces altamente redundantes del tejido de Oracle Cloud Infrastructure con ancho de banda y latencia predecibles.

Para obtener instrucciones, consulte Interconexión local de VCN.

No. Las dos VCN de una relación de interconexión local no pueden tener CIDR superpuestos.

Sí. Si la VCN-1 se interconecta con otras dos VCN (por ejemplo, VCN-2 y VCN-3), esas dos VCN (VCN-2 y VCN-3) pueden tener CIDR superpuestos.

Sí.

Una VCN determinada puede tener un máximo de diez interconexiones locales a la vez.

• Una alternativa fiable y de bajo costo a los modelos de conectividad como VPN que elimina las puertas de enlace de Internet, las IP públicas para las instancias, el cifrado y los cuellos de botella de rendimiento.
• Facilidad de habilitación de la interconexión entre dos VCN sin tiempo de inactividad programado.
• Conectividad privada para recursos en VCN interconectadas que utilizan los enlaces altamente redundantes de la red troncal de Oracle Cloud Infrastructure con ancho de banda y latencia predecibles.

No. Una interconexión remota se establece mediante una puerta de enlace de enrutamiento dinámico (DRG).

Para obtener instrucciones, consulte Interconexión remota de VCN.

No. Las dos VCN de una relación de interconexión remota no pueden tener CIDR superpuestos.

No. Si la VCN-1 se interconecta de forma remota con otras dos VCN (por ejemplo, VCN-2 y VCN-3), esas dos VCN (VCN-2 y VCN-3) no pueden tener CIDR superpuestos.

No.

Sí. El tráfico de interconexión remota de VCN se cifra mediante el cifrado de enlace estándar de la industria.

Una VCN determinada puede tener un máximo de diez interconexiones remotas a la vez.

Sí. Puede usar las tablas de rutas y las listas de seguridad de la VCN-A para controlar la conectividad con la VCN-B interconectada. Puede permitir la conectividad al intervalo completo de direcciones de VCN-B o limitarla a una o más subredes.

Sí. Una vez establecida la interconexión local o remota, las instancias en VCN-B pueden enviar tráfico al intervalo completo de direcciones de VCN-A. Sin embargo, puede limitar el acceso de las instancias en VCN-B a una subred específica en VCN-A mediante el uso de reglas de entrada apropiadas en las listas de seguridad de la subred.

No. El rendimiento y la latencia deben ser próximos a los de las conexiones dentro de la VCN. El tráfico sobre la interconexión local tiene una disponibilidad y restricciones de ancho de banda similares a las del tráfico entre instancias en una VCN.

La interconexión remota de VCN utiliza la red troncal entre regiones de Oracle Cloud Infrastructure, que está diseñada para ofrecer un rendimiento y unas características de disponibilidad superiores, y un SLA de disponibilidad del 99,5 % para la conectividad entre regiones. Como guía, Oracle proporciona un rendimiento superior a 75 Mbps y una latencia inferior a 60 ms entre regiones de EE. UU., a 80 ms entre la UE y EE. UU., a 175 ms entre EE. UU. y APAC y a 275 ms entre la UE y APAC.

• Intercambio de tráfico local (dentro de la misma región): sin cargo.
• Intercambio de tráfico remoto (entre regiones): el precio se basa en la transferencia de datos salientes. Consulte el último precio publicado para "Transferencia de datos salientes".

La solución de enrutamiento de tránsito de VCN (VTR) se basa en una topología de concentrador y radio que permite que la VCN central proporcione conectividad de tránsito entre varias VCN radiales (dentro de la región) y en las redes locales. Solo se requiere una única VPN FastConnect o IPSec (conectada a la VCN central) para que la red local se comunique con todas las VCN radiales.

Consulte las instrucciones en Configuración del enrutamiento de tránsito de VCN en la consola.

Actualmente, las VCN radiales pueden acceder a sus redes locales mediante la VCN central.

No. La solución de enrutamiento de tránsito de VCN solo admite la conectividad consolidada entre VCN en la misma región.

Sí. Tú lo controlas con la tabla de rutas asociada con la LPG en la VCN central. Puede configurar reglas de ruta restrictivas que especifiquen solo las subredes locales que desea poner a disposición de la VCN radial. Las rutas anunciadas a la VCN radial son las de la tabla de rutas y el CIDR de la VCN central.

Sí. Tú lo controlas con la tabla de rutas asociada con la DRG en la VCN central. Puede configurar reglas de ruta restrictivas que especifiquen solo las subredes de VCN radiales que desea poner a disposición de la red local. Las rutas anunciadas a la red local son las de la tabla de rutas y el CIDR de la VCN central.

Sí. La VCN central está limitada a un máximo de 10 interconexiones locales con VCN radiales.

Sí. Puede agregar una puerta de enlace de servicio a una VCN que esté conectada a su red local mediante FastConnect o VPN de sitio a sitio. Luego puede configurar las reglas de ruta en las tablas de rutas asociadas con la DRG y con la puerta de enlace de servicio de la VCN para dirigir el tráfico local a través de VCN a los servicios de Oracle de interés. Los hosts locales pueden usar sus IP privadas cuando se comunican con los servicios de Oracle y el tráfico no atraviesa Internet.

Para obtener más información, consulte Enrutamiento del tránsito: acceso privado a los servicios de Oracle.

Sí. Puede configurar el enrutamiento del tránsito a través de una IP privada en la VCN central. En este caso, el tráfico se enruta a una IP privada en la instancia del cortafuegos de la VCN central. La instancia de cortafuegos puede inspeccionar todo el tráfico entre la red local y las VCN radiales.

Si se enruta a través de una instancia de cortafuegos (o cualquier otro dispositivo virtual de red) en la VCN central, los límites de rendimiento se basan en las características de E/S del dispositivo virtual de red. Si el tráfico no se enruta a través de un dispositivo virtual de red —y se enruta directamente a través de las puertas de enlace de la VCN central—, no hay límites de rendimiento. Las puertas de enlace son dispositivos virtuales que están altamente disponibles y se escalan dinámicamente para admitir los requisitos de ancho de banda de la red.

El Protocolo de configuración dinámica de host (DHCP) proporciona un marco para pasar la información de configuración a los hosts en una red IP. Los parámetros de configuración y otra información de control se llevan a la instancia en el campo de opciones ( RFC 2132) del mensaje DHCP. Cada subred de una VCN puede tener un solo conjunto de opciones de DHCP asociadas.

Puede configurar dos opciones que controlan cómo las instancias de la VCN resuelven los nombres de host del sistema de nombres de dominio (DNS):

• Buscar dominio. Puede especificar un solo dominio de búsqueda.
• Tipo de DNS. Elija uno de los dos:
  • Resolución de Internet y de VCN (predeterminado).
  • Resolución personalizada (puedes especificar hasta tres servidores DNS de tu elección que tú mismo configures, administres y mantengas).

Al resolver una consulta DNS, el sistema operativo de la instancia utiliza los servidores DNS especificados con Tipo de DNS y agrega el dominio de búsqueda al valor que se consulta. Para obtener más información, consulte Opciones de protocolo de configuración dinámica de host (Dynamic Host Configuration Protocol, DHCP).

Sí. Puede editar las propiedades de subred para cambiar qué conjunto de opciones de DHCP usa la subred. También puede cambiar los valores de las opciones de DHCP.

Cuando inicia una instancia, puede especificar un nombre de host para la instancia, junto con un nombre para mostrar. Este nombre de host, combinado con el nombre de dominio de la subred, se convierte en el nombre de dominio completo (FQDN) de su instancia. Este FQDN es único dentro de la VCN y se resuelve en la dirección IP privada de su instancia. Para más detalles, consulte DNS en su red virtual en la nube.

Tenga en cuenta que, para especificar un nombre de host para la instancia, la VCN y la subred deben configurarse para habilitar los nombres de host DNS.

Cuando crea una VCN, puede especificar su etiqueta DNS. Esto, combinado con el dominio principal oraclevcn.com, se convierte en el nombre de dominio de la VCN.

Cuando crea una subred, puede especificar su etiqueta DNS. Esto, combinado con el nombre de dominio de VCN, se convierte en el nombre de dominio de la subred.

Puede habilitar un nombre de host para una instancia de computación solo si el VCN y la subred se crean con una etiqueta DNS.

Un nombre de host DNS es un nombre que corresponde a la dirección IP de una instancia conectada a una red. En el caso de una VCN de Oracle Cloud Infrastructure, cada instancia se puede configurar con un nombre de host DNS que corresponda a la dirección privada de la instancia.

Un nombre de dominio completo (FQDN) de una instancia es similar a hostname.subnetdnslabel.vcndnslabel.oraclevcn.com, donde hostname es el nombre de host DNS de la instancia, subnetdnslabel y vcndnslabel son las etiquetas DNS de la subred de la instancia y de la VCN, respectivamente.

El dominio principal oraclevcn.com está reservado para su uso con nombres de host DNS creados en Oracle Cloud Infrastructure.

Sí.

No.

Sí. Los nombres de host DNS se crean para instancias independientemente del tipo de DNS seleccionado para la subred.

No. La instancia puede resolver los nombres de host solo de instancias dentro de la misma VCN.

Sí, puede hacerlo con servidores DNS personalizados configurados dentro de la VCN. Puedes configurar los servidores DNS personalizados para usar 169.254.169.254 como reenviador para el dominio VCN (por ejemplo, contoso.oraclevcn.com).

Tenga en cuenta que los servidores DNS personalizados deben configurarse en una subred que use "Resolución de Internet y de VCN" como tipo de DNS (para permitir el acceso a la dirección IP 169.254.169.254).

Para ver un ejemplo de implementación con el proveedor Oracle Terraform, consulte Configuración de DNS híbrido.

No se factura nada por crear y utilizar las VCN. Sin embargo, se aplican cargos por el uso de otros servicios de Oracle Cloud Infrastructure (incluidos los volúmenes de cálculo y de bloque) y por la transferencia de datos con arreglo a las tarifas publicadas. No hay cargos por transferencia de datos para ninguna comunicación entre los recursos dentro de una VCN.

Solo se le cobran las tarifas de transferencia de datos salientes de Oracle Cloud Infrastructure publicadas. No se factura nada por la conexión VPN por hora o por mes.

No incurre en cargos por transferencia de datos al acceder a otros servicios públicos de Oracle Cloud Infrastructure, como el almacenamiento de objetos, en la misma región. Todo el tráfico de red a través de IP privadas o públicas entre sus instancias y otros recursos dentro de su VCN, como una base de datos o un equilibrador de carga, está libre de cargos de transferencia de datos.

Si accede a recursos públicos de Oracle Cloud Infrastructure a través de su VPN IPSec desde su VCN, se facturarán los cargos publicados de transferencia de datos salientes.

A menos que se indique lo contrario, los precios de Oracle Cloud Infrastructure, incluidos los cargos de transferencia de datos salientes, excluyen los impuestos y los aranceles aplicables, incluido el IVA y cualquier impuesto a las ventas aplicable.