Reglas de la política de firewall

Cuando creas una regla de política de firewall, debes especificar un conjunto de componentes que definen lo que hace la regla. Estos componentes especifican la dirección del tráfico, el origen, el destino y las características de la capa 4, como el protocolo y el puerto de destino (si el protocolo usa puertos).

Cada regla de política del firewall se aplica a las conexiones entrantes (entrada) o salientes (salida), pero no a ambas.

Reglas de entrada

La dirección de entrada se refiere a las conexiones entrantes que se envían desde orígenes específicos a objetivos de Google Cloud. Las reglas de entrada se aplican a paquetes entrantes, en los que el destino de los paquetes es el objetivo.

Una regla de entrada con una acción deny protege todas las instancias cuando bloquea las conexiones entrantes a ellas. Una regla de mayor prioridad podría permitir el acceso entrante. Una red predeterminada creada automáticamente incluye algunas reglas de firewall de VPC prepropagadas, que permiten la entrada para ciertos tipos de tráfico.

Reglas de salida

La dirección de salida se refiere al tráfico saliente enviado de un objetivo a un destino. Las reglas de salida se aplican a paquetes para conexiones nuevas en las que el origen del paquete es el objetivo.

Una regla de salida con una acción allow permite que una instancia envíe tráfico a los destinos especificados en la regla. Las reglas de firewall de mayor prioridad deny pueden denegar la salida. Google Cloud también bloquea o limita ciertos tipos de tráfico.

Componentes de las reglas de las políticas de firewall

Las reglas en las políticas de firewall jerárquicas, las políticas de firewall de red globales y las políticas de firewall de red regionales usan los componentes descritos en esta sección. El término política de firewall hace referencia a cualquiera de estos tres tipos de políticas. Para obtener más información sobre los tipos de políticas de firewall, consulta Políticas de firewall.

Las reglas de las políticas de firewall suelen funcionar de la misma manera que las reglas de firewall de VPC, pero existen algunas diferencias, como se describe en las siguientes secciones.

Prioridad

La prioridad de una regla en una política de firewall es un número entero de 0 a 2,147,483,647, inclusive. Los números enteros más bajos indican prioridades más altas. La prioridad de una regla en una política de firewall es similar a la prioridad de una regla de firewall de VPC, con las siguientes diferencias:

  • Cada regla en una política de firewall debe tener una prioridad única.
  • La prioridad de una regla en una política de firewall funciona como el identificador único de la regla. Las reglas en las políticas de firewall no usan nombres para la identificación.
  • La prioridad de una regla en una política de firewall define el orden de evaluación dentro de la política de firewall. Las reglas de firewall de VPC y las reglas en las políticas de firewall jerárquicas, las políticas de firewall de red globales y las políticas de firewall de red regionales se evalúan como se describe en Orden de evaluación de políticas y reglas.

Acción en caso de coincidencia

Una regla en una política de firewall puede tener una de las siguientes acciones:

  • allow permite el tráfico y detiene la evaluación de reglas.
  • deny no permite el tráfico y detiene la evaluación de reglas.
  • apply_security_profile_group intercepta con transparencia el tráfico y lo envía al extremo de firewall configurado para la inspección de la capa 7.

Aplicación

Puedes cambiar si una regla de política de firewall se aplica configurando su estado como habilitada o inhabilitada. Establece el estado de aplicación cuando creas una regla o cuando actualizas una regla.

Si no configuras un estado de aplicación cuando creas una regla de firewall nueva, la regla de firewall se habilita de forma automática.

Protocolos y puertos

Al igual que con las reglas de firewall de VPC, debes especificar una o más restricciones de protocolos y puertos cuando creas una regla. Cuando especificas TCP o UDP en una regla, puedes especificar el protocolo, el protocolo y un puerto de destino, o el protocolo y un rango de puertos de destino. No puedes especificar solo un puerto o rango de puertos. Además, solo puedes especificar puertos de destino. No se admiten reglas basadas en puertos de origen.

Puedes usar los siguientes nombres de protocolo en reglas de firewall: tcp, udp, icmp (en ICMP para IPv4), esp, ah, sctp y ipip. Para todos los demás protocolos, usa los números de protocolo de IANA.

Muchos protocolos usan el mismo nombre y número en IPv4 y en IPv6, pero algunos protocolos, como ICMP, no. Para especificar ICMP de IPv4, usa icmp o el número de protocolo 1. Para ICMP de IPv6, usa el número de protocolo 58.

Las reglas de firewall no admiten la especificación de códigos y tipos de ICMP, solo el protocolo.

El protocolo IPv6 de salto por salto no es compatible con las reglas de firewall.

Si no especificas los parámetros de protocolo y puerto, la regla se aplica a todos los protocolos y puertos de destino.

Logging

El registro de las reglas de la política de firewall funciona igual que el registro de reglas de firewall de VPC, excepto por las siguientes diferencias:

  • El campo de referencia incluye el ID de la política de firewall y un número que indica el nivel del recurso al que se adjunta la política. Por ejemplo, 0 significa que la política se aplica a una organización, y 1 significa que la política se aplica a una carpeta de nivel superior en la organización.

  • Los registros de las reglas de políticas de firewall incluyen un campo target_resource que identifica las redes de VPC a las que se aplica la regla.

  • El registro solo se puede habilitar para las reglas allow, deny y apply_security_profile_group. No se puede habilitar en reglas goto_next.

Objetivo, origen y destino

Los parámetros de objetivo identifican las interfaces de red de las instancias a las que se aplica una regla de firewall.

Puedes especificar parámetros de origen y parámetros de destino que se aplican a los orígenes o destinos de los paquetes para las reglas de firewall de entrada y salida. La dirección de la regla de firewall determina los valores posibles para los parámetros de origen y destino.

Los parámetros de objetivo, origen y destino funcionan juntos.

Destinos

El parámetro de objetivo identifica las interfaces de red de las instancias de Compute Engine, incluidos los nodos de GKE y las instancias del entorno flexible de App Engine.

Puedes definir los objetivos para las reglas de entrada o salida. Las opciones de objetivos válidas dependen del tipo de política de firewall.

Objetivos para las reglas de políticas de firewall jerárquicas

Las reglas de políticas de firewall jerárquicas admiten los siguientes objetivos:

  • Objetivo más amplio predeterminado: cuando omites la especificación de destino en una regla de política de firewall jerárquica, la regla de firewall se aplica a todas las instancias en todas las redes de VPC de todos los proyectos en el nodo de Resource Manager (organización o carpeta) asociado con la firewall. Este es el conjunto más amplio de objetivos.

  • Redes específicas: si especificas una o más redes de VPC a través del parámetro target-resources, el conjunto más amplio de objetivos se limita a las VMs con una interfaz de red en al menos una de las redes de VPC especificadas.

  • Instancias identificadas por cuenta de servicio: si especificas una o más cuentas de servicio a través del parámetro target-service-accounts, el conjunto más amplio de objetivos se limita a las VMs que usan una de las cuentas de servicio especificadas.

  • Instancias y redes específicas identificadas por la cuenta de servicio: si especificas el parámetro target-resources y el parámetro target-service-accounts, el conjunto más amplio de objetivos se limita a las VMs que cumplan con los siguientes criterios:

    • Las VMs tienen una interfaz de red en una de las redes de VPC especificadas.
    • Las VMs usan una de las cuentas de servicio especificadas.

Destinos para las reglas de las políticas de firewall de red globale

Las reglas de las políticas de firewall de red globales admiten los siguientes objetivos:

  • Objetivo predeterminado: todas las instancias de la red de VPC: cuando omites la especificación de destino en una regla de política de firewall de red global, la regla de firewall se aplica a las instancias que tienen una interfaz de red en la red de VPC asociada con la política. Las instancias pueden estar ubicadas en cualquier región. Este es el conjunto más amplio de objetivos.

  • Instancias por etiquetas seguras de destino: si especificas etiquetas de destino con el parámetro target-secure-tags, el conjunto más amplio de objetivos se limita para incluir solo aquellas VMs vinculadas a las etiquetas.

  • Instancias por cuentas de servicio de objetivo: si especificas cuentas de servicio con el parámetro target-service-accounts, el conjunto más amplio de objetivos se reduce para incluir solo las VMs que usan una de las cuentas de servicio especificadas.

Destinos para las reglas de políticas de firewall de la red regionales

Las reglas de las políticas de firewall de red regionales admiten los siguientes objetivos:

  • Destino predeterminado: todas las instancias de la región y la red de VPC: cuando omites la especificación de destino en una regla de política de firewall de red regional, la regla de firewall se aplica a las instancias que tienen una interfaz de red en la red de VPC asociada con la política. Las instancias deben estar ubicadas en la misma región que la política. Este es el conjunto de objetivos más amplio.

  • Instancias por etiquetas seguras de destino: si especificas etiquetas de destino con el parámetro target-secure-tags, el conjunto más amplio de objetivos se limita para incluir solo aquellas VMs vinculadas a las etiquetas.

  • Instancias por cuentas de servicio de objetivo: si especificas cuentas de servicio con el parámetro target-service-accounts, el conjunto más amplio de objetivos se reduce para incluir solo las VMs que usan una de las cuentas de servicio especificadas.

Objetivos y direcciones IP para reglas de entrada

Los paquetes enrutados a la interfaz de red de una VM de destino se procesan en función de las siguientes condiciones:

  • Si la regla de firewall de entrada incluye un rango de direcciones IP de destino, el destino del paquete debe ajustarse a uno de los rangos de direcciones IP de destino definidos de forma explícita.

  • Si la regla de firewall de entrada no incluye un rango de direcciones IP de destino, el destino del paquete debe coincidir con una de las siguientes direcciones IP:

    • La dirección IPv4 interna principal que se asigna a la NIC de la instancia.

    • Cualquier rango de direcciones IP que se configura en la NIC de la instancia.

    • La dirección IPv4 externa que está asociada a la NIC de la instancia.

    • Si se configura IPv6 en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC.

    • Una dirección IP interna o externa asociada con una regla de reenvío que se usa para el balanceo de cargas de transferencia, en la que la instancia es un backend de un balanceador de cargas de red de transferencia interno o un balanceador de cargas de red de transferencia externo.

    • Una dirección IP interna o externa asociada con una regla de reenvío que se usa para el reenvío de protocolos, en la que una instancia de destino hace referencia a la instancia.

    • Una dirección IP dentro del rango de destino de una ruta estática personalizada que usa la instancia (next-hop-instance o next-hop-address) como una VM de próximo salto.

    • Una dirección IP dentro del rango de destino de una ruta estática personalizada que usa un balanceador de cargas de red de transferencia interno (next-hop-ilb) como próximo salto si la VM es un backend para ese balanceador de cargas.

Objetivos y direcciones IP para reglas de salida

El procesamiento de los paquetes emitidos desde la interfaz de red de un objetivo depende de la configuración de reenvío de IP en la VM de destino. El reenvío de IP está inhabilitado de forma predeterminada.

  • Cuando la VM de destino tiene inhabilitado el reenvío de IP, la VM puede emitir paquetes con los siguientes orígenes:

    • La dirección IPv4 interna principal de la NIC de una instancia.

    • Cualquier rango de direcciones IP que se configura en la NIC de una instancia.

    • Si se configura IPv6 en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC.

    • Una dirección IP interna o externa asociada con una regla de reenvío para el balanceo de cargas de transferencia o el reenvío de protocolos. Esto es válido si la instancia es un backend de un balanceador de cargas de red de transferencia interno, un balanceador de cargas de red de transferencia externo o si una instancia objetivo hace referencia a ella.

    Si la regla de firewall de salida incluye rangos de direcciones IP de origen, las VMs de destino aún están limitadas a las direcciones IP de origen mencionadas antes, pero el parámetro de origen se puede usar para definir mejor ese conjunto. El uso de un parámetro de origen sin habilitar el reenvío de IP no expande el conjunto de direcciones de origen de paquetes posibles.

    Si la regla de firewall de salida no incluye un rango de direcciones IP de origen, se permiten todas las direcciones IP de origen mencionadas antes.

  • Cuando la VM de destino tiene habilitado el reenvío de IP, la VM puede emitir paquetes con direcciones de origen arbitrarias. Puedes usar el parámetro de origen para definir con mayor precisión el conjunto de orígenes de paquetes permitidos.

Fuentes

Los valores del parámetro de origen dependen de lo siguiente:

  • El tipo de política de firewall que contiene la regla de firewall
  • La dirección de la regla de firewall

Orígenes para reglas de entrada

En la siguiente tabla, se enumeran los parámetros de origen que se pueden usar de forma individual o en combinación entre sí en una sola regla de política de firewall de entrada. El NGFW de Cloud requiere que especifiques al menos un parámetro de origen.

Parámetro de origen de la regla de entrada Compatibilidad con políticas de firewall jerárquicas Compatibilidad con las políticas de firewall de red globales y regionales
Rangos de direcciones IP de origen

Una lista simple que consta de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La lista se almacena dentro de la regla de la política de firewall.
Grupos de direcciones de origen

Colecciones reutilizables de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La regla de firewall hace referencia a la colección. Para obtener más información, consulta Grupos de direcciones para políticas de firewall.
Nombres de dominio de origen

Es una lista de uno o más nombres de dominio de origen. Para obtener más información, incluida la forma en que los nombres de dominio se convierten en direcciones IP, consulta Objetos FQDN.
Etiquetas de origen seguras

Una lista de una o más etiquetas de origen seguras. Para obtener más información, consulta Cómo las etiquetas seguras de origen implican las fuentes de paquetes.
Ubicaciones geográficas de origen

Es una lista de una o más ubicaciones geográficas de origen especificadas como códigos de país o región de dos letras. Para obtener más información, consulta Objetos de ubicación geográfica.
Fuentes de las listas de Google Threat Intelligence

Es una lista de uno o más nombres predefinidos de listas de Google Threat Intelligence. Si deseas obtener más información, consulta Inteligencia de amenazas de Google para las reglas de políticas de firewall.
Permiso de la red de origen

Es una restricción que define un límite de seguridad. Para obtener más información, consulta Alcances de red.

En una sola regla de entrada, puedes usar dos o más parámetros de origen para producir una combinación de fuentes. Cloud NGFW aplica las siguientes restricciones a las combinaciones de fuentes de cada regla de entrada:

  • Los rangos de direcciones IP de origen deben contener CIDR IPv4 o IPv6, no una combinación de ambos.
  • No se puede usar un grupo de direcciones de origen que contenga CIDRs IPv4 con un grupo de direcciones de origen que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de origen que contenga CIDRs IPv4 con un grupo de direcciones de origen que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de origen que contenga CIDRs IPv6 con un grupo de direcciones de origen que contenga CIDRs IPv4.
  • El alcance de la red de Internet no se puede usar con las etiquetas de red de origen.
  • El alcance no de Internet, el alcance de las redes de VPC y el alcance entre VPCs no se pueden usar con las listas de Google Threat Intelligence o las geolocalizaciones de origen.

Cloud NGFW aplica la siguiente lógica para hacer coincidir los paquetes con una regla de entrada que usa una combinación de origen:

  • Si la combinación de fuentes no incluye un alcance de red de origen, los paquetes coinciden con la regla de entrada si coinciden con al menos un parámetro de origen en la combinación de fuentes.

  • Si la combinación de fuentes incluye un alcance de red de origen, los paquetes coinciden con la regla de entrada si coinciden con el alcance de red de origen y al menos uno de los otros parámetros de origen en la combinación de fuentes.

Cómo las etiquetas seguras de origen implican los orígenes de los paquetes

Las reglas de entrada en las políticas de firewall de red globales y regionales pueden especificar orígenes a través de etiquetas seguras. Cada etiqueta segura está asociada a una sola red de VPC y solo se puede vincular a una VM que tenga una interfaz de red en la red de VPC a la que está asociada la etiqueta segura.

Los paquetes que se envían desde una interfaz de red de una VM coinciden con una regla de entrada que usa una fuente de etiqueta segura cuando se cumplen las siguientes condiciones:

  • Si la regla de entrada está en una política de red regional, la VM debe estar ubicada en una zona de la región de la política de firewall de red. Si la regla de entrada está en una política de firewall de red global, la VM se puede ubicar en cualquier zona.

  • La interfaz de red de la VM que envía los paquetes cumple con uno de los siguientes criterios:

    • La interfaz de red de la VM está en la misma red de VPC que la red de VPC a la que se aplica la política de firewall de red global o regional.
    • La interfaz de red de la VM se encuentra en una red de VPC que está conectada, mediante el intercambio de tráfico entre redes de VPC, a la red de VPC a la que se aplica la política de firewall de red global o regional.
    • La red de VPC que usa la interfaz de red de la VM y la red de VPC a la que se aplica la política de firewall de red global o regional son radios de VPC en el mismo concentrador de Network Connectivity Center.

  • La dirección IP de origen del paquete es una de las siguientes:

    • La dirección IPv4 interna principal de la interfaz de red.
    • Cualquier dirección IPv6 (interna o externa) asignada a la interfaz de red

No se resuelven otras direcciones IP de origen del paquete cuando se usan etiquetas de red de origen. Por ejemplo, se excluyen los rangos de direcciones IP del alias y las direcciones IPv4 externas asociadas con la interfaz de red. Si necesitas crear reglas de firewall de entrada con fuentes que incluyan rangos de alias de direcciones IP o direcciones IPv4 externas, usa un rango de direcciones de origen o un grupo de direcciones de origen.

Orígenes para las reglas de salida

Puedes usar los siguientes orígenes para reglas de salida en las políticas de firewall jerárquicas y en las políticas de firewall de red:

  • Predeterminado - implicado por el destino: Si omites el parámetro de origen de una regla de salida, las fuentes de paquetes se definen de forma implícita como se describe en Destinos y direcciones IP para reglas de salida.

  • Rangos de IPv4 de origen: Una lista de direcciones IPv4 en formato CIDR.

  • Rangos de IPv6 de origen: Una lista de direcciones IPv6 en formato CIDR.

Sigue estos lineamientos a fin de agregar rangos de direcciones IP de origen para reglas de salida:

  • Si una interfaz de VM tiene direcciones IPv4 internas y externas asignadas, solo se usa la dirección IPv4 interna durante la evaluación de la regla.

  • Si tienes un rango de direcciones IP de origen y parámetros de destino en la regla de salida, los parámetros de destino se resuelven en la misma versión de IP que la versión de IP de origen.

    Por ejemplo, en una regla de salida, tienes un rango de direcciones IPv4 en el parámetro de origen y un objeto FQDN en el parámetro de destino. Si el FQDN se resuelve tanto en direcciones IPv4 como en direcciones IPv6, solo se usa la dirección IPv4 resuelta durante la aplicación de la regla.

Destinos

Los destinos se pueden especificar a través de rangos de direcciones IP, que son compatibles con las reglas de entrada y salida en las políticas de firewall jerárquicas y de red. El comportamiento de destino predeterminado depende de la dirección de la regla.

Destinos para las reglas de entrada

Puedes usar los siguientes destinos para las reglas de firewall de entrada en las políticas jerárquicas y de firewall de red:

  • Predeterminado: implicado por el objetivo: Si omites el parámetro de destino de una regla de entrada, los destinos del paquete se definen de forma implícita como se describe en Objetivos y direcciones IP para reglas de entrada.

  • Rangos de direcciones IPv6 de destino: una lista de direcciones IPv6 en formato CIDR.

  • Rangos de direcciones IPv6 de destino: una lista de direcciones IPv6 en formato CIDR.

Sigue estos lineamientos a fin de agregar rangos de direcciones IP de destino para las reglas de entrada:

Destinos para las reglas de salida

En la siguiente tabla, se enumeran los parámetros de destino que se pueden usar de forma individual o en combinación entre sí en una sola regla de política de firewall de salida. El NGFW de Cloud requiere que especifiques al menos un parámetro de destino.

Parámetro de destino de la regla de salida Compatibilidad con políticas de firewall jerárquicas Compatibilidad con las políticas de firewall de red globales y regionales
Rangos de direcciones IP de destino

Una lista simple que consta de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La lista se almacena dentro de la regla de la política de firewall.
Grupos de direcciones de destino

Colecciones reutilizables de direcciones IPv4 en formato CIDR o direcciones IPv6 en formato CIDR. La regla de la política de firewall hace referencia a la colección. Para obtener más información, consulta Grupos de direcciones para políticas de firewall.
Nombres de dominio de destino

Es una lista de uno o más nombres de dominio de origen. Para obtener más información, incluida la forma en que los nombres de dominio se convierten en direcciones IP, consulta Objetos FQDN.
Geolocalizaciones de destino

Es una lista de una o más ubicaciones geográficas de origen especificadas como códigos de país o región de dos letras. Para obtener más información, consulta Objetos de ubicación geográfica.
Listas de Google Threat Intelligence de destino

Es una lista de uno o más nombres predefinidos de listas de Google Threat Intelligence. Si deseas obtener más información, consulta Inteligencia de amenazas de Google para las reglas de políticas de firewall.
Permiso de la red de destino

Es una restricción que define un límite de seguridad. Para obtener más información, consulta Alcances de red.

En una sola regla de salida, puedes usar dos o más parámetros de destino para generar una combinación de destinos. Cloud NGFW aplica las siguientes restricciones a las combinaciones de destino de cada regla de salida:

  • Los rangos de direcciones IP de destino deben contener CIDR IPv4 o IPv6, no una combinación de ambos.
  • No se puede usar un grupo de direcciones de destino que contenga CIDRs IPv4 con un grupo de direcciones de destino que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de destino que contenga CIDRs IPv4 con un grupo de direcciones de destino que contenga CIDRs IPv6.
  • No se puede usar un rango de direcciones IP de destino que contenga CIDRs IPv6 con un grupo de direcciones de destino que contenga CIDRs IPv4.
  • Las listas de Google Threat Intelligence o las geolocalizaciones de destino no se pueden usar con el alcance de la red de destino que no sea de Internet.

La NGFW de Cloud aplica la siguiente lógica para hacer coincidir los paquetes con una regla de salida que usa una combinación de destino:

  • Si la combinación de destino no incluye un alcance de red de destino, los paquetes coinciden con la regla de salida si coinciden con al menos un parámetro de destino en la combinación de destino.

  • Si la combinación de destino incluye un alcance de red de destino, los paquetes coinciden con la regla de salida si coinciden con el alcance de red de destino y al menos uno de los otros parámetros de destino en la combinación de destino.

Permisos de red

Los alcances de red te ayudan a cumplir con tus objetivos de seguridad, ya que usan menos reglas de políticas de firewall de manera más eficiente. Cloud NGFW admite cuatro tipos de permisos de red que se pueden usar para crear una combinación de origen o de destino en una regla de una política de firewall jerárquica, una política de firewall de red global o una política de firewall de red regional.

Tipos de permisos de la red

En la siguiente tabla, se enumeran los cuatro tipos de alcances de red y si un tipo de alcance se puede usar en una combinación de origen de una regla de entrada, en una combinación de destino de una regla de salida o en ambas.

Tipo de permiso de la red Orígenes para reglas de entrada Destinos para las reglas de salida
Internet (INTERNET)
Sin conexión a Internet (NON_INTERNET)
Redes de VPC (VPC_NETWORKS)
Dentro de la VPC (INTRA_VPC)

Los alcances de Internet y no de Internet son mutuamente excluyentes. Las redes de VPC y los alcances intra-VPC son subconjuntos del alcance que no es de Internet.

Alcance de Internet

El alcance de Internet (INTERNET) se puede usar como parte de una combinación de origen de una regla de entrada o como parte de una combinación de destino de una regla de salida:

  • Para una regla de entrada, especifica la fuente de alcance de Internet y al menos otro parámetro de origen, excepto una fuente de etiqueta segura. Los paquetes coinciden con la regla de entrada si coinciden con al menos uno de los otros parámetros de origen y coinciden con el parámetro de origen de alcance de Internet.

  • Para una regla de salida, especifica el destino de alcance de Internet y al menos un otro parámetro de destino. Los paquetes coinciden con la regla de salida si coinciden con al menos uno de los otros parámetros de destino y con el parámetro de destino de alcance de Internet.

En el resto de esta sección, se describen los criterios que usa la NGFW de Cloud para determinar si un paquete pertenece al alcance de Internet.

Alcance de Internet para paquetes de entrada

Los paquetes de entrada que un Maglev de Google enruta a una interfaz de red de VM se consideran dentro del alcance de Internet. Maglev enruta los paquetes a una interfaz de red de VM cuando el destino del paquete coincide con una de las siguientes opciones:

  • Una dirección IPv4 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia externo o una regla de reenvío para el reenvío de protocolos externos
  • Una dirección IPv6 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia externo o una regla de reenvío para el reenvío de protocolos externos, y el paquete no se enruto a través de una ruta de subred importada por el intercambio de tráfico de red de VPC o desde un radio de VPC en un centro de Network Connectivity Center.

Para obtener más información sobre los paquetes que Maglev enruta a las VMs de backend para un balanceador de cargas de red de transferencia externo o el reenvío de protocolos externos, consulta Rutas para balanceadores de cargas de red de transferencia externos y reenvío de protocolos externos.

Alcance de Internet para paquetes de salida

Los paquetes de salida que envían las interfaces de red de la VM y que se enrutan mediante rutas estáticas que usan el siguiente salto de la puerta de enlace de Internet predeterminada se consideran en el alcance de Internet. Sin embargo, si la dirección IP de destino de estos paquetes de salida es para las APIs y los servicios de Google, estos paquetes se consideran en el alcance que no es de Internet. Para obtener más información sobre la conectividad a los servicios y las APIs de Google, consulta Alcance no relacionado con Internet.

Cuando los paquetes se enrutan con una ruta estática que usa el siguiente salto de la puerta de enlace de Internet predeterminada, los paquetes que envían las interfaces de red de la VM a los siguientes destinos se consideran en el alcance de Internet:

  • Un destino de dirección IP externa fuera de la red de Google.
  • Un destino de dirección IPv4 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas externo regional o una regla de reenvío para el reenvío de protocolos externos
  • Un destino de dirección IPv6 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas externo regional o una regla de reenvío para el reenvío de protocolos externos
  • Un destino de dirección IPv4 e IPv6 externa global de una regla de reenvío de un balanceador de cargas externo global.

Los paquetes que envían las interfaces de red de la VM a las puertas de enlace de Cloud VPN y Cloud NAT se consideran dentro del alcance de Internet:

  • Los paquetes de salida que se envían desde una interfaz de red de una VM que ejecuta software de VPN a la dirección IPv4 externa regional de una puerta de enlace de Cloud VPN se consideran dentro del alcance de Internet.
  • Los paquetes de salida que se envían de una puerta de enlace de Cloud VPN a otra puerta de enlace de Cloud VPN no se consideran en ningún alcance de red, ya que las reglas de firewall solo se aplican a las VMs.
  • En el caso de la NAT pública, los paquetes de respuesta que se envían desde una interfaz de red de VM a la dirección IPv4 externa regional de una puerta de enlace de Cloud NAT se consideran en el alcance de Internet.

Si las redes de VPC están conectadas mediante el intercambio de tráfico entre redes de VPC o si las redes de VPC participan como radios de VPC en el mismo centro de Network Connectivity Center, las rutas de subred IPv6 pueden proporcionar conectividad a los destinos de direcciones IPv6 externas regionales de las interfaces de red de VM, las reglas de reenvío de balanceador de cargas externo regional y las reglas de reenvío de protocolos externos. Cuando la conectividad a esos destinos de direcciones IPv6 externas regionales se proporciona a través de una ruta de subred, los destinos se encuentran en el alcance que no es de Internet.

Alcance fuera de Internet

El alcance no de Internet (NON-INTERNET) se puede usar como parte de una combinación de origen de una regla de entrada o como parte de una combinación de destino de una regla de salida:

  • Para una regla de entrada, especifica la fuente de alcance que no es de Internet y al menos un otro parámetro de fuente, excepto una fuente de lista de Threat Intelligence o una fuente de geolocalización. Los paquetes coinciden con la regla de entrada si coinciden con al menos uno de los otros parámetros de origen y coinciden con el parámetro de fuente de rango que no es de Internet.

  • Para una regla de salida, especifica el destino que no sea de Internet y al menos otro parámetro de destino. Los paquetes coinciden con la regla de salida si coinciden con al menos uno de los otros parámetros de destino y con el parámetro de destino de alcance no de Internet.

En el resto de esta sección, se describen los criterios que usa la NGFW de Cloud para determinar si un paquete pertenece al alcance que no es de Internet.

Alcance no de Internet para paquetes de entrada

Los paquetes de entrada enrutados a una interfaz de red de VM con próximos saltos dentro de una red de VPC o desde las APIs y los servicios de Google se consideran dentro del alcance que no es de Internet.

Los paquetes se enrutan mediante próximos saltos dentro de una red de VPC o desde los servicios y las APIs de Google en las siguientes situaciones:

  • El destino del paquete coincide con una de las siguientes opciones:

    • Una dirección IPv4 o IPv6 interna regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de transferencia interno o una regla de reenvío para el reenvío de protocolos internos.
    • Una dirección IPv6 externa regional de una interfaz de red de VM, una regla de reenvío de un balanceador de cargas de red de paso externo o una regla de reenvío para el reenvío de protocolos externos y el paquete se enrutó con una ruta de subred local, una ruta de subred de intercambio de tráfico o una ruta de subred de Network Connectivity Center.
    • Cualquier dirección dentro del rango de destino de una ruta estática en la que la VM receptora sea una VM de próximo salto o una VM de backend de un balanceador de cargas de red de transferencia interno de próximo salto

  • La fuente del paquete coincide con una de las siguientes opciones:

Alcance no de Internet para paquetes de salida

Los paquetes de salida que envían las interfaces de red de la VM y que se enrutan dentro de una red de VPC o se envían a las APIs y los servicios de Google se consideran dentro del alcance no de Internet.

Los paquetes se enrutan mediante próximos saltos dentro de una red de VPC o a las APIs y los servicios de Google en las siguientes situaciones:

Alcance de las redes de VPC

El alcance de redes de VPC (VPC_NETWORKS) solo se puede usar como parte de una combinación de fuentes de una regla de entrada. No puedes usar el alcance de las redes de VPC como parte de una combinación de destino de una regla de salida.

Para usar el alcance de las redes de VPC como parte de una combinación de fuentes de una regla de entrada, haz lo siguiente:

  1. Debes especificar una lista de redes de VPC de origen:

    • La lista de redes de origen debe contener al menos una red de VPC. Puedes agregar un máximo de 250 redes de VPC a la lista de redes de origen.
    • Debe existir una red de VPC para que puedas agregarla a la lista de redes fuente.
    • Puedes agregar la red con su identificador de URL parcial o completo.
    • Las redes de VPC que agregues a la lista de redes de origen no deben estar conectadas entre sí. Cada red de VPC se puede ubicar en cualquier proyecto.
    • Si se borra una red de VPC después de agregarla a la lista de redes fuente, la referencia a la red borrada permanece en la lista. El NGFW de Cloud ignora las redes de VPC borradas cuando se aplica una regla de entrada. Si se borran todas las redes de VPC de la lista de redes de origen, las reglas de entrada que dependen de la lista no son eficaces porque no coinciden con ningún paquete.

  2. Debes especificar al menos otro parámetro de fuente, excepto una fuente de lista de inteligencia sobre amenazas o una fuente de geolocalización.

Un paquete coincide con una regla de entrada que usa el alcance de las redes de VPC en su combinación de origen si se cumplen todas las siguientes condiciones:

  • El paquete coincide con al menos uno de los otros parámetros de origen.

  • Un recurso ubicado en una de las redes de VPC de origen envía el paquete.

  • La red de VPC de origen y la red de VPC a la que se aplica la política de firewall que contiene la regla de entrada son la misma red de VPC, o bien están conectadas a través del intercambio de tráfico entre redes de VPC o como radios de VPC en un concentrador de Network Connectivity Center.

Los siguientes recursos se encuentran en una red de VPC:

  • Interfaces de red de VM
  • Túneles de Cloud VPN
  • Adjuntos de VLAN de Cloud Interconnect
  • Dispositivos del router
  • Proxy de Envoy en una subred de solo proxy
  • Extremos de Private Service Connect
  • Conectores de Acceso a VPC sin servidores

Dentro de la VPC

El alcance de red intra-VPC (INTRA_VPC) solo se puede usar como parte de una combinación de origen de una regla de entrada. No puedes usar el alcance intra-VPC como parte de una combinación de destino de una regla de salida.

Para usar el alcance intra-VPC como parte de una combinación de fuentes de una regla de entrada, debes especificar al menos otro parámetro de fuente, excepto una fuente de lista de amenazas de inteligencia o una fuente de geolocalización.

Un paquete coincide con una regla de entrada que usa el alcance intra-VPC en su combinación de origen si se cumplen todas las siguientes condiciones:

  • El paquete coincide con al menos uno de los otros parámetros de origen.

  • Un recurso ubicado en la red de VPC a la que se aplica la política de firewall que contiene la regla de entrada envía el paquete.

Los siguientes recursos se encuentran en una red de VPC:

  • Interfaces de red de VM
  • Túneles de Cloud VPN
  • Adjuntos de VLAN de Cloud Interconnect
  • Dispositivos del router
  • Proxy de Envoy en una subred de solo proxy
  • Extremos de Private Service Connect
  • Conectores de Acceso a VPC sin servidores

Objetos de ubicación geográfica

Usa objetos de ubicación geográfica en reglas de la política de firewall para filtrar el tráfico IPv4 y el IPv6 externo en función de ubicaciones geográficas o regiones específicas.

Puedes aplicar reglas con objetos de ubicación geográfica al tráfico de entrada y salida. Según la dirección del tráfico, las direcciones IP asociadas con los códigos de país coinciden con el origen o el destino del tráfico.

  • Puedes configurar objetos de ubicación geográfica para políticas de firewall jerárquicas, políticas de firewall de red globales y políticas de firewall de red regionales.

  • Para agregar ubicaciones geográficas a las reglas de la política de firewall, usa los códigos de país o región de dos letras, como se definen en los códigos de país ISO 3166 alfa-2.

    Por ejemplo, si deseas permitir el tráfico entrante solo desde EE.UU. hacia la red, crea una regla de política de firewall de entrada con el código de país de origen establecido como US y la acción establecida como allow. Del mismo modo, si deseas permitir el tráfico saliente solo a EE.UU., configura una regla de política de firewall de salida con el código de país de destino establecido en US y la acción establecida en allow.

  • Cloud NGFW te permite configurar reglas de firewall para los siguientes territorios, sujetos a sanciones completas de EE.UU.:

    Territorios Código asignado
    Crimea XC
    Las denominadas Donetsk People's Republic y Luhansk People's Republic XD

  • Si hay códigos de país duplicados en una sola regla de firewall, solo se conserva una entrada para ese código de país. Se quita la entrada duplicada. Por ejemplo, en la lista de código de país ca,us,us, solo se conserva ca,us.

  • Google mantiene una base de datos con direcciones IP y asignaciones de código de país. Los firewalls de Google Cloud usan esta base de datos para asignar las direcciones IP del tráfico de origen y destino al código de país y, luego, aplican la regla de política de firewall coincidente con los objetos de ubicación geográfica.

  • A veces, las asignaciones de direcciones IP y los códigos de país cambian debido a las siguientes condiciones:

    Debido a que estos cambios tardan un tiempo en reflejarse en la base de datos de Google, es posible que veas algunas interrupciones del tráfico y cambios en el comportamiento del tráfico que se bloquea o se permite.

Usa objetos de ubicación geográfica con otros filtros de reglas de políticas de firewall

Puedes usar objetos de ubicación geográfica junto con otros filtros de origen o de destino. Según su dirección, la regla de política de firewall se aplica al tráfico entrante o saliente que coincide con la unión de todos los filtros especificados.

Para obtener información sobre cómo funcionan los objetos de ubicación geográfica con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en las políticas de firewall jerárquicas y Orígenes para reglas de entrada en las políticas de firewall de red.

Si deseas obtener información para saber cómo funcionan los objetos de ubicación geográfica con otros filtros de destino en las reglas de salida, consulta Destinos para reglas de salida.

Google Threat Intelligence para reglas de políticas de firewall

Las reglas de políticas de firewall te permiten proteger tu red, ya que permiten o bloquean el tráfico según los datos de Google Threat Intelligence. Los datos de Google Threat Intelligence incluyen listas de direcciones IP basadas en las siguientes categorías:

  • Nodos de salida de Tor: Tor es un software de código abierto que habilita la comunicación anónima. Para excluir a los usuarios que ocultan su identidad, bloquea las direcciones IP de los nodos de salida de Tor (extremos en los que el tráfico sale de la red de Tor).
  • Direcciones IP maliciosas conocidas: Direcciones IP que se sabe que son el origen de ataques de aplicaciones web. Para mejorar la posición de seguridad de tu aplicación, bloquea estas direcciones IP.
  • Motores de búsqueda: Direcciones IP que pueden habilitar la indexación de sitios.
  • Rangos de direcciones IP de la nube pública: esta categoría puede bloquearse para evitar que las herramientas maliciosas automatizadas exploren aplicaciones web, o bien se permite si el servicio usa otras nubes públicas. Esta categoría se divide aún más en las siguientes subcategorías:
    • Rangos de direcciones IP que usa Amazon Web Services
    • Rangos de direcciones IP que usa Microsoft Azure
    • Rangos de direcciones IP que usa Google Cloud
    • Rangos de direcciones IP que usan los servicios de Google

Las listas de datos de Google Threat Intelligence pueden incluir direcciones IPv4, direcciones IPv6 o ambas. Para configurar Google Threat Intelligence en tus reglas de políticas de firewall, usa los nombres de lista predefinidos de Google Threat Intelligence según la categoría que desees permitir o bloquear. Estas listas se actualizan de forma continua, lo que protege los servicios de amenazas nuevas sin pasos de configuración adicionales. Los nombres de las listas válidos son los siguientes.

Nombre de la lista Descripción
iplist-tor-exit-nodes Coincide con las direcciones IP de los nodos de salida TOR
iplist-known-malicious-ips Coincide con las direcciones IP que se sabe que atacan aplicaciones web
iplist-search-engines-crawlers Coincide con las direcciones IP de los rastreadores de los motores de búsqueda
iplist-vpn-providers Hace coincidir las direcciones IP que pertenecen a proveedores de VPN de baja reputación
iplist-anon-proxies Coincide con las direcciones IP que pertenecen a proxies anónimos abiertos
iplist-crypto-miners Coincide con las direcciones IP que pertenecen a los sitios de minería de criptomonedas
iplist-public-clouds
  • iplist-public-clouds-aws
  • iplist-public-clouds-azure
  • iplist-public-clouds-gcp
  • iplist-public-clouds-google-services
 Coincide con las direcciones IP que pertenecen a nubes públicas
  • Coincide con los rangos de direcciones IP que usa Amazon Web Services
  • Coincide con los rangos de direcciones IP que usa Microsoft Azure
  • Coincide con los rangos de direcciones IP que usa Google Cloud
  • Coincide con los rangos de direcciones IP que usan los servicios de Google

Usa Google Threat Intelligence con otros filtros de reglas de políticas de firewall

Para definir una regla de política de firewall con Google Threat Intelligence, sigue estos lineamientos:

  • Para las reglas de salida, especifica el destino mediante una o más listas de amenazas de Google.

  • Para las reglas de entrada, especifica el origen mediante una o más listas de amenazas de Google.

  • Puedes configurar listas de Google Threat Intelligence para las políticas de firewall jerárquicas, las políticas de firewall de red globales y las políticas de firewall de red regionales.

  • Puedes usar estas listas junto con otros componentes del filtro de reglas de origen o destino.

    Para obtener información sobre cómo funcionan las listas de Google Threat Intelligence con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en políticas de firewall jerárquicas y Orígenes para reglas de entrada en políticas de firewall de red.

    Para obtener información sobre cómo funcionan las listas de Google Threat Intelligence con otros filtros de destino en las reglas de salida, consulta Destinos para reglas de salida.

  • El registro de firewall se realiza a nivel de la regla. Para que sea más fácil depurar y analizar el efecto de tus reglas de firewall, no incluyas varias listas de Google Threat Intelligence en una sola regla de firewall.

  • Puedes agregar varias listas de Google Threat Intelligence a una regla de política de firewall. Cada nombre de lista incluido en la regla se cuenta como un atributo, sin importar la cantidad de direcciones IP o rangos de direcciones IP incluidos en esa lista. Por ejemplo, si incluiste los nombres de las listas iplist-tor-exit-nodes, iplist-known-malicious-ips y iplist-search-engines-crawlers en tu regla de política de firewall, el recuento de atributos de la regla por política de firewall aumenta en tres. Para obtener más información sobre el recuento de atributos de la regla, consulta Cuotas y límites.

Crea excepciones a las listas de Google Threat Intelligence

Si tienes reglas que se aplican a las listas de Google Threat Intelligence, puedes usar las siguientes técnicas para crear reglas de excepción aplicables a ciertas direcciones IP dentro de una lista de Google Threat Intelligence:

  • Listado selectivo de permisos: supongamos que tienes una regla de firewall de entrada o salida que rechaza los paquetes desde o hacia una lista de Threat Intelligence de Google. Para permitir Paquetes desde o hacia una dirección IP seleccionada dentro de esa lista de Google Threat Intelligence, crea una regla de firewall de permiso de entrada o salida de prioridad más alta que especifique la dirección IP de excepción como fuente o destino.

  • Listado selectivo de denegación: supongamos que tienes una regla de firewall de entrada o salida que permite paquetes desde o hacia una lista de Threat Intelligence de Google. Para rechazar Paquetes desde o hacia una dirección IP seleccionada dentro de esa lista de Google Threat Intelligence, crea una regla de firewall de denegación de entrada o salida de mayor prioridad que especifique la dirección IP de excepción como un origen o un destino.

Grupos de direcciones para políticas de firewall

Los grupos de direcciones son una colección lógica de rangos de direcciones IPv4 o rangos de direcciones IPv6 en formato CIDR. Puedes usar grupos de direcciones para definir orígenes o destinos coherentes a los que hacen referencia muchas reglas de firewall. Los grupos de direcciones se pueden actualizar sin modificar las reglas de firewall que los usan. Para obtener más información sobre los grupos de direcciones, consulta Grupos de direcciones para políticas de firewall.

Puedes definir grupos de direcciones de origen y de destino para las reglas de firewall de entrada y salida, respectivamente.

Para obtener información sobre cómo funcionan los grupos de direcciones de origen con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en políticas de firewall jerárquicas y Orígenes para reglas de entrada en políticas de firewall de red.

Si deseas obtener información sobre cómo funcionan los grupos de direcciones de destino con otros filtros de destino en las reglas de salida, consulta Destinos de las reglas de salida.

Objetos FQDN

Los objetos de nombre de dominio completamente calificados (FQDN) en las reglas de políticas de firewall filtran el tráfico entrante o saliente desde o hacia dominios específicos.

Puedes aplicar reglas de la política de firewall que usen objetos FQDN al tráfico de entrada y el tráfico de salida. Según la dirección del tráfico, las direcciones IP asociadas con los nombres de dominio coinciden con el origen o el destino del tráfico.

  • Puedes configurar objetos FQDN en reglas de políticas de firewall para políticas de firewall jerárquicas, políticas de firewall de red globales y políticas de firewall de red regionales.

  • Debes especificar objetos FQDN en la sintaxis de FQDN estándar.

    Para obtener más información sobre los formatos de nombre de dominio, consulta Formato de nombre de dominio.

  • En intervalos periódicos, Cloud NGFW actualiza las reglas de la política de firewall que contienen objetos FQDN con los resultados de resolución de nombres de dominio más recientes.

  • Los nombres de dominio especificados en las reglas de la política de firewall se resuelven en direcciones IP según el orden de resolución de nombres de VPC de Cloud DNS. Cloud DNS notifica al firewall de Cloud NGFW si hay cambios en los resultados de resolución de nombres de dominio, también conocidos como registros del sistema de nombres de dominio (DNS).

  • Si dos nombres de dominio se resuelven en la misma dirección IP, la regla de la política de firewall se aplica a esa dirección IP, no a un solo dominio. En otras palabras, los objetos FQDN son entidades de capa 3.

  • Si el objeto FQDN en la regla de política de firewall de salida incluye un dominio que tiene CNAME en el registro DNS, debes configurar tu regla de política de firewall de salida con todos los nombres de dominio que tus VMs pueden consultar, incluidos todos los alias posibles, para garantizar un comportamiento confiable de la regla de firewall. Si tus VMs consultan CNAME que no estén configurados en la regla de política de firewall de salida, es posible que la política no funcione durante el cambio de los registros DNS.

  • También puedes usar nombres de DNS internos de Compute Engine en las reglas de tus políticas de firewall de red. Sin embargo, asegúrate de que tu red no esté configurada para usar un servidor de nombres alternativo en la política del servidor saliente.

  • Si deseas agregar nombres de dominio personalizados en las reglas de la política de firewall de red, puedes usar zonas administradas de Cloud DNS para la resolución de nombres de dominio. Sin embargo, asegúrate de que tu red no esté configurada para usar un servidor de nombres alternativo en la política del servidor saliente. Para obtener más información sobre la administración de zonas, consulta Crea, modifica y borra zonas.

Limitaciones

Las siguientes limitaciones se aplican a las reglas de firewall de entrada y salida que usan objetos FQDN:

  • Los objetos FQDN no admiten nombres de dominio de nivel superior (raíz) ni comodines (*). Por ejemplo, *.example.com. y .org no son compatibles.

Puedes usar objetos FQDN en reglas de política de firewall de entrada. Debes tener en cuenta las siguientes limitaciones cuando definas objetos FQDN para las reglas de entrada:

  • Un nombre de dominio se puede resolver en un máximo de 32 direcciones IPv4 y 32 direcciones IPv6. Las consultas de DNS que se resuelven en más de 32 direcciones IPv4 y 32 direcciones IPv6 se truncan para que incluyan solo 32 direcciones IPv4 o IPv6 de esas direcciones IP resueltas. Por lo tanto, no incluyas nombres de dominio que se resuelvan en más de 32 direcciones IPv4 y 32 direcciones IPv6 en las reglas de la política de firewall de entrada.

  • Algunas consultas de nombres de dominio tienen respuestas únicas según la ubicación del cliente solicitante. La ubicación desde la que se realiza la resolución de DNS de la regla de política de firewall es la región de Google Cloud que contiene la VM a la que se aplica la regla de política de firewall.

  • No uses reglas de entrada que usen objetos FQDN si los resultados de la resolución de nombres de dominio son muy variables o si la resolución de nombres de dominio usa una forma de balanceo de cargas basado en DNS. Por ejemplo, muchos nombres de dominio de Google usan un esquema de balanceo de cargas basado en DNS.

Puedes usar objetos FQDN en reglas de política de firewall de salida, pero no te recomendamos usar objetos FQDN con registros A de DNS que tengan un TTL (tiempo de vida) de menos de 90 segundos.

Usa objetos de FQDN con otros filtros de regla de política de firewall

En una regla de política de firewall, puedes definir objetos FQDN junto con otros filtros de origen o destino.

Para obtener información sobre cómo funcionan los objetos FQDN con otros filtros de origen en las reglas de entrada, consulta Orígenes para reglas de entrada en políticas de firewall jerárquicas y Orígenes para reglas de entrada en políticas de firewall de red..

Para obtener información sobre cómo funcionan los objetos FQDN con otros filtros de destino en las reglas de salida, consulta Destinos de las reglas de salida.

Formato del nombre de dominio

Los firewalls de VPC admiten el formato de nombre de dominio como se define en RFC 1035 , RFC 1123 y RFC 4343.

Para agregar nombres de dominio a las reglas de la política de firewall, sigue estos lineamientos de formato:

  • El nombre de dominio debe contener al menos dos etiquetas que se describen de la siguiente manera:

    • Cada etiqueta coincide con expresiones regulares que incluyen solo estos caracteres: [a-z]([-a-z0-9][a-z0-9])?..
    • Cada etiqueta tiene entre 1 y 63 caracteres.
    • Las etiquetas se concatenan con un punto (.).

  • La longitud codificada máxima del nombre de dominio no debe superar los 255 bytes (octetos).

  • También puedes agregar un nombre de dominio internacionalizado (IDN) a las reglas de la política de firewall.

  • Los nombres de dominio deben estar en los formatos Unicode o Punycode.

  • Si especificas un IDN en formato Unicode, el firewall de Google Cloud lo convierte al formato Punycode antes de procesarlo. Como alternativa, puedes usar la herramienta convertidor de IDN para obtener una representación del IDN en Punycode.

  • El firewall de Google Cloud no admite nombres de dominio equivalentes en la misma regla de política de firewall. Después de convertir el nombre de dominio en Punycode, si los dos nombres de dominio difieren como máximo en un punto final, se consideran equivalentes.

Situaciones de excepción con FQDN

Cuando usas objetos FQDN en las reglas de la política de firewall, puedes encontrar las siguientes excepciones durante la resolución del nombre de DNS:

  • Nombre de dominio incorrecto: si especificas uno o más nombres de dominio que usan un formato no válido cuando creas una regla de política de firewall, recibirás un error. No se puede crear la regla de política de firewall, a menos que todos los nombres de dominio tengan el formato correcto.

  • El nombre de dominio no existe (NXDOMAIN): si el nombre de dominio no existe, Google Cloud ignora el objeto FQDN de la regla de política de firewall.

  • Sin resolución de direcciones IP: si el nombre de dominio no se resuelve en ninguna dirección IP, se ignora el objeto FQDN.

  • No se puede acceder al servidor de Cloud DNS: si no se puede acceder a un servidor DNS, las reglas de la política de firewall que usan objetos FQDN solo se aplican si los resultados de resolución de DNS almacenados en caché con anterioridad están disponibles. Los objetos FQDN de la regla se ignoran si no hay resultados de resolución de DNS almacenados en caché o los resultados de DNS han vencido.

¿Qué sigue?