Reglas de firewall de VPC

Las reglas de firewall de la nube privada virtual (VPC) se aplican a un proyecto y a una red determinados. Si deseas aplicar reglas de firewall a varias redes de VPC en una organización, consulta Políticas de firewall. En el resto de esta página, solo se tratan las reglas de firewall de VPC.

Las reglas de firewall de VPC permiten o rechazan las conexiones hacia o desde las instancias de máquina virtual (VM) en la red de VPC. Las reglas de firewall de VPC habilitadas siempre se aplican, ya que protegen las instancias sin importar la configuración ni el sistema operativo, incluso si no se iniciaron.

Cada red de VPC funciona como un firewall distribuido. Mientras que las reglas de firewall se definen a nivel de red, las conexiones se permiten o deniegan por instancia. Se puede considerar que las reglas de firewall de VPC existen entre las instancias y otras redes y, también, entre instancias individuales dentro de la misma red.

Nota: Esta página es una descripción general de las reglas de firewall. Si buscas información sobre cómo crear y trabajar con reglas de firewall, consulta Usa reglas de firewall de VPC.

Para obtener más información acerca de los firewalls, consulta Firewall (computación).

Prácticas recomendadas para las reglas de firewall

Cuando diseñes y evalúes las reglas de firewall, ten en cuenta las siguientes recomendaciones:

• Implementa los principios de privilegio mínimo. Bloquea todo el tráfico de forma predeterminada y solo permite el tráfico específico que necesitas. Esto incluye limitar la regla solo a los protocolos y puertos que necesites.
• Usa las reglas de políticas de firewall jerárquicas para bloquear el tráfico que nunca debe permitirse a nivel de organización o carpeta.
• Para las reglas de “permitir”, especifica la cuenta de servicio de las VM para restringir las reglas a VM específicas.
• Si necesitas crear reglas basadas en direcciones IP, intenta minimizar la cantidad de reglas. Es más fácil realizar un seguimiento de una regla que permite el tráfico a un rango de 16 VM que realizar un seguimiento de 16 reglas independientes.
• Activa el Registro de reglas de firewall y usa Estadísticas de firewall para verificar que las reglas de firewall se usen de la manera prevista. El registro de las reglas de firewall puede generar costos, por lo que recomendamos que lo uses de forma selectiva.

Reglas de firewall en Google Cloud

Cuando creas una regla de firewall de VPC, especificas una red de VPC y un conjunto de componentes que definen lo que hace la regla. Los componentes te permiten orientar ciertos tipos de tráfico según el protocolo, los puertos de destino, los orígenes y los destinos del tráfico. Para obtener más información, consulta los componentes de las reglas de firewall.

Puedes crear o modificar las reglas de firewall de VPC mediante la consola de Google Cloud, Google Cloud CLI y la API de REST. Cuando creas o modificas una regla de firewall, puedes especificar las instancias a las que se aplicará mediante el componente objetivo de la regla. Para ver ejemplos de reglas de firewall, consulta Otros ejemplos de configuración.

Además de las reglas de firewall que creas, Google Cloud tiene otras reglas que pueden afectar las conexiones entrantes (entrada) o salientes (salida):

• Google Cloud bloquea o limita cierto tráfico. Para obtener más información, consulta Tráfico bloqueado y limitado.

• Google Cloud siempre permite la comunicación entre una instancia de VM y su servidor de metadatos correspondiente en 169.254.169.254. Para obtener más información, consulta Tráfico que siempre está permitido.

• Cada red tiene dos reglas de firewall implícitas que permiten las conexiones salientes y bloquean las conexiones entrantes. Las reglas de firewall que crees pueden anular estas reglas implícitas.

• La red predeterminada ya está propagada con reglas de firewall que puedes borrar o modificar.

Especificaciones

Las reglas de firewall de VPC tienen las siguientes características:

• Cada regla de firewall se aplica a las conexiones entrantes (entrada) o salientes (salida), pero no a ambas. Para obtener más información, consulta la dirección de la conexión.

• Las reglas de firewall admiten conexiones IPv4. Las conexiones IPv6 también son compatibles con las redes de VPC que tienen IPv6 habilitado. Cuando especificas un origen o un destino para una regla de entrada o salida por dirección, puedes especificar direcciones o bloques IPv4 o IPv6 en notación de CIDR.

• Cada regla de firewall puede contener rangos IPv4 o IPv6, pero no ambos.

• Cada acción de la regla de firewall es allow o deny. La regla afecta a las conexiones, siempre y cuando se aplique. Por ejemplo, puedes inhabilitar una regla para solucionar problemas.

• Cuando creas una regla de firewall, debes seleccionar una red de VPC. Si bien la regla se aplica a nivel de instancia, su configuración está asociada a una red de VPC. Esto significa que no puedes compartir reglas de firewall entre redes de VPC, incluidas las redes conectadas por el intercambio de tráfico entre redes de VPC o mediante túneles de Cloud VPN.

• Las reglas de firewall de VPC son reglas con estado:

  • Cuando se permite una conexión a través del firewall en cualquier dirección, también se permite el tráfico de retorno que coincide con esta conexión. No se puede configurar una regla de firewall para denegar el tráfico de respuesta asociado.
  • El tráfico de retorno debe coincidir con la tupla de 5 elementos (IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo) del tráfico de solicitudes aceptado, pero con las direcciones de origen, las de destino y los puertos revertidos.
  • Google Cloud asocia los paquetes de entrada a los paquetes de salida correspondientes mediante una tabla de seguimiento de conexiones. Las conexiones IPv4 admiten los protocolos TCP, UDP, ICMP y SCTP. Las conexiones IPv6 admiten los protocolos TCP, UDP, SCTP e ICMPv6.
  • Google Cloud implementa el seguimiento de conexiones sin importar si el protocolo admite conexiones. Si se permite una conexión entre un origen y un objetivo (para una regla de entrada) o entre un objetivo y un destino (para una regla de salida), se permite todo el tráfico de respuesta, siempre y cuando el estado de seguimiento de la conexión del firewall esté activo. El estado de seguimiento de una regla de firewall se considera activo si se envía al menos un paquete cada 10 minutos.
  • Cuando se permite una conexión fragmentada a través del firewall, Google Cloud usa el seguimiento de conexiones para permitir solo el primer fragmento del tráfico de retorno. Para permitir fragmentos de retorno posteriores, debes agregar una regla de firewall.
  • El tráfico de respuesta ICMP, como “ICMP TYPE 3, DESTINATION UNREACHABLE”, se genera en respuesta a una conexión TCP/UDP permitida a través del firewall. Este comportamiento es coherente con RFC 792.

• Las reglas de firewall de VPC no vuelven a ensamblar los paquetes TCP fragmentados. Por lo tanto, una regla de firewall aplicable al protocolo TCP solo puede aplicarse al primer fragmento porque contiene el encabezado TCP. Las reglas de firewall aplicables al protocolo TCP no se aplican a los fragmentos de TCP posteriores.

• La cantidad máxima de conexiones con seguimiento en la tabla de reglas de firewall depende de la cantidad de conexiones con estado compatibles con el tipo de máquina de la instancia. Si se excede la cantidad máxima de conexiones con seguimiento, el seguimiento se detiene para las conexiones que tienen el intervalo de inactividad más largo a fin de permitir el seguimiento de las conexiones nuevas.

  Tipo de máquina de la instancia	Cantidad máxima de conexiones con estado
  Tipos de máquinas de núcleo compartido	130,000
  Instancias que cuentan con 1 a 8 CPU virtuales	130,000 conexiones por CPU virtual
  Instancias con más de 8 CPU virtuales	1,040,000 (130,000 × 8) conexiones en total

Reglas implícitas

Cada red de VPC tiene dos reglas de firewall IPv4 implícitas. Si IPv6 está habilitado en una red de VPC, la red también tiene dos reglas de firewall IPv6 implícitas. Estas reglas no se muestran en la consola de Google Cloud.

Las reglas de firewall IPv4 implícitas están presentes en todas las redes de VPC, sin importar cómo se crean las redes ni si son redes de VPC de modo automático o de modo personalizado. La red predeterminada tiene las mismas reglas implícitas.

• Regla de permiso de salida IPv4 implícita. Una regla de salida cuya acción es allow, el destino es 0.0.0.0/0 y la prioridad es la más baja posible (65535) permite que cualquier instancia envíe tráfico a cualquier destino, excepto el tráfico bloqueado por Google Cloud. Una regla de firewall de mayor prioridad puede restringir el acceso saliente. Se permite el acceso a Internet si ninguna otra regla de firewall deniega el tráfico saliente y si la instancia tiene una dirección IP externa o usa una instancia de Cloud NAT. Para obtener más información, consulta Requisitos de acceso a Internet.

• Regla de denegación de entrada IPv4 implícita. Una regla de entrada cuya acción es deny, el origen es 0.0.0.0/0 y la prioridad es la más baja posible (65535) protege todas las instancias cuando bloquea las conexiones entrantes a ellas. Una regla de mayor prioridad podría permitir el acceso entrante. La red predeterminada incluye algunas reglas adicionales que anulan esta, lo que permite ciertos tipos de conexiones entrantes.

Si IPv6 está habilitado, la red de VPC también tiene estas dos reglas implícitas:

• Regla de permiso de salida IPv6 implícita. Una regla de salida cuya acción es allow, el destino es ::/0 y la prioridad es la más baja posible (65535) permite que cualquier instancia envíe tráfico a cualquier destino, excepto el tráfico bloqueado por Google Cloud. Una regla de firewall de mayor prioridad puede restringir el acceso saliente. Se permite el acceso a Internet si ninguna otra regla de firewall deniega el tráfico saliente y si la instancia tiene una dirección IP externa.

• Regla de denegación de entrada IPv6 implícita. Una regla de entrada cuya acción es deny, el origen es ::/0 y la prioridad es la más baja posible (65535) protege todas las instancias cuando bloquea las conexiones entrantes a ellas. Una regla de mayor prioridad podría permitir el acceso entrante.

Las reglas implícitas no se pueden quitar, pero tienen la menor prioridad posible. Puedes crear reglas que las anulen siempre que tengan prioridades más altas (números de prioridad menores que 65535). Debido a que las reglas deny tienen prioridad sobre las reglas allow de la misma prioridad, una regla allow de entrada con una prioridad de 65535 nunca se aplica.

Reglas ya propagadas en la red predeterminada

La red predeterminada se propaga de forma previa con reglas de firewall que permiten las conexiones entrantes a las instancias. Estas reglas se pueden quitar o modificar según sea necesario:

Nombre de la norma	Dirección	Prioridad	Rangos de origen	Acción	Protocolos y puertos	Descripción
default-allow-internal	ingress	65534	10.128.0.0/9	allow	tcp:0-65535 udp:0-65535 icmp	Permite conexiones entrantes a instancias de VM desde otras instancias dentro de la misma red de VPC.
default-allow-ssh	ingress	65534	0.0.0.0/0	allow	tcp:22	Te permite conectarte a instancias con herramientas como ssh, scp o sftp.
default-allow-rdp	ingress	65534	0.0.0.0/0	allow	tcp:3389	Te permite conectarte a instancias mediante el protocolo de escritorio remoto de Microsoft (RDP).
default-allow-icmp	ingress	65534	0.0.0.0/0	allow	icmp	Te permite usar herramientas como ping.

Puedes crear reglas de firewall similares para las redes que no sean la predeterminada. Consulta Configura las reglas de firewall para casos de uso comunes a fin de obtener más información.

Tráfico bloqueado y limitado

Además de las reglas de firewall de VPC y las políticas de firewall jerárquicas, Google Cloud bloquea o limita cierto tráfico como se describe en la siguiente tabla.

Tipo de tráfico	Detalles
Frecuencia de paquetes y ancho de banda Se aplica a: Todos los paquetes de salida Todos los paquetes de entrada	Google Cloud incluye el ancho de banda por instancia de VM, para cada interfaz de red (NIC) o dirección IP. El tipo de máquina de una VM define su tasa de salida máxima posible. Sin embargo, solo puedes alcanzar esa tasa de salida máxima posible en situaciones específicas. Para obtener más información, consulta Ancho de banda de red en la documentación de Compute Engine.
Ofertas y confirmaciones de DHCP Se aplica a: Paquetes de salida al puerto UDP 68 (DHCPv4) Paquetes de salida al puerto UDP 546 (DHCPv6)	Google Cloud bloquea las ofertas y confirmaciones de DHCP entrantes de todas las fuentes, excepto los paquetes DHCP que provienen del servidor de metadatos.
Protocolos compatibles con direcciones IP externas de Google Cloud Se aplica a: Paquetes de entrada a direcciones IP externas	Las direcciones IPv4 e IPv6 externas solo aceptan paquetes TCP, UDP, ICMP, IPIP, AH, ESP, SCTP y GRE. Los recursos que usan direcciones IP externas imponen restricciones adicionales al protocolo: Reglas de reenvío para los reenvíos de protocolos, balanceadores de cargas de aplicaciones externos, balanceadores de cargas de red del proxy externo y balanceadores de cargas de red de transferencia externos solo procesan los protocolos y puertos configurados en la regla de reenvío. Las puertas de enlace de Cloud VPN solo aceptan protocolos de VPN.
Tráfico de SMTP (puerto 25) Se aplica a: Paquetes de salida a direcciones IP externas en el puerto TCP 25	De forma predeterminada, Google Cloud bloquea los paquetes de salida enviados al puerto de destino TCP 25 de una dirección IP externa (incluida una dirección IP externa de otro recurso de Google Cloud). Sin embargo, este tráfico no se bloquea en proyectos que pertenecen a clientes seleccionados de Google Cloud. En la consola de Google Cloud, tanto la página de redes de VPC como la página de políticas de firewall muestran un mensaje que indica si el puerto SMTP 25 está permitido o no en el proyecto. Este bloque no se aplica a los paquetes de salida enviados al puerto de destino TCP 25 de una dirección IP interna, incluida una dirección IP pública de uso privado en una red de VPC o una red local. Si se permite la salida SMTP externa en el puerto 25 en tu proyecto y deseas enviar este tipo de tráfico, se deben cumplir las siguientes condiciones adicionales: Las reglas de firewall de salida en la red de VPC y las políticas de firewall jerárquicas aplicables a la red de VPC deben permitir la salida a la dirección IP externa en el puerto TCP 25. Las reglas implícitas de permiso de salida cumplen con este requisito porque permiten la salida a cualquier dirección IP, así como las respuestas entrantes establecidas desde cualquier dirección IP. La ruta aplicable al destino debe usar el siguiente salto de puerta de enlace de Internet predeterminado. Las rutas predeterminadas generadas por el sistema cumplen con este requisito. La instancia que envía paquetes a la dirección IP externa debe cumplir con los requisitos de acceso a Internet. Puedes evitar la salida SMTP externa si creas reglas de firewall de VPC de denegación de salida o políticas de firewall jerárquicas.

Tráfico que siempre está permitido

En las instancias de VM, las reglas de firewall de VPC y las políticas de firewall jerárquicas no se aplican a lo siguiente:

• Paquetes enviados al servidor de metadatos de Google Cloud y recibidos desde él

• Paquetes enviados a una dirección IP asignada a una de las interfaces de red (NIC) de la instancia, en la que los paquetes permanecen dentro de la VM. Las direcciones IP asignadas a la NIC de una instancia incluyen lo siguiente:

  • La dirección IPv4 interna principal de la NIC
  • Cualquier dirección IPv4 interna de un rango de IP de alias de la NIC
  • Si se configura IPv6 en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC
  • Una dirección IPv4 interna o externa asociada con una regla de reenvío, para el balanceo de cargas o el reenvío de protocolos, si la instancia es un backend para el balanceador de cargas o una instancia de destino para el reenvío de protocolos
  • Direcciones de bucle invertido
  • Direcciones configuradas como parte del software de superposición de red que ejecutas dentro de la instancia

Servidor de metadatos de Google Cloud

Google Cloud ejecuta un servidor de metadatos local junto con cada instancia en 169.254.169.254. Este servidor es esencial para el funcionamiento de la instancia, por lo que la instancia puede acceder a él sin importar las reglas de firewall que configures. El servidor de metadatos proporciona los siguientes servicios básicos a la instancia:

• DHCP
• Para la resolución de DNS, sigue el orden de resolución de nombres de DNS de la red de VPC
• Metadatos de la instancia
• Protocolo NTP

Interacciones de productos

En las siguientes secciones, se describe cómo interactúan las reglas de firewall y las políticas de firewall jerárquicas con otros productos de Google Cloud.

Reglas de firewall y balanceadores de cargas de transferencia

Las reglas de firewall de VPC y las políticas de firewall jerárquicas controlan cuáles de los protocolos y puertos compatibles con la regla de reenvío pueden acceder a los backends del balanceador de cargas de transferencia. Para obtener detalles, consulta:

• Reglas de firewall en la documentación del balanceador de cargas de red de transferencia externo
• Reglas de firewall en la documentación del balanceador de cargas de red de transferencia interno

Reglas de firewall y balanceadores de cargas de proxy

Para balanceadores de cargas de aplicaciones externos, balanceadores de cargas de aplicaciones internos, balanceadores de cargas de red del proxy internos y balanceadores de cargas de red del proxy externo, las reglas de firewall de VPC y las políticas de firewall jerárquicas no controlan qué protocolos y puertos acepta la dirección IP de la regla de reenvío del balanceador de cargas del proxy. La regla de reenvío sola determina qué protocolos y puertos acepta el balanceador de cargas de proxy.

Las reglas de firewall de VPC y las políticas de firewall jerárquicas controlan cómo estos balanceadores de cargas de proxy se comunican con sus backends. Para obtener detalles, consulta:

• Reglas de firewall en la documentación del balanceador de cargas de aplicaciones externo
• Reglas de firewall en la documentación del balanceador de cargas de aplicaciones interno
• Reglas de firewall en la documentación del balanceador de cargas de red del proxy interno
• Reglas de firewall en la documentación del balanceador de cargas de red del proxy externo

Reglas de firewall y Cloud VPN

Las reglas de firewall y las políticas de firewall jerárquicas no controlan qué protocolos y puertos son aceptados por la puerta de enlace de Cloud VPN.

Las puertas de enlace de Cloud VPN solo aceptan paquetes para los protocolos y puertos que se describen en las especificaciones de Cloud VPN.

Reglas de firewall y GKE

Google Kubernetes Engine crea y administra las reglas de firewall automáticamente cuando creas un clúster o recursos en el clúster (incluidos Ingress y objetos Service). Para obtener más información, consulta las Reglas de firewall creadas automáticamente en la documentación de Google Kubernetes Engine.

Componentes de reglas de firewall

Cada regla de firewall consiste en los siguientes componentes de configuración:

• Una dirección desde la perspectiva del objetivo. La dirección puede ser de entrada o salida.

• Una prioridad numérica, que determina si se aplica la regla. Solo se aplica la regla con la prioridad más alta (número de prioridad más bajo), cuyos otros componentes coinciden con el tráfico. Se ignoran las reglas en conflicto con prioridades más bajas

• Una acción en caso de coincidencia, ya sea allow o deny, que determina si la regla permite o bloquea las conexiones.

• El estado de aplicación de la regla de firewall: Puedes habilitar e inhabilitar reglas de firewall sin tener que borrarlas.

• Un objetivo, que define las instancias (incluidos los clústeres de GKE y las instancias del entorno flexible de App Engine) a las que se aplica la regla

• Un filtro de origen o destino para las características del paquete.

• El protocolo (como TCP, UDP o ICMP) y el puerto de destino

• Una opción booleana de registros que registra las conexiones que hacen que la regla coincida con Cloud Logging.

Resumen de componentes

Regla de entrada (entrante)
Prioridad	Acción	Aplicación	Parámetro de destino	Filtros de origen y destino	Protocolos y puertos
Número entero de 0 a 65535 inclusive; predeterminado: 1000	allow o deny	enabled (predeterminado) o disabled	Especifica las instancias que reciben paquetes.	Orígenes para reglas de entrada Destinos para las reglas de entrada	Especifica un protocolo o un protocolo y un puerto de destino. Si no se establece, la regla se aplica a todos los protocolos y puertos de destino. Para obtener más información, consulta Protocolos y puertos.
Regla de salida (saliente)
Prioridad	Acción	Aplicación	Parámetro de destino	Filtros de origen y destino	Protocolos y puertos
Número entero de 0 a 65535 inclusive; predeterminado: 1000	allow o deny	enabled (predeterminado) o disabled	Especifica las instancias que envían paquetes.	Orígenes para las reglas de salida Destinos para las reglas de salida	Especifica un protocolo o un protocolo y un puerto de destino. Si no se establece, la regla se aplica a todos los protocolos y puertos de destino. Para obtener más información, consulta Protocolos y puertos.

Dirección del tráfico

Puedes crear reglas de firewall que se apliquen al tráfico de entrada o salida. Una sola regla no se puede aplicar al tráfico de entrada y de salida. Sin embargo, puedes crear varias reglas para definir el tráfico de entrada y salida que permites o rechazas a través del firewall.

• Entrada (entrante) describe los paquetes que ingresan a una interfaz de red de un objetivo.

• Salida (saliente) describe los paquetes que dejan una interfaz de red de destino.

• Si no especificas una dirección, Google Cloud usa la de entrada.

Prioridad

La prioridad de la regla de firewall es un número entero de 0 a 65535, inclusive. Los números enteros más bajos indican prioridades más altas. Si no especificas una prioridad cuando creas una regla, se asigna una de 1000.

La prioridad relativa de una regla de firewall determina si es aplicable cuando se evalúa en comparación con otras. La lógica de la evaluación funciona de la siguiente manera:

• La regla de prioridad más alta aplicable a un objetivo para un tipo de tráfico determinado tiene precedencia. La especificidad del objetivo no es relevante. Por ejemplo: una regla de entrada con prioridad más alta para ciertos protocolos y puertos de destino orientada a todos los objetivos anula una regla definida de manera similar con una prioridad menor para los mismos protocolos y puertos de destino orientada a objetivos específicos.

• La regla de prioridad más alta aplicable a una definición de puerto de destino y protocolo determinada tiene prioridad, incluso cuando la definición del puerto de destino y el protocolo son más generales. Por ejemplo, una regla de entrada de prioridad más alta que habilita el tráfico a todos los protocolos y puertos destinados a objetivos específicos anula una regla de entrada de prioridad más baja y rechaza al puerto TCP 22 para los mismos objetivos.

• Una regla con una acción deny anula a otra con una acción allow solo si ambas tienen la misma prioridad. Mediante las prioridades relativas, es posible compilar reglas allow que anulen reglas deny, y reglas deny que anulen a reglas allow.

• Las reglas con la misma prioridad y la misma acción tienen el mismo resultado. Sin embargo, la regla que se usa durante la evaluación es indefinida. En general, no importa qué regla se use, excepto cuando habilitas el registro de reglas de firewall. Si deseas que los registros muestren las reglas de firewall que se evalúan en un orden coherente y bien definido, asígnales prioridades únicas.

Considera el siguiente ejemplo, en el que hay dos reglas de firewall:

• Una regla de entrada de orígenes 0.0.0.0/0 (cualquier dirección IPv4) aplicable a todos los objetivos, protocolos y puertos, con una acción deny y una prioridad de 1000

• Una regla de entrada de orígenes 0.0.0.0/0 (cualquier dirección IPv4) aplicable a objetivos específicos con la etiqueta de red webserver, para el tráfico en TCP 80, con una acción allow.

La prioridad de la segunda regla determina si se permite el tráfico de TCP en el puerto 80 para los objetivos webserver:

• Si la prioridad de la segunda regla es un número mayor que 1000, tiene una prioridad más baja, por lo que se aplica la primera regla que rechaza todo el tráfico.

• Si la prioridad de la segunda regla se establece en 1000, las dos reglas tienen prioridades idénticas, por lo que se aplica la primera regla que niega todo el tráfico.

• Si la prioridad de la segunda regla es un número menor que 1000, tiene una prioridad más alta, de modo que permite el tráfico en TCP 80 para objetivos webserver. En ausencia de otras reglas, la primera regla rechazaría otros tipos de tráfico a los objetivos webserver y, también, rechazaría todo el tráfico, incluido el de TCP 80, a instancias sin la etiqueta webserver.

En el ejemplo anterior, se demuestra cómo puedes usar las prioridades para crear reglas allow selectivas y reglas deny globales a fin de implementar una práctica recomendada de seguridad de privilegio mínimo.

Nota: Cada red tiene dos reglas de firewall implícitas de prioridad baja que no se pueden quitar, y la red predeterminada incluye reglas de firewall adicionales que sí se pueden quitar. Para obtener más información, consulta Reglas implícitas y predeterminadas.

Acción en casos de coincidencia

El componente de acción de una regla de firewall determina si esta permite o bloquea el tráfico y está sujeto a los otros componentes de la regla:

• Una acción allow permite conexiones que coinciden con los otros componentes especificados.

• Una acción deny bloquea conexiones que coinciden con los otros componentes especificados.

Nota: Una regla de firewall solo puede tener un componente de acción. allow y deny no se pueden especificar en la misma regla. Para definir el orden en el que se deben aplicar las reglas, crea reglas de firewall independientes con prioridades diferentes.

Aplicación

Puedes cambiar si una regla de firewall se aplica configurando su estado en enabled o disabled. 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 configura de forma automática como enabled.

Casos de uso

Inhabilitar y habilitar es útil para solucionar problemas y realizar mantenimiento. Considera cambiar la aplicación de una regla de firewall en las siguientes situaciones:

• Para solucionar problemas: Junto con el registro de reglas de firewall, puedes inhabilitar de forma temporal una regla de firewall a fin de determinar si la regla es responsable de bloquear o permitir el tráfico. Esto es útil para situaciones en las que se aplican varias reglas de firewall al mismo tráfico. Inhabilitar y habilitar reglas es más útil que borrar y volver a crear reglas porque ninguno de los otros componentes de la regla se pierde.

• Para realizar tareas de mantenimiento: Inhabilitar reglas de firewall puede simplificar el mantenimiento periódico. Por ejemplo, puedes elegir habilitar una regla de firewall de entrada que permita el acceso SSH solo en ocasiones en las que necesites realizar tareas de mantenimiento con SSH. Cuando no realizas el mantenimiento, puedes inhabilitar la regla.

Efectos sobre el tráfico existente

Cuando cambias el estado de aplicación de una regla de firewall o cuando creas una regla nueva que es enforced, el cambio solo se aplica a las conexiones nuevas. Las conexiones existentes no se ven afectadas por el cambio.

Protocolos y puertos

Para limitar el alcance de una regla de firewall, especifica protocolos o protocolos y puertos de destino. Puedes especificar un protocolo o una combinación de protocolos y sus puertos. Si omites los protocolos y los puertos, la regla de firewall se aplica a todo el tráfico en cualquier protocolo y cualquier puerto de destino. No se admiten reglas basadas en puertos de origen.

No todos los protocolos admiten puertos. Por ejemplo, existen puertos para TCP y UDP, pero no para ICMP. ICMP tiene tipos de ICMP diferentes, pero no son puertos y no se pueden especificar en una regla de firewall.

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, debes usar 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.

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

En la siguiente tabla, se resumen las combinaciones válidas de especificación de protocolos y puertos para las reglas de firewall de Google Cloud.

Especificación	Ejemplo	Explicación
Sin protocolo ni puerto	—	Si no especificas un protocolo, la regla de firewall aplica a todos los protocolos y a sus puertos aplicables.
Protocolo	tcp	Si especificas un protocolo sin información de puertos, la regla de firewall se aplica a ese protocolo y a todos los puertos aplicables.
Protocolo y puerto único	tcp:80	Si especificas un protocolo y un puerto de destino único, la regla de firewall se aplica a ese puerto de destino del protocolo.
Protocolo y rango de puerto	tcp:20-22	Si especificas un protocolo y un rango de puertos, la regla de firewall aplica a ese rango de puertos de destino para el protocolo.
Combinaciones	icmp,tcp:80 tcp:443 udp:67-69	Puedes especificar varias combinaciones de protocolos y puertos de destino a los que se aplica la regla de firewall. Para obtener más información, consulta Crea reglas de firewall.

Importante: Un puerto no se puede especificar por sí solo. Si solo especificas un número, Google Cloud lo interpreta como un protocolo de IP decimal. Por ejemplo, si especificas 80 por sí solo, Google Cloud lo interpreta como un protocolo de IP 80 (ISO-IP), que no es lo mismo que un puerto TCP 80 (tcp:80).

Objetivo, origen y destino

Los objetivos identifican las interfaces de red de las instancias a las que se aplica la regla de firewall.

Puedes especificar los parámetros de origen y 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.

Parámetro de destino

El parámetro de destino 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 siguientes objetivos para las reglas de entrada o salida. Los parámetros de objetivo, origen y destino funcionan juntos como se describe en Origen, destino y objetivo.

• Objetivo predeterminado: todas las instancias de la red de VPC. Cuando omites una especificación de objetivo, la regla de firewall se aplica a todas las instancias en la red de VPC.

• Instancias por etiqueta de red de objetivo: La regla de firewall solo se aplica a las instancias en la red de VPC con una etiqueta de red que coincida. Para conocer la cantidad máxima de etiquetas de objetivo que puedes aplicar por regla de firewall, consulta las cuotas de recursos de VPC.

• Instancias por cuentas de servicio de objetivo. La regla de firewall solo se aplica a las instancias en la red de VPC que usan una cuenta de servicio específica. Para conocer la cantidad máxima de cuentas de servicio de objetivo que puedes aplicar por regla de firewall, consulta Cuotas de recursos de VPC.

Para obtener información sobre los beneficios y las limitaciones de las etiquetas de red de objetivo y las cuentas de servicio de objetivo, consulta la comparación entre el filtrado por cuenta de servicio y por etiqueta de red.

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 alias de 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 como una VM de siguiente salto (next-hop-instance o next-hop-address)

  • Una dirección IP dentro del rango de destino de una ruta estática personalizada mediante un próximo salto de balanceador de cargas de red de transferencia interno (next-hop-ilb), 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 destino 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 alias de 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 si 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, o una instancia de destino 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 (función de vista previa). 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.

Parámetro de origen

Los valores del parámetro de origen dependen de la dirección de la regla de firewall.

Orígenes para reglas de entrada

Puedes usar los siguientes orígenespara las reglas de firewall de entrada:

• Rango de origen predeterminado: Cuando omites una especificación de origen en una regla de entrada, Google Cloud usa el rango de direcciones IPv4 de origen predeterminado 0.0.0.0/0 (cualquier dirección IPv4). El valor predeterminado no incluye los orígenes IPv6.

• 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.

• Etiquetas de red de origen: Una o más etiquetas de red que identifican interfaces de red de instancias de VM en la misma red de VPC que la regla de firewall. Para conocer la cantidad máxima de etiquetas de red de origen por regla de firewall, consulta las cuotas de recursos de VPC. Para obtener detalles sobre las direcciones de origen del paquete cuando se usa esta especificación de origen implícita, consulta Cómo las etiquetas de red de origen y las cuentas de servicio de origen implican los orígenes de paquetes.

• Cuentas de servicio de origen: Una o más cuentas de servicio que identifican interfaces de red de instancias de VM en la misma red de VPC que la regla de firewall. Para conocer la cantidad máxima de cuentas de servicio de origen por regla de firewall, consulta las cuotas de recursos de VPC. Para obtener detalles sobre las direcciones de origen del paquete cuando se usa esta especificación de origen implícita, consulta Cómo las etiquetas de red de origen y las cuentas de servicio de origen implican los orígenes de paquetes.

• Una combinación de fuentes válida: Para todas las combinaciones siguientes, el conjunto de orígenes efectivo consta de la unión de las direcciones IPv4 o IPv6 que se especifican de forma explícita y los rangos de direcciones IP que están implícitos por la etiqueta de red de origen o la cuenta de servicio de origen:

  • Una combinación de rangos IPv4 de origen y etiquetas de red de origen.
  • Una combinación de rangos IPv6 de origen y etiquetas de red de origen.
  • Una combinación de rangos IPv4 de origen y cuentas de servicio de origen.
  • Una combinación de rangos IPv6 de origen y cuentas de servicio de origen.

Importante: Las etiquetas de red y las cuentas de servicio no se pueden usar en la misma regla de firewall. Para obtener más información, consulta la comparación entre el filtrado por cuenta de servicio y por etiqueta de red.

Cómo las etiquetas de red de origen y las cuentas de servicio de origen implican los orígenes de paquetes

Cuando una regla de firewall de entrada usa una etiqueta de red de origen, los paquetes deben emitirse desde una interfaz de red que cumpla con los siguientes criterios:

• La interfaz de red usa la misma red de VPC que la regla de firewall.
• La interfaz de red está asociada con una VM que tiene una etiqueta de red que coincide con la etiqueta de red de origen de la regla de firewall.

Cuando una regla de firewall de entrada usa una cuenta de servicio de origen, los paquetes deben emitirse desde una interfaz de red que cumpla con los siguientes criterios:

• La interfaz de red usa la misma red de VPC que la regla de firewall.
• La interfaz de red está asociada con una VM que tiene una cuenta de servicio que coincide con la cuenta de servicio de origen de la regla de firewall.

Además de especificar una interfaz de red, cuando una regla de firewall de entrada usa una etiqueta de red de origen o una cuenta de servicio de origen, los paquetes emitidos desde la interfaz de red de la VM deben usar una de las siguientes direcciones IP de origen válidas:

• La dirección IPv4 interna principal de esa interfaz de red.
• Cualquier dirección IPv6 asignada a esa interfaz de red.

Si una regla de firewall de entrada también contiene rangos de direcciones IP de destino, la interfaz de red vinculada a una etiqueta de red se resuelve en la misma versión de IP que el rango de IP de destino.

No hay otras direcciones IP de origen de paquetes implícitas cuando se usan etiquetas de red de origen o cuentas de servicio de origen. Por ejemplo, se excluyen los rangos de alias de IP y la dirección IPv4 externa asociada con la interfaz de red. Si necesitas crear reglas de firewall de entrada cuyos orígenes incluyan rangos de alias de direcciones IP o direcciones IPv4 externas, usa rangos de IPv4 de origen.

Orígenes para las reglas de salida

Puedes usar los siguientes orígenes para las reglas de firewall de salida:

• Predeterminada: implicada por el objetivo: Si omites el parámetro de origen de una regla de salida, los orígenes de paquetes se definen de forma implícita como se describe en Objetivos 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 las 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 especificas los parámetros de origen y de destino en una regla de salida, usa la misma versión de IP para ambos parámetros. Puedes usar un rango de direcciones IPv4 o uno IPv6, pero no ambos. Si deseas obtener más detalles, consulta Destinos para las reglas de salida.

Parámetro de destino

Los destinos se pueden especificar mediante rangos de direcciones IP, que son compatibles con las reglas de entrada y salida. 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:

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

• Rangos de IPv4 de destino. Una lista de direcciones IPv4 en formato CIDR.

• Rangos de 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:

• 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 especificas parámetros de origen y de destino en una regla de entrada, los parámetros de origen se resuelven en la misma versión de IP que el rango de direcciones IP de destino. Para obtener más información sobre cómo definir los orígenes de las reglas de entrada, consulta Orígenes para las reglas de entrada.

Destinos para las reglas de salida

Puedes usar los siguientes destinos para las reglas de firewall de salida:

• Rango de destino predeterminado. Cuando omites una especificación de destino en una regla de salida, Google Cloud usa el rango de direcciones IPv4 de destino predeterminado 0.0.0.0/0 (cualquier dirección IPv4). El valor predeterminado no incluye los destinos de IPv6.

• Rangos de IPv4 de destino. Una lista de direcciones IPv4 en formato CIDR.

• Rangos de IPv6 de destino. Una lista de direcciones IPv6 en formato CIDR.

Filtra origen y objetivo por cuenta de servicio

Puedes usar cuentas de servicio para crear reglas de firewall que son de tipo más específico:

• Para las reglas de entrada y de salida, puedes usar cuentas de servicio a fin de especificar objetivos.

• Para las reglas de entrada, puedes especificar el origen de los paquetes entrantes como la dirección IP interna principal de cualquier VM en la red en que la VM usa una cuenta de servicio particular.

La cuenta de servicio se debe crear en el mismo proyecto que la regla de firewall antes de que crees una regla de firewall que se base en ella. Si bien el sistema no te impide crear una regla que use una cuenta de servicio de un proyecto diferente, la regla no se aplica si la cuenta de servicio no existe en el proyecto de la regla de firewall.

Nota: No puedes usar las cuentas de servicio de Workload Identity en las reglas de firewall de VPC para el filtrado de origen y de destino.

Las reglas de firewall que usan cuentas de servicio para identificar instancias se aplican a las instancias nuevas que se crearon y asociaron a la cuenta de servicio y, también, a las instancias existentes si cambias sus cuentas de servicio. Si deseas cambiar la cuenta de servicio asociada con una instancia, debes pararla y reiniciarla. Puedes asociar cuentas de servicio a instancias individuales y plantillas de instancias que usan los grupos de instancias administrados.

Nota: En proyectos con una VPC independiente (una VPC que no participa en una VPC compartida), solo puedes usar cuentas de servicio de ese proyecto como criterios de la regla de firewall. En los proyectos en los que se usa una VPC compartida, puedes usar cuentas de servicio del proyecto host o de cualquier proyecto de servicio como criterios de la regla de firewall. Si creas una regla de firewall que usa cuentas de servicio que no coinciden con estas dos situaciones, la regla de firewall no se aplicará.

Filtra por cuenta de servicio en comparación con etiqueta de red

En esta sección, se destacan los puntos clave que debes tener en cuenta cuando decides si debes usar cuentas de servicio o etiquetas de red para definir objetivos y orígenes (en las reglas de entrada).

Si necesitas un control estricto sobre cómo las reglas de firewall se aplican a las VMs, usa las cuentas de servicio de objetivo y las cuentas de servicio de origen en lugar de etiquetas de red de objetivo y etiquetas de red de origen:

• Una etiqueta de red es un atributo arbitrario. Una o más etiquetas de red pueden asociarse a una instancia de cualquier principal de la administración de identidades y accesos (IAM) que tenga permiso para editarla. Los principales de IAM que cuentan con la función de administrador de instancias de Compute Engine para un proyecto tienen este permiso. Los principales de IAM que pueden editar una instancia pueden cambiar las etiquetas de red, lo que podría cambiar el conjunto de reglas de firewall aplicables para esa instancia.

• Una cuenta de servicio representa una identidad asociada con una instancia. Solo se puede asociar una cuenta de servicio con una instancia. Puedes controlar el acceso a la cuenta de servicio si controlas la asignación de la función de usuario de cuenta de servicio para otros principales de IAM. Para que un principal de IAM inicie una instancia mediante una cuenta de servicio, debe tener la función de usuario de cuenta de servicio al menos en esa cuenta de servicio y los permisos adecuados para crear instancias (por ejemplo, tener la función de administrador de instancias de Compute Engine en el proyecto).

No puedes mezclar y combinar cuentas de servicio y etiquetas de red en ninguna regla de firewall:

• No puedes usar cuentas de servicio de objetivo junto con etiquetas de red de objetivo en ninguna regla de firewall (de entrada o de salida).

• Si especificas objetivos por etiqueta de red de objetivo o cuenta de servicio de objetivo, los siguientes orígenes no son válidos para las reglas de firewall de entrada.

  Destinos	Orígenes no válidos
  Etiquetas de red de objetivo	Cuentas de servicio de origen Combinación de rangos de IP de origen y cuentas de servicio de origen
  Cuenta de servicio de destino	Etiquetas de red de origen Combinación de rangos de IP de origen y etiquetas de red de origen

A continuación, se incluyen consideraciones operativas para las cuentas de servicio y las etiquetas de red:

• Para cambiar una cuenta de servicio de una instancia, es necesario detener y reiniciar la instancia. Se pueden agregar o quitar etiquetas de red mientras la instancia está en ejecución.

• Existe una cantidad máxima de cuentas de servicio de objetivo, cuentas de servicio de origen, etiquetas de red de objetivo y etiquetas de red de origen que se pueden especificar para las reglas de firewall. Para obtener más información, consulta las cuotas de recursos de VPC.

• Si identificas instancias por etiqueta de red, la regla de firewall se aplica a la dirección IP interna principal de la instancia.

• Las reglas de firewall de la cuenta de servicio se aplican al nodo de GKE, no al Pod de GKE.

Funciones y permisos

En la siguiente tabla, se describen los permisos de administración de identidades y accesos (IAM) que necesitas para trabajar con las reglas de firewall de VPC.

Tarea	Permiso necesario	Función de muestra
Crea una regla de firewall	compute.firewalls.create	Administrador de seguridad de Compute (roles/compute.securityAdmin
Borra una regla de firewall	compute.firewalls.delete	Administrador de seguridad de Compute (roles/compute.securityAdmin
Realiza cambios en las reglas de firewall	compute.firewalls.update	Administrador de seguridad de Compute (roles/compute.securityAdmin
Visualiza los detalles de una regla de firewall	compute.firewalls.get	Visualizador de la red de Compute (roles/compute.networkViewer)
Visualiza una lista de reglas de firewall	compute.firewalls.list	Visualizador de la red de Compute (roles/compute.networkViewer)

Casos de uso

Los casos prácticos a continuación demuestran cómo funcionan las reglas de firewall. En estos ejemplos, se habilitaron todas las reglas de firewall.

Casos de entrada

Las reglas de firewall de entrada controlan las conexiones entrantes de un origen a instancias de destino en la red de VPC. El origen para una regla de entrada se puede definir como una de las siguientes opciones:

• Un rango de direcciones IPv4 o IPv6. El valor predeterminado es cualquier dirección IPv4 (0.0.0.0/0).
• Otras instancias en la red de VPC identificadas por etiquetas de red
• Otras instancias en la red de VPC identificadas por cuenta de servicio
• Otras instancias en tu red de VPC identificadas por rango de direcciones IPv4 o IPv6 y por etiqueta de red
• Otras instancias en la red de VPC identificadas por rango de direcciones IPv4 o IPv6 y por cuenta de servicio

El origen predeterminado es cualquier dirección IPv4 (0.0.0.0/0). Si deseas controlar las conexiones entrantes para orígenes externos a la red de VPC, incluidos otros orígenes en Internet, usa un rango de direcciones IP en formato CIDR.

Las reglas de entrada con una acción allow permiten el tráfico entrante según los otros componentes de la regla. Además de especificar el origen y el objetivo de la regla, puedes limitar la regla para hacer que se aplique a protocolos y puertos de destino específicos. Del mismo modo, las reglas de entrada con una acción deny se pueden usar para proteger instancias mediante el bloqueo del tráfico entrante según los componentes de la regla de firewall.

Precaución: También puedes usar cuentas de servicio de objetivo o etiquetas de red de objetivo para especificar los destinos de entrada. Si lo haces, limitas la forma en que puedes especificar el origen de la regla. Para obtener más información, consulta la comparación entre el filtrado por cuenta de servicio y por etiqueta de red.

Ejemplos de entrada

En la figura 1, se ilustran algunos ejemplos en los que las reglas de firewall pueden controlar las conexiones de entrada. En los ejemplos se usa el parámetro de objetivo en la asignación de reglas para aplicar reglas a instancias específicas.

Figura 1. En esta red de VPC de ejemplo, las reglas de firewall de entrada permitida admiten la regla de denegación de entrada implícita para algunas VMs (haz clic para ampliar).

• Una regla de entrada con prioridad 1000 es aplicable a la VM 1. Esta regla permite el tráfico de TCP entrante desde cualquier origen IPv4 (0.0.0.0/0). Se permite el tráfico de TCP de otras instancias en la red de VPC, sujeto a las reglas de salida aplicables para esas otras instancias. La VM 4 se puede comunicar con la VM 1 a través de TCP, ya que la VM 4 no tiene una regla de salida que bloquee esa comunicación (solo se aplica la regla de permiso de salida implícita). Debido a que la VM 1 tiene una IP externa, esta regla también permite el tráfico de TCP entrante desde hosts externos en Internet y desde la VM 2 a través de direcciones IP externas.

• La VM 2 no tiene una regla de firewall de entrada especificada, por lo que la regla de denegación de entrada implícita bloquea todo el tráfico entrante. Se bloquean las conexiones desde otras instancias en la red, sin importar las reglas de salida para las otras instancias. Debido a que la VM 2 tiene una IP externa, hay una ruta de acceso a ella desde hosts externos en Internet, pero la regla de denegación de entrada implícita también bloquea el tráfico entrante externo.

• Una regla de entrada con una prioridad de 1000 es aplicable a la VM 3. Esta regla permite el tráfico de TCP desde instancias en la red con la etiqueta de red client, como la VM 4. Se permite el tráfico de TCP de la VM 4 a la VM 3, ya que la VM 4 no tiene una regla de salida que bloquee esa comunicación (solo se aplica la regla de permiso de salida implícita). Debido a que la VM 3 no tiene una IP externa, no existe una ruta de acceso a ella desde hosts externos en Internet.

Casos de salida

Las reglas de firewall de salida controlan las conexiones salientes desde instancias de objetivo en la red de VPC. Las reglas de salida con una acción allow permiten el tráfico de instancias basadas en los otros componentes de la regla. Por ejemplo, puedes permitir el tráfico saliente a destinos específicos, como un rango de direcciones IPv4, en los protocolos y los puertos de destino que especifiques. Del mismo modo, las reglas de salida con una acción deny bloquean el tráfico en función de los demás componentes de la regla.

Toda regla de salida necesita un destino. El destino predeterminado es cualquier dirección IPv4 (0.0.0.0/0), pero puedes crear un destino más específico si usas un rango de direcciones IPv4 o IPv6 en formato CIDR. Cuando especificas un rango de direcciones IP, puedes controlar el tráfico a instancias en la red y a destinos fuera de ella, incluidos los destinos en Internet.

Ejemplos de salida

En la figura 2, se ilustran algunos ejemplos en los que las reglas de firewall pueden controlar las conexiones de salida. En los ejemplos se usa el parámetro de objetivo en la asignación de reglas para aplicar reglas a instancias específicas.

Figura 2. En esta red de VPC de ejemplo, las reglas de firewall de salida de rechazo anulan la regla de permiso de salida implícita para algunas VMs (haz clic para agrandar).

• La VM 1 no tiene una regla de firewall de salida especificada, por lo que la regla de permiso de salida implícita le permite enviar tráfico a cualquier destino. Se permiten conexiones a otras instancias en la red de VPC. Esto está sujeto a las reglas de entrada aplicables para esas otras instancias. La VM 1 puede enviar tráfico a la VM 4 porque la VM 4 tiene una regla de entrada que permite el tráfico entrante desde cualquier rango de direcciones IP. Debido a que la VM 1 tiene una dirección IP externa, puede enviar tráfico a hosts externos en Internet. Se permiten respuestas entrantes al tráfico enviado por la VM 1 debido a que las reglas de firewall tienen estado.

• Una regla de salida con prioridad 1000 es aplicable a la VM 2. Esta regla rechaza todo el tráfico saliente a todos los destinos IPv4 (0.0.0.0/0). Se bloquea el tráfico saliente a otras instancias en la red de VPC, sin importar las reglas de entrada aplicadas a las otras instancias. Aunque la VM 2 tiene una dirección IP externa, esta regla de firewall bloquea el tráfico saliente hacia hosts externos en Internet.

• Una regla de salida con una prioridad de 1000 es aplicable a la VM 3. Esta regla bloquea el tráfico de TCP saliente hacia cualquier destino en el rango de IP 192.168.1.0/24. Aunque las reglas de entrada para la VM 4 permiten todo el tráfico entrante, la VM 3 no puede enviar tráfico de TCP a la VM 4. Sin embargo, la VM 3 puede enviar tráfico de UDP a la VM 4 porque la regla de salida solo se aplica al protocolo TCP.

  Además, la VM 3 puede enviar tráfico a otras instancias en la red de VPC fuera del rango de IP 192.168.1.0/24, siempre que esas otras instancias tengan reglas de entrada para permitir ese tráfico. Debido a que no tiene una dirección IP externa, no cuenta con una ruta de acceso para enviar tráfico fuera de la red de VPC.

¿Qué sigue?

• Para crear y trabajar con reglas de firewall, consulta Usa reglas de firewall de VPC.

Pruébalo tú mismo

Si es la primera vez que usas Google Cloud, crea una cuenta para evaluar el rendimiento de Cloud NGFW en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Probar Cloud NGFW gratis