Reglas de seguridad

El servicio de Networking ofrece dos funciones de firewall virtual que utilizan reglas de seguridad para controlar el tráfico en el nivel de paquete. Los dos funciones son:

  • Listas de seguridad: la función de firewall virtual original del servicio de Networking.
  • Grupos de seguridad de red (NSG): función posterior diseñada para componentes de aplicaciones que tienen posiciones de seguridad diferentes. Los NSG solo se admiten para servicios específicos.

Estas dos funciones ofrecen diferentes maneras de aplicar reglas de seguridad a un conjunto de tarjetas de interfaz de red virtual (VNIC)  en la red virtual en la nube (VCN).

En este tema, se resumen las diferencias básicas entre las dos funciones. También se explican los conceptos importantes de las reglas de seguridad que es necesario comprender. El modo de creación, gestión y aplicación de reglas de seguridad varía entre las listas de seguridad y los grupos de seguridad de la red. Para obtener información detallada sobre la implantación, consulte los siguientes temas relacionados:

Comparación de listas de seguridad y grupos de seguridad de red

Las listas de seguridad permiten definir un conjunto de reglas de seguridad que se aplica a todas las VNIC de una subred completa. Para utilizar una lista de seguridad determinada con una subred concreta, debe asociar la lista de seguridad a la subred, ya sea durante la creación de la subred o más adelante. Una subred se puede asociar con un máximo de cinco listas de seguridad. Todas las VNIC que se crean en esa subred están sujetas a las listas de seguridad asociadas con la subred.

Los grupos de seguridad de red (NSG) permiten definir un conjunto de reglas de seguridad que se aplica a un grupo de VNIC de su elección (o los recursos principales de las VNIC, como equilibradores de carga o sistemas de base de datos). Por ejemplo, las VNIC que pertenecen a un conjunto de instancias informáticas que tienen la misma posición de seguridad. Para utilizar un NSG determinado, agregue las VNIC de interés al grupo. Las VNIC agregadas a ese grupo están sujetas a las reglas de seguridad de ese grupo. Se puede agregar una VNIC a un máximo de cinco NSG.

La siguiente tabla resume las diferencias.

Herramienta de seguridad Se aplica a Para activar Limitaciones
Listas de seguridad Todas las VNIC de una subred que utilizan esa lista de seguridad Asociar la lista de seguridad a la subred Máximo de cinco listas de seguridad por subred
Grupos de seguridad de red VNIC seleccionadas en la misma VCN Agregar VNIC específicas al NSG Máximo de cinco NSG por VNIC

Oracle recomienda utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.

Sin embargo, puede usar tanto listas de seguridad como NSG juntos si así lo desea. Para obtener más información, consulte Uso combinado de listas de seguridad y grupos de seguridad de red.

Acerca de las VNIC y los recursos principales

Un VNIC es un componente de servicio de Networking que permite a un recurso en red, como una instancia informática, conectarse a una red virtual en la nube (VCN). La VNIC determina cómo se conecta la instancia con los puntos finales dentro y fuera de la VCN. Cada VNIC reside en una subred de una VCN.

Al crear una instancia informática, se crea automáticamente una VNIC para la instancia en la subred de la instancia. Se considera que la instancia es el recurso principal para la VNIC. Puede agregar más VNIC (secundarias) a una instancia de cálculo. Por este motivo, las VNIC de una instancia se muestran de forma destacada como parte de los recursos relacionados de una instancia informática en la Consola.

Hay otros tipos de recursos principales que se pueden crear que también dan lugar a la creación automática de una VNIC. Por ejemplo, al crear un equilibrador de carga, el servicio de Load Balancing crea automáticamente VNIC para equilibrar el tráfico en el conjunto de backends. Además, al crear un sistema de base de datos, el servicio de Database crea automáticamente VNIC como nodos del sistema de base de datos. Esos servicios crean y gestionan esos VNIC. Por este motivo, esos VNIC no son rápidamente aparentes en la Consola de la misma forma que las VNIC para las instancias informáticas.

Para usar una NSG, se colocan las VNIC de su elección en el grupo. Sin embargo, lo habitual es trabajar con el recurso principal cuando se agrega una VNIC al grupo, no la VNIC propiamente dicho. Por ejemplo, al crear una instancia informática, puede especificar opcionalmente un NSG para la instancia. Aunque conceptualmente coloca la instancia en el grupo, en realidad está aplicando el VNIC principal de la instancia en el grupo de seguridad de red. Las reglas de seguridad del grupo se aplican a esa VNIC, no a la instancia. Además, si agrega una VNIC secundaria a la instancia, también puede especificar un NSG para esa VNIC, en cuyo caso las reglas se aplican a esa VNIC, no a la instancia. Tenga en cuenta que todos las VNIC de un NSG determinado deben estar en la VCN al que pertenece el NSG.

Del mismo modo, cuando coloca un equilibrador de carga en un grupo de seguridad de red, conceptualmente coloca el equilibrador de carga en el grupo. No obstante, en realidad, coloca las VNIC gestionados por el servicio de Load Balancing en el grupo de seguridad de red.

La pertenencia al VNIC de un NSG se gestiona en el recurso principal, no en el propio NSG. En otras palabras, para agregar un recurso principal a un grupo de seguridad de red, puede ejecutar la acción en el recurso principal (mediante la especificación de los grupos de seguridad de red a los que se debe agregar el recurso principal). No se ejecuta la acción en el grupo de seguridad de red (mediante la especificación de qué VNIC o recursos principales se deben agregar al grupo de seguridad de red). De manera similar, para eliminar una VNIC de un grupo de seguridad de red, puede ejecutar esa acción actualizando el recurso principal, no el grupo de seguridad de red. Por ejemplo, para agregar una VNIC de una instancia informática existente a un NSG, actualice las propiedades de la VNIC y especifique el NSG. Por ejemplo, con la API de REST, puede llamar a UpdateVnic. En la Consola, verá la instancia y, a continuación, la VNIC de interés, donde se pueden editar las propiedades de la VNIC.

Para obtener una lista de los recursos principales que admiten el uso de NSG, consulte Soporte para grupos de seguridad de red.

Grupo de seguridad de red como origen o destino de una regla

Hay una diferencia importante en cómo se pueden escribir reglas de seguridad para NSG en comparación con las listas de seguridad.

Al escribir reglas para un NSG, puede especificar un NSG como origen del tráfico (para reglas de entrada) o destino del tráfico (para reglas de salida). Compárese con las reglas de la lista de seguridad, donde puede especificar un CIDR como origen o destino.

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.

Además, si desea controlar el tráfico entre los VNIC en una NSG específica, puede escribir reglas que especifiquen la propia NSG de la regla como origen (para las reglas de entrada) o destino (para las reglas de salida).

Para obtener más información, consulte Visión general de los grupos de seguridad de red.

Diferencias de API de REST

Hay algunas diferencias básicas en el modelo de API de REST para los NSG en comparación con las listas de seguridad. Para obtener más información, consulte Uso de la API.

Reglas predeterminadas

VCN proporciona automáticamente una lista de seguridad predeterminada que contiene varias reglas de seguridad predeterminadas que sirven de ayuda para empezar a utilizar el servicio de Networking. Al crear una subred, la lista de seguridad predeterminada se asocia a la subred a menos que se especifique una lista de seguridad personalizada ya creada en la VCN.

En comparación, la VCN NO tiene ningún grupo de seguridad de red predeterminado.

Límites

Las dos funciones tienen límites diferentes.

Límites de lista de seguridad

Recurso

Ámbito

Crédito universal mensual o anual

Pago por consumo o promoción

Listas de seguridad VCN 300 300
Listas de seguridad Subred 5* 5*
Reglas de seguridad Lista de seguridad

200 reglas de entrada*

y

200 reglas de salida*

200 reglas de entrada*

y

200 reglas de salida*

* No se puede aumentar el límite para este recurso
Límites de grupos de seguridad de red

Recurso

Ámbito

Crédito universal mensual o anual

Pago por consumo o promoción

Grupos de seguridad de red VCN 1000 1000
VNIC Grupo de seguridad de red

Un grupo de seguridad de red determinado puede tener tantos VNIC como en la VCN.

Una VNIC determinada puede pertenecer como máximo a 5 grupos de seguridad de red.*

Un grupo de seguridad de red determinado puede tener tantos VNIC como en la VCN.

Una VNIC determinada puede pertenecer como máximo a 5 grupos de seguridad de red.*

Reglas de seguridad Grupo de seguridad de red

120 (total de entrada más salida)

120 (total de entrada más salida)

* No se puede aumentar el límite para este recurso

Mejores prácticas para reglas de seguridad

Uso de grupos de seguridad de red

Oracle recomienda utilizar NSG para los componentes que tienen la misma posición de seguridad. Por ejemplo, en una arquitectura de varios niveles, tendría un NSG independiente por cada nivel. Todos las VNIC de un nivel determinado pertenecen a la NSG de ese nivel. En un nivel determinado, es posible que tenga un subconjunto determinado de las VNIC del nivel que tienen requisitos de seguridad adicionales y especiales. Por lo tanto, debe crear otro NSG para esas reglas adicionales y colocar ese subconjunto de VNIC en el NSG del nivel y en el NSG adicional.

Oracle también recomienda usar NSG porque Oracle dará prioridad a los NSG antes que a las listas de seguridad cuando se implantan mejoras futuras.

Familiarización con las reglas de la lista de seguridad predeterminada

VCN proporciona automáticamente una lista de seguridad predeterminada que contiene varias reglas de seguridad predeterminadas que sirven de ayuda para empezar a utilizar el servicio de Networking. Esas reglas existen porque activan la conectividad básica. Incluso si decide no utilizar las listas de seguridad o la lista de seguridad predeterminada, es preciso familiarizarse con las reglas para comprender mejor los tipos de tráfico que necesitan los recursos en la nube conectados a la red. Es posible que desee usar esas reglas en los NSG o en cualquier lista de seguridad personalizada que se configure.

La lista de seguridad predeterminada no incluye reglas para activar el ping. Si necesita utilizar el ping, consulte Reglas para activar el ping.

No eliminar reglas de seguridad predeterminadas de forma indiscriminada

De manera predeterminada, la VCN puede tener subredes que utilizan la lista de seguridad por defecto. No elimine ninguna de las reglas de seguridad predeterminadas de la lista a menos que haya confirmado antes que los recursos de la VCN no las necesiten. De lo contrario, es posible que se interrumpa la conectividad de la VCN.

Confirmación de que las reglas del firewall del sistema operativo se alinean con las reglas de seguridad

Las instancias que ejecutan imágenes de plataforma también tienen reglas de firewall del sistema operativo que controlan el acceso a la instancia. Al solucionar el problema de acceso a una instancia, asegúrese de que todos los elementos siguientes están definidos correctamente:

  • Las reglas de los grupos de seguridad de red en los que está la instancia
  • Las reglas de las listas de seguridad asociadas a la subred de la instancia
  • Las reglas de firewall del sistema operativo de la instancia

Si la instancia está ejecutando Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 u Oracle Linux Cloud Developer 8, debe utilizar firewalld para interactuar con las reglas iptables. A continuación se muestran los comandos para abrir un puerto (1521 en este ejemplo):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Para instancias con un volumen de inicio iSCSI, el comando --reload anterior puede causar problemas. Para obtener información detallada y una solución alternativa, consulte Bloqueo del sistema de experiencias en instancias al ejecutar el firewall-cmd --reload.

Uso de métricas de VNIC para solucionar problemas de paquetes anulados debido a reglas de seguridad

El servicio de Networking ofrece métricas para VNIC, que muestran los niveles de tráfico de VNIC (paquetes y bytes). Dos de las métricas son para paquetes de entrada y salida que violan las reglas de seguridad y, por lo tanto, se anulan. Puede utilizar estas métricas para ayudarle a resolver problemas relacionados con reglas de seguridad y si las VNIC reciben el tráfico deseado.

Uso combinado de listas de seguridad y grupos de seguridad de red

Solo se pueden utilizar listas de seguridad o grupos de seguridad de red, o también ambos elementos juntos. Depende de las necesidades de seguridad concretas.

Si tiene reglas de seguridad que desea aplicar para todos las VNIC de una VCN, la solución más sencilla consiste en colocar las reglas en una sola lista de seguridad y, a continuación, asociar esa lista de seguridad a todas las subredes de la VCN. De esta manera, puede garantizar la aplicación de las reglas, independientemente de quién en su organización cree una VNIC en la VCN. Si lo desea, puede utilizar la lista de seguridad predeterminada de la VCN, que se incluye automáticamente en la VCN y contiene un conjunto de reglas esenciales por defecto.

Si decide utilizar de forma combinada listas de seguridad y grupos de seguridad de red, el conjunto de reglas que se aplica a una VNIC determinada es la unión de estos elementos:

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

El diagrama siguiente es una ilustración sencilla de la idea.

Una VNIC está sujeta a las reglas de todos los grupos de seguridad de red en los que está y todas las listas de seguridad asociadas a su subred.

Se permite un paquete en cuestión si cualquier regla de las listas y grupos relevantes permite el tráfico (o si el tráfico forma parte de una conexión existente cuyo seguimiento se está realizando). Hay una excepción si las listas vienen a contener reglas con estado y sin estado que cubren el mismo tráfico. Para obtener más información, consulte Reglas con estado frente a sin estado.

Partes de una regla de seguridad

Una regla de seguridad permite un tipo concreto de tráfico dentro o fuera de una VNIC. Por ejemplo, una regla de seguridad que se suele utilizar permite al puerto 22 de TCP el tráfico para establecer conexiones SSH con la instancia (más concretamente con las VNIC de la instancia). Sin reglas de seguridad, no se permite tráfico en las VNIC ni fuera de ellos en la VCN.

Nota

Las reglas de seguridad no se aplican al tráfico que cubre el bloque CIDR 169.254.0.0/16, que incluye servicios como iSCSI y metadatos de la instancia.

Cada regla de seguridad especifica los siguientes elementos:

  • Dirección (entrada o salida): el tráfico de entrada es el que se recibe y el de salida, el que se envía desde la VNIC. El modelo de API de REST para las listas de seguridad es diferente de los grupos de seguridad de red. Con las listas de seguridad, hay un objeto IngressSecurityRule y otro objeto EgressSecurityRule independiente. Con los grupos de seguridad de red, solo hay un objeto SecurityRule y el atributo direction del objeto determina si la regla es para el tráfico de entrada o salida.
  • Con estado o sin estado: si se tiene estado, se utiliza el seguimiento de conexión para el tráfico que coincide con la regla. Si no tiene estado, no se utiliza ningún seguimiento de conexión. Consulte Reglas con estado frente a sin estado.
  • Tipo de origen y origen (solo reglas de entrada): el origen que proporcione para una regla de entrada depende del tipo de origen elegido.

    Tipos de orígenes permitidos
    Tipo de origen Origen permitido
    CIDR Bloque CIDR desde el que se origina el tráfico. Utilice 0.0.0.0/0 para indicar todas las direcciones IP. El prefijo es necesario (por ejemplo, incluya el /32 si especifica una dirección IP individual).
    Grupo de seguridad de red

    Grupo de seguridad de red que está en la misma VCN que el grupo de seguridad de red de esta regla.

    Este tipo de origen está disponible solo si la regla pertenece a un NSG, y no a una lista de seguridad.

    Servicio

    Solo para los paquetes que provienen de un servicio de Oracle mediante un gateway de servicio.

    El servicio de origen es la etiqueta CIDR del servicio en la que está interesado.

  • Tipo de destino y destino (solo reglas de salida): el destino que se proporciona para una regla de salida depende del tipo de destino elegido.

    Tipos de destino permitidos
    Tipo de destino Destino permitido
    CIDR Bloque CIDR al que se dirige el tráfico. Utilice 0.0.0.0/0 para indicar todas las direcciones IP. El prefijo es necesario (por ejemplo, incluya el /32 si especifica una dirección IP individual).
    Grupo de seguridad de red

    Grupo de seguridad de red que está en la misma VCN que el grupo de seguridad de red de esta regla.

    Este tipo de destino solo está disponible si la regla pertenece a un NSG, y no a una lista de seguridad.

    Servicio

    Solo para paquetes que pasan a un servicio de Oracle mediante un gateway de servicio.

    El servicio de destino es la etiqueta CIDR del servicio en la que está interesado.

  • Protocolo IP: un único protocolo IPv4 o "todos" para cubrir todos los protocolos.
  • Puerto de origen: puerto desde el que se origina el tráfico. Para TCP o UDP, puede especificar todos los puertos de origen u, opcionalmente, especificar un único número de puerto de origen o un rango.
  • Puerto de destino: puerto al que se dirige el tráfico. Para TCP o UDP, puede especificar todos los puertos de destino u, opcionalmente, especificar un único número de puerto de destino o un rango.
  • Tipo y código ICMP: para ICMP, puede especificar todos los tipos y códigos o especificar de manera opcional un solo tipo con un código opcional. Si el tipo tiene varios códigos, cree una regla independiente para cada código que desee permitir.
  • Descripción (solo reglas del NSG): las reglas de seguridad del NSG incluyen un atributo opcional, mediante el que se puede proporcionar una descripción fácil de recordar de la regla. Esto no se admite actualmente para las reglas de listas de seguridad.

Para ver ejemplos de reglas de seguridad, consulte Escenarios de Networking.

Para conocer el límite del número de reglas que puede tener, consulte Comparación de listas de seguridad y grupos de seguridad de red.

Nota

Si usa los NSG y dos VNIC que están en la misma VCN necesitan comunicarse mediante sus direcciones IP públicas, debe usar la dirección IP pública de la VNIC, no el NSG de la VNIC como el origen (para entrada) o el destino (para salida) en las reglas de seguridad relevantes. El paquete se enruta al gateway de internet de la VCN y, en ese momento, la información del NSG de la VNIC no está disponible. Por lo tanto, una regla de seguridad que especifique el NSG como origen o destino no será efectiva para permitir ese tipo específico de tráfico.

Reglas con estado frente a sin estado

Al crear una regla de seguridad, se selecciona si es con estado o sin estado. La diferencia se describe en las secciones siguientes. El valor predeterminado es con estado. Se recomiendan reglas sin estado si se tiene un sitio web orientado a internet de gran volumen (para el tráfico HTTP/HTTPS).

Esta sección hace referencia específicamente a instancias de cálculo y su tráfico. Sin embargo, la discusión se aplica a todos los tipos de recursos con las VNIC. Consulte Comparación de listas de seguridad y grupos de seguridad de red.

Reglas con estado

Al marcar una regla de seguridad con estado se indica que se va a utilizar el seguimiento de conexiones para cualquier tráfico que coincida con esa regla. Esto significa que, cuando una instancia recibe tráfico que coincide con la regla de entrada con estado, se realiza un seguimiento de la respuesta y se permite de forma automática para el host de origen, independientemente de las reglas de salida aplicables a la instancia. Asimismo, cuando una instancia envía tráfico que coincida con una regla de salida con estado, la respuesta entrante se permite automáticamente, con independencia de las reglas de entrada.

Por ejemplo, puede tener una regla de seguridad de entrada con estado para una instancia (Instancia A) que necesite recibir y responder al tráfico HTTP del host B. El host B puede ser cualquier host, ya sea una instancia o no. La instancia A y el host B se están comunicando porque la regla de entrada con estado permite el tráfico de cualquier dirección IP de origen (0.0.0.0/0) solo al puerto de destino 80 (protocolo TCP). No se necesita ninguna regla de salida para permitir el tráfico de respuesta, ya que se realiza un seguimiento automático de las respuestas y se permiten.

Regla de entrada con estado que permite el tráfico HTTP entrante y la respuesta

Reglas sin estado

Si define una regla de seguridad sin estado, NO podrá utilizar el seguimiento de conexión para ningún tráfico que coincida con esa regla. Esto significa que el tráfico de respuesta no se permite automáticamente. Para permitir el tráfico de respuesta para una regla de entrada sin estado, debe crear la regla de salida sin estado correspondiente.

La siguiente figura muestra la instancia A y el host B como antes, pero ahora con las reglas de seguridad sin estado. Al igual que con la regla con estado en la sección anterior, la regla de entrada sin estado permite el tráfico de todas las direcciones IP y de cualquier puerto, solo en el puerto de destino 80 (con el protocolo TCP). Para permitir el tráfico de respuesta, debe haber una regla de salida sin estado correspondiente que permita el tráfico a cualquier dirección IP de destino (0.0.0.0/0) y todos los puertos, desde el puerto de origen 80 únicamente (mediante el protocolo TCP).

Reglas de entrada y salida sin estado que permiten la respuesta y el tráfico HTTP entrante

Si la instancia A necesita, en cambio, iniciar el tráfico HTTP y obtener la respuesta, se requiere un conjunto diferente de reglas sin estado. Como se muestra en la siguiente figura, la regla de salida tendría el puerto de origen = todos y el puerto de destino = 80 (HTTP). La regla de entrada tendría entonces el puerto de origen 80 y el puerto de destino = todos.

Reglas de entrada y salida sin estado que permiten a la instancia iniciar el tráfico HTTP y obtener la respuesta

Si va a utilizar el enlace de puerto en la instancia A para especificar exactamente de qué puerto procede el tráfico HTTP, puede especificar aquel como puerto de origen en la regla de salida y el puerto de destino en la regla de entrada.

Nota

Si, por algún motivo, utiliza reglas con estado y sin estado, y hay tráfico que coincida con una regla con estado y sin estado en una dirección determinada (por ejemplo, entrada), la regla sin estado tiene prioridad y no se realiza el seguimiento de la conexión. Necesitaría una regla correspondiente en la otra dirección (por ejemplo, salida, sin estado o con estado) para que se permita el tráfico de respuesta.

Detalles de seguimiento de conexiones para reglas con estado

Oracle utiliza el seguimiento de conexiones para permitir respuestas para el tráfico que coincide con las reglas con estado (consulte Reglas con estado frente a sin estado). Cada instancia tiene un número máximo de conexiones simultáneas cuyo seguimiento se puede realizar, según la unidad de comandos de la instancia.

Para determinar el tráfico de respuesta para TCP, UDP e ICMP, Oracle realiza el seguimiento de la conexión en estos elementos para el paquete:

  • Protocolo
  • Direcciones IP de origen y destino
  • Puertos de origen y destino (solo para TCP y UDP)
Nota

Para otros protocolos, Oracle solo realiza el seguimiento de las direcciones IP y protocolo, y no de los puertos. Esto significa que cuando una instancia inicia el tráfico a otro host y se permite este tráfico mediante reglas de seguridad de salida, todo el tráfico que la instancia recibe posteriormente de ese host durante un período se considera tráfico de respuesta y se permite.

Activación de mensajes de descubrimiento de la MTU de la ruta para reglas sin estado

Si decide utilizar reglas de seguridad sin estado para permitir que el tráfico bidireccional con los puntos finales fuera de la VCN, es importante agregar una regla de seguridad que permita el tipo de tráfico ICMP de tipo 3, código 4 desde el origen 0.0.0.0/0 y cualquier puerto de origen. Esta regla permite a las instancias recibir mensajes de fragmentación del descubrimiento de la MTU de la ruta. Esta regla resulta crítica para establecer una conexión con sus instancias. Sin ella, puede experimentar problemas de conectividad. Para obtener más información, consulte Conexiones que se cuelgan.

Reglas para activar el ping

La lista de seguridad predeterminada de la VCN contiene varias reglas predeterminadas, pero ninguna que permita solicitudes de ping. Si desea hacer ping en una instancia, asegúrese de que las listas de seguridad aplicables o los NSG de la instancia incluyan una regla de entrada adicional con estado que permita específicamente el tipo de tráfico 8 de ICMP desde la red de origen desde la que desea hacer ping. Para permitir el acceso de ping desde internet, utilice 0.0.0.0/0 para el origen. Tenga en cuenta que esta regla de ping es independiente de las reglas relacionadas con ICMP predeterminadas en la lista de seguridad predeterminada. No elimine dichas reglas.

Reglas para gestionar paquetes UDP fragmentados

Las instancias pueden enviar o recibir tráfico UDP. Si un paquete UDP es demasiado grande para la conexión, está fragmentado. Sin embargo, solo el primer fragmento del paquete contiene la información de protocolo y puerto. Si las reglas de seguridad que permiten este tráfico de entrada y salida especifican un número de puerto determinado (de origen o de destino), los fragmentos posteriores al primero se anulan. Si espera que las instancias envíen o reciban paquetes UDP grandes, establezca los puertos de origen y destino para las reglas de seguridad aplicables como TODOS (en lugar de un número de puerto concreto).