Reglas de cortafuegos de VPC

Las reglas de cortafuegos de nube privada virtual (VPC) se aplican a un proyecto y una red concretos. Si quieres aplicar reglas de cortafuegos a varias redes de VPC de una organización, consulta Políticas de cortafuegos. El resto de esta página solo trata sobre las reglas de cortafuegos de VPC.

Las reglas de cortafuegos de VPC te permiten aceptar o rechazar conexiones a o desde instancias de máquina virtual (VM) de tu red de VPC. Las reglas de cortafuegos de VPC habilitadas se aplican siempre, lo que protege tus instancias independientemente de su configuración y sistema operativo, incluso si no se han iniciado.

Cada red de VPC funciona como un cortafuegos distribuido. Aunque las reglas de cortafuegos se definen a nivel de red, las conexiones se permiten o se deniegan por instancia. Puedes considerar que las reglas de cortafuegos de VPC no solo existen entre tus instancias y otras redes, sino también entre las instancias individuales de la misma red.

Para obtener más información sobre los cortafuegos, consulta el artículo Cortafuegos (informática).

Prácticas recomendadas para las reglas de cortafuegos

Cuando diseñes y evalúes tus reglas de cortafuegos, ten en cuenta las siguientes prácticas recomendadas:

Reglas de cortafuegos en Google Cloud

Cuando creas una regla de cortafuegos de VPC, especificas una red de VPC y un conjunto de componentes que definen lo que hace la regla. Los componentes te permiten orientar tus anuncios a determinados tipos de tráfico en función del protocolo, los puertos de destino, las fuentes y los destinos del tráfico. Para obtener más información, consulta los componentes de las reglas de cortafuegos.

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

Además de las reglas de cortafuegos que crees, Google Cloud tiene otras reglas que pueden afectar a las conexiones entrantes o salientes:

  • Google Cloud bloquea o limita determinado 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 siempre permitido.

  • Todas las redes tienen dos reglas de cortafuegos implícitas que permiten las conexiones salientes y bloquean las entrantes. Las reglas de cortafuegos que crees pueden anular estas reglas implícitas.

  • La red predeterminada ya tiene reglas de cortafuegos que puedes eliminar o modificar.

Especificaciones

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

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

  • Las reglas de cortafuegos admiten conexiones IPv4. Las conexiones IPv6 también se admiten en redes de VPC que tengan IPv6 habilitado. Al especificar una fuente o un destino para una regla de entrada o salida por dirección, puede especificar direcciones o bloques IPv4 o IPv6 en notación CIDR.

  • Cada regla de cortafuegos puede contener intervalos IPv4 o IPv6, pero no ambos.

  • La acción de cada regla de cortafuegos es allow o deny. La regla se aplica a las conexiones mientras esté habilitada. Por ejemplo, puedes inhabilitar una regla para solucionar problemas.

  • Cuando creas una regla de cortafuegos, debes seleccionar una red de VPC. Aunque 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 cortafuegos entre redes de VPC, incluidas las redes conectadas mediante el emparejamiento entre redes de VPC o mediante túneles de Cloud VPN.

  • Las reglas de cortafuegos de VPC son con estado:

    • Cuando se permite una conexión a través del cortafuegos en cualquier dirección, también se permite el tráfico de retorno que coincida con esta conexión. No puedes configurar una regla de cortafuegos para denegar el tráfico de respuesta asociado.
    • El tráfico de retorno debe coincidir con la quíntupla (IP de origen, IP de destino, puerto de origen, puerto de destino y protocolo) del tráfico de solicitud aceptado, pero con las direcciones y los puertos de origen y de destino invertidos.
    • Google Cloud Asocia los paquetes entrantes con los paquetes salientes correspondientes mediante una tabla de seguimiento de conexiones. Las conexiones IPv4 admiten los protocolos TCP, UDP, SCTP e ICMP. Las conexiones IPv6 admiten los protocolos TCP, UDP, SCTP e ICMPv6.
    • Google Cloud implementa el seguimiento de conexiones independientemente de si el protocolo admite conexiones. Si se permite una conexión entre un origen y un destino (en el caso de una regla de entrada) o entre un destino y un origen (en el caso de una regla de salida), se permite todo el tráfico de respuesta siempre que el estado de seguimiento de conexiones del cortafuegos 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 cortafuegos,Google Cloud usa el seguimiento de conexiones para permitir solo el primer fragmento del tráfico de retorno. Para permitir fragmentos de devolución posteriores, debes añadir una regla de cortafuegos.
    • El tráfico de respuesta ICMP, como "ICMP TYPE 3, DESTINATION UNREACHABLE" (ICMP TIPO 3, DESTINO INACCESIBLE), generado en respuesta a una conexión TCP/UDP permitida, se permite a través del cortafuegos. Este comportamiento es coherente con RFC 792.

  • Las reglas de cortafuegos de VPC no vuelven a ensamblar los paquetes TCP fragmentados. Por lo tanto, una regla de cortafuegos aplicable al protocolo TCP solo se puede aplicar al primer fragmento, ya que contiene la cabecera TCP. Las reglas de cortafuegos aplicables al protocolo TCP no se aplican a los fragmentos TCP posteriores.

  • El número máximo de conexiones rastreadas en la tabla de reglas de cortafuegos depende del número de conexiones con estado que admita el tipo de máquina de la instancia. Si se supera el número máximo de conexiones monitorizadas, se detiene la monitorización de las conexiones que tengan el intervalo de inactividad más largo para permitir que se monitoricen nuevas conexiones.

    Tipo de máquina de la instancia Número máximo de conexiones con estado
    Tipos de máquinas de núcleo compartido 130.000
    Instancias con entre 1 y 8 vCPUs 130.000 conexiones por vCPU
    Instancias con más de 8 vCPUs 1.040.000 (130.000 × 8) conexiones en total

Reglas implícitas

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

Las reglas de cortafuegos IPv4 implícitas están presentes en todas las redes de VPC, independientemente de cómo se creen y de si son redes de VPC automáticas o de modo personalizado. La red predeterminada tiene las mismas reglas implícitas.

  • Regla de salida implícita de IPv4. Una regla de salida cuya acción sea allow, cuyo destino sea 0.0.0.0/0 y cuya prioridad sea 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. Es posible que una regla de cortafuegos de mayor prioridad restrinja el acceso saliente. Se permite el acceso a Internet si ninguna otra regla de cortafuegos 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 los requisitos de acceso a Internet.

    Para obtener información sobre los requisitos de enrutamiento, consulta los requisitos de acceso a Internet.

  • Regla de denegación de entrada IPv4 implícita. Una regla de entrada cuya acción es deny, la fuente es 0.0.0.0/0 y la prioridad es la más baja posible (65535) protege todas las instancias bloqueando las conexiones entrantes. Una regla de mayor prioridad puede 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 salida de IPv6 implícita. Una regla de salida cuya acción sea allow, cuyo destino sea ::/0 y cuya prioridad sea 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. Es posible que una regla de cortafuegos de mayor prioridad restrinja el acceso saliente. Para obtener información sobre los requisitos de enrutamiento, consulta los requisitos de acceso a Internet.

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

Las reglas implícitas no se pueden quitar, pero tienen las prioridades más bajas posibles. Puede crear reglas que las anulen siempre que tengan una prioridad mayor (números de prioridad inferiores a 65535). Como 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 predefinidas en la red predeterminada

La red predeterminada se rellena previamente con reglas de cortafuegos que permiten conexiones entrantes a las instancias. Estas reglas se pueden eliminar o modificar según sea necesario:

Nombre de la regla Dirección Prioridad Intervalos 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 las conexiones entrantes a instancias de VM desde otras instancias de la misma red 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 (RDP) de Microsoft.
default-allow-icmp ingress 65534 0.0.0.0/0 allow icmp Te permite usar herramientas como ping.

Puedes crear reglas de cortafuegos similares para redes que no sean la predeterminada. Para obtener más información, consulta Configurar reglas de cortafuegos para casos prácticos habituales.

Tráfico bloqueado y limitado

A diferencia de las reglas de cortafuegos de VPC y las políticas de cortafuegos jerárquicas, Google Cloud bloquea o limita determinado tráfico, tal como se describe en la siguiente tabla.

Tipo de tráfico Detalles
Tasa de paquetes y ancho de banda

Se aplica a:

  • Todos los paquetes de salida
  • Todos los paquetes de entrada
 Google Cloud tiene en cuenta 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 entrada al puerto UDP 68 (DHCPv4)
  • Paquetes de entrada al puerto UDP 546 (DHCPv6)
 Google Cloud bloquea las ofertas y los acuses de recibo de DHCP entrantes de todas las fuentes excepto los paquetes DHCP procedentes del servidor de metadatos.
Protocolos admitidos por las direcciones IP externas 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 de protocolo adicionales:
Tráfico SMTP (puerto 25)

Se aplica a:

  • Paquetes de salida a direcciones IP externas en el puerto TCP 25

Para evitar el spam, de forma predeterminada, se Google Cloud bloquean los paquetes de salida enviados al puerto de destino TCP 25 de una dirección IP externa (incluida la dirección IP externa de otro Google Cloud recurso). Google Cloud elimina automáticamente este bloqueo cuando determina que un proyecto tiene un riesgo bajo de enviar grandes volúmenes de correo a través de conexiones sin cifrar. Google Cloud excluye de este bloqueo el tráfico SMTP a través de TLS en los puertos 465 o 587. Para saber si tu proyecto permite este tráfico, ve a la página Redes de VPC o a la página Políticas de cortafuegos de la Google Cloud consola. Un mensaje de banner en ambas páginas indica si tu proyecto permite este tráfico. Para obtener más información, ponte en contacto con un Google Cloud especialista en ventas.

Este bloqueo 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 usada de forma privada en una red VPC o en una red local.

Si se permite el tráfico de salida SMTP externo en el puerto 25 de tu proyecto y quieres enviar este tipo de tráfico, debes cumplir las siguientes condiciones adicionales:

  • Las reglas de cortafuegos de salida de la red de VPC y las políticas de cortafuegos 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 de salida implícitas cumplen este requisito porque permiten la salida a cualquier dirección IP (y las respuestas entrantes establecidas desde ella).
  • La ruta aplicable al destino debe usar el siguiente salto de la pasarela de Internet predeterminada. Las rutas predeterminadas generadas por el sistema cumplen este requisito.
  • La instancia que envía paquetes a la dirección IP externa debe cumplir los requisitos de acceso a Internet.

Puedes impedir la salida SMTP externa creando reglas de cortafuegos de VPC de denegación de salida o políticas de cortafuegos jerárquicas.

Tráfico siempre permitido

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

  • Paquetes enviados y recibidos del Google Cloud servidor de metadatos

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

    • Dirección IPv4 interna principal de la NIC.
    • Cualquier dirección IPv4 interna de un intervalo de IPs alias de la NIC
    • Si IPv6 está configurado en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC
    • Una dirección IPv4 interna o externa asociada a una regla de reenvío, para el balanceo de carga o el reenvío de protocolos, si la instancia es un backend del balanceador de carga 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 redes que ejecutas en la propia instancia

Google Cloud servidor de metadatos

Google Cloud ejecuta un servidor de metadatos local junto a 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 independientemente de las reglas de cortafuegos que configure. El servidor de metadatos proporciona los siguientes servicios básicos a la instancia:

Interacciones con el producto

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

Reglas de cortafuegos y balanceadores de carga de paso a través

Las reglas de cortafuegos de VPC y las políticas de cortafuegos jerárquicas controlan qué protocolos y puertos admitidos de la regla de reenvío pueden acceder a los backends del balanceador de carga de tipo pases. Para obtener información detallada, consulta estos enlaces:

Reglas de cortafuegos y balanceadores de carga de proxy

En el caso de los balanceadores de carga de aplicaciones externos, los balanceadores de carga de aplicaciones internos, los balanceadores de carga de red con proxy internos y los balanceadores de carga de red con proxy externos, las reglas de cortafuegos de VPC y las políticas de cortafuegos jerárquicas no controlan qué protocolos y puertos acepta la dirección IP de la regla de reenvío del balanceador de carga de proxy. La regla de reenvío por sí sola determina qué protocolos y puertos acepta el balanceador de carga proxy.

Las reglas de cortafuegos de VPC y las políticas de cortafuegos jerárquicas controlan cómo se comunican estos balanceadores de carga proxy con sus backends. Para obtener más información, consulta:

Reglas de cortafuegos y Cloud VPN

Las reglas de cortafuegos y las políticas de cortafuegos jerárquicas no controlan qué protocolos y puertos acepta la pasarela de Cloud VPN.

Las pasarelas de Cloud VPN solo aceptan paquetes de los protocolos y puertos descritos en las especificaciones de Cloud VPN.

Reglas de cortafuegos y GKE

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

Reglas de cortafuegos y AI Hypercomputer

Puedes crear reglas de cortafuegos de VPC al crear las redes de VPC necesarias para crear VMs en AI Hypercomputer. Usa las reglas de cortafuegos para especificar los protocolos y puertos permitidos en tus redes de VPC. Para obtener más información, consulta la descripción general de AI Hypercomputer.

Componentes de las reglas de cortafuegos

Cada regla de cortafuegos consta de los siguientes componentes de configuración:

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

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

  • Una acción tras 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 cortafuegos: puedes habilitar y inhabilitar reglas de cortafuegos sin eliminarlas.

  • Un destino, 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 de los paquetes.

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

  • Una opción booleana logs que registra las conexiones que coinciden con la regla en Cloud Logging.

Resumen de componentes

Regla de entrada
Prioridad Acción Aplicación Parámetro de destino Filtros de origen y destino Protocolos y puertos
Número entero de 0 a 65535, ambos incluidos. El valor predeterminado es 1000. allow o deny enabled (valor predeterminado) o disabled Especifica las instancias que reciben paquetes.

Fuentes de las reglas de entrada

Destinos de las reglas de entrada

Especifica un protocolo o un protocolo y un puerto de destino.

Si no se define, 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
Prioridad Acción Aplicación Parámetro de destino Filtros de origen y destino Protocolos y puertos
Número entero de 0 a 65535, ambos incluidos. El valor predeterminado es 1000. allow o deny enabled (valor predeterminado) o disabled Especifica las instancias que envían paquetes.

Fuentes de las reglas de salida

Destinos de las reglas de salida

Especifica un protocolo o un protocolo y un puerto de destino.

Si no se define, 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

Puede crear reglas de cortafuegos que se apliquen al tráfico de entrada o de salida. Una sola regla no puede aplicarse 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 deniegas a través del cortafuegos.

  • El tráfico de entrada describe los paquetes que entran en una interfaz de red de un destino.

  • El tráfico de salida describe los paquetes que salen de una interfaz de red de un destino.

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

Prioridad

La prioridad de la regla de cortafuegos es un número entero comprendido entre 0 y 65535, ambos incluidos. Los números enteros más bajos indican prioridades más altas. Si no especifica una prioridad al crear una regla, se le asignará la prioridad 1000.

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

  • Prevalece la regla de prioridad más alta que se aplique a un objetivo para un tipo de tráfico concreto. La especificidad de la segmentación no importa. Por ejemplo, una regla de entrada de mayor prioridad para determinados puertos y protocolos de destino, que se aplica a todos los destinos, anula una regla definida de forma similar con menor prioridad para los mismos puertos y protocolos de destino, que se aplica a destinos específicos.

  • La regla de mayor prioridad aplicable a un protocolo y una definición de puerto de destino determinados tiene prioridad, incluso cuando la definición de protocolo y puerto de destino es más general. Por ejemplo, una regla de entrada de mayor prioridad que permite el tráfico de todos los protocolos y puertos de destino destinados a determinados destinos anula una regla de entrada de menor prioridad que deniega el TCP 22 para los mismos destinos.

  • Una regla con la acción deny anula otra con la acción allow solo si las dos reglas tienen la misma prioridad. Con las prioridades relativas, es posible crear reglas allow que anulen reglas deny y reglas deny que anulen reglas allow.

  • Las reglas con la misma prioridad y la misma acción tienen el mismo resultado. Sin embargo, la regla que se utiliza durante la evaluación es indeterminada. Normalmente, no importa qué regla se utilice, excepto cuando habilitas la función Almacenamiento de registros de reglas de cortafuegos. Si quiere que sus registros muestren las reglas de cortafuegos que se están evaluando en un orden coherente y bien definido, asígneles prioridades únicas.

Veamos un ejemplo en el que hay dos reglas de cortafuegos:

  • Una regla de entrada de las fuentes 0.0.0.0/0 (cualquier dirección IPv4) aplicable a todos los destinos, todos los protocolos y todos los puertos de destino, con una acción deny y una prioridad 1000.

  • Una regla de entrada de fuentes 0.0.0.0/0 (cualquier dirección IPv4) aplicable a destinos 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 TCP al puerto 80 para los destinos webserver:

  • Si la prioridad de la segunda regla se establece en un número mayor que 1000, tiene una prioridad menor, por lo que se aplica la primera regla que deniega todo el tráfico.

  • Si la prioridad de la segunda regla es 1000, las dos reglas tienen la misma prioridad, por lo que se aplica la primera regla, que deniega todo el tráfico.

  • Si la prioridad de la segunda regla se establece en un número inferior a 1000, tiene una prioridad mayor, lo que permite el tráfico en el puerto TCP 80 para los destinos webserver. Si no hubiera otras reglas, la primera seguiría denegando otros tipos de tráfico a los destinos webserver y también denegaría todo el tráfico, incluido el TCP 80, a las instancias sin la etiqueta de red webserver.

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

Acción tras coincidencia

El componente de acción de una regla de cortafuegos determina si permite o bloquea el tráfico, en función de los demás componentes de la regla:

  • Una acción allow permite las conexiones que coincidan con los demás componentes especificados.

  • Una acción deny bloquea las conexiones que coinciden con los demás componentes especificados.

Aplicación

Puede elegir si una regla de cortafuegos está aplicada configurando su estado como enabled o disabled. Puedes definir el estado de aplicación al crear una regla o al actualizarla.

Si no define un estado de aplicación al crear una regla de cortafuegos, esta se enabled automáticamente.

Casos prácticos

Habilitar e inhabilitar son opciones útiles para solucionar problemas y realizar tareas de mantenimiento. Te recomendamos que cambies la aplicación de una regla de cortafuegos en las siguientes situaciones:

  • Para solucionar problemas: junto con la función Almacenamiento de registros de reglas de cortafuegos, puedes inhabilitar temporalmente una regla de cortafuegos para determinar si es la responsable de bloquear o permitir el tráfico. Esto resulta útil en situaciones en las que se aplican varias reglas de cortafuegos al mismo tráfico. Es más útil inhabilitar y habilitar reglas que eliminarlas y volver a crearlas, ya que no se pierde ninguno de los otros componentes de la regla.

  • Mantenimiento: inhabilitar las reglas de cortafuegos puede simplificar el mantenimiento periódico. Por ejemplo, puedes habilitar una regla de firewall de entrada que permita el acceso SSH solo cuando necesites realizar tareas de mantenimiento mediante SSH. Cuando no estés realizando tareas de mantenimiento, puedes inhabilitar la regla.

Efectos en el tráfico actual

Cuando cambias el estado de aplicación de una regla de cortafuegos o creas una regla que está enforced, el cambio se aplica solo a las conexiones nuevas. Los cambios no afectan a las conexiones que ya tengas.

Protocolos y puertos

Puede acotar el ámbito de una regla de cortafuegos especificando protocolos o protocolos y puertos de destino. Puede especificar un protocolo o una combinación de protocolos y sus puertos de destino. Si omite tanto los protocolos como los puertos, la regla de cortafuegos se aplicará a todo el tráfico de cualquier protocolo y cualquier puerto de destino. No se admiten reglas basadas en puertos de origen.

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

Puede usar los siguientes nombres de protocolo en las reglas de cortafuegos: tcp, udp, icmp (para ICMP de IPv4), esp, ah, sctp y ipip. En el resto de los protocolos, debes usar los números de protocolo de IANA.

Muchos protocolos usan el mismo nombre y número tanto en IPv4 como en IPv6, pero algunos protocolos, como ICMP, no lo hacen.

El protocolo de salto a salto de IPv6 no se admite en las reglas de cortafuegos.

En la siguiente tabla se resumen las combinaciones válidas de protocolo y puerto de destino para las reglas de cortafuegos de Google Cloud .

Especificaciones Ejemplo Explicación
Sin protocolo ni puerto — Si no especifica ningún protocolo, la regla de cortafuegos se aplicará a todos los protocolos y a sus puertos de destino correspondientes.
Protocolo tcp Si especifica un protocolo sin información de puerto, la regla de cortafuegos se aplicará a ese protocolo y a todos sus puertos aplicables.
Protocolo y un solo puerto tcp:80 Si especifica un protocolo y un solo puerto de destino, la regla de firewall se aplica a ese puerto de destino del protocolo.
Protocolo e intervalo de puertos tcp:20-22 Si especificas un protocolo y un intervalo de puertos, la regla de cortafuegos se aplica a ese intervalo de puertos de destino del protocolo.
Combinaciones icmp,tcp:80
tcp:443
udp:67-69		 Puede especificar varias combinaciones de protocolos y puertos de destino a los que se aplica la regla de cortafuegos. Para obtener más información, consulta el artículo Crear reglas de firewall.

Destino, origen y destino

Los destinos identifican las interfaces de red de las instancias a las que se aplica la regla de cortafuegos.

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

Parámetro de destino

El parámetro target 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 destinos para las reglas de entrada o de salida. Los parámetros target, source y destination funcionan conjuntamente tal como se describe en Origen, destino y objetivo.

  • Destino predeterminado: todas las instancias de la red de VPC. Si no especificas un destino, la regla de cortafuegos se aplicará a todas las instancias de la red de VPC.

  • Instancias por etiquetas de red de destino. La regla de cortafuegos solo se aplica a las instancias con interfaces de red en la red de VPC de la regla de cortafuegos si las instancias tienen una etiqueta de red que coincida con al menos una de las etiquetas de red de destino de la regla de cortafuegos. Para ver el número máximo de etiquetas de red de destino que puedes especificar por regla de cortafuegos, consulta los límites por regla de cortafuegos.

  • Instancias por cuentas de servicio de destino. La regla de cortafuegos solo se aplica a las instancias con interfaces de red en la red VPC de la regla de cortafuegos si las instancias usan una cuenta de servicio que coincida con al menos una de las cuentas de servicio de destino de la regla de cortafuegos. Para consultar el número máximo de cuentas de servicio de destino que puedes especificar por regla de cortafuegos, consulta los límites por regla de cortafuegos.

Para obtener información sobre las ventajas y las limitaciones de las etiquetas de red de destino y las cuentas de servicio de destino, consulta Filtrar por cuenta de servicio o por etiqueta de red.

Destinos y direcciones IP de las 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 cortafuegos de entrada incluye un intervalo de direcciones IP de destino, el destino del paquete debe estar dentro de uno de los intervalos de direcciones IP de destino definidos explícitamente.

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

    • La dirección IPv4 interna principal asignada a la interfaz de red de la instancia.

    • Cualquier intervalo de IP de alias configurado en la NIC de la instancia.

    • La dirección IPv4 externa asociada a la interfaz de red de la instancia.

    • Si IPv6 está configurado en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC.

    • Una dirección IP interna o externa asociada a una regla de reenvío que se usa para el balanceo de carga de paso a través, donde la instancia es un backend de un balanceador de carga de red de paso a través interno o externo.

    • Una dirección IP interna o externa asociada a una regla de reenvío usada para el reenvío de protocolos, donde la instancia se hace referencia mediante una instancia de destino.

    • Una dirección IP dentro del intervalo de destino de una ruta estática personalizada que usa la instancia como máquina virtual de salto siguiente (next-hop-instance o next-hop-address).

    • Una dirección IP dentro del intervalo de destino de una ruta estática personalizada que use un salto siguiente de un balanceador de carga de red de paso a través interno (next-hop-ilb), si la VM es un backend de ese balanceador de carga.

Destinos y direcciones IP de las 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 de la VM de destino. El reenvío de IP está inhabilitado de forma predeterminada.

  • Si la máquina virtual de destino tiene inhabilitado el reenvío de IP, puede emitir paquetes con las siguientes fuentes:

    • Dirección IPv4 interna principal de la interfaz de red de una instancia.

    • Cualquier intervalo de IP de alias configurado en la NIC de una instancia.

    • Si IPv6 está configurado en la subred, cualquiera de las direcciones IPv6 asignadas a la NIC.

    • Una dirección IP interna o externa asociada a una regla de reenvío para el balanceo de carga de paso a través o el reenvío de protocolos, si la instancia es un backend de un balanceador de carga de red de paso a través interno o externo, o si una instancia de destino hace referencia a ella.

    Si la regla de cortafuegos de salida incluye intervalos de direcciones IP de origen, las VMs de destino seguirán estando limitadas a las direcciones IP de origen mencionadas anteriormente, pero el parámetro de origen se puede usar para acotar ese conjunto. Si se usa un parámetro de origen sin habilitar el reenvío de IP, no se amplía el conjunto de posibles direcciones de origen de los paquetes.

    Si la regla de cortafuegos de salida no incluye un intervalo de direcciones IP de origen, se permiten todas las direcciones IP de origen mencionadas anteriormente.

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

Parámetro de origen

Los valores de los parámetros de origen dependen de la dirección de la regla de firewall.

Fuentes de las reglas de entrada

Puedes usar las siguientes fuentes para las reglas de cortafuegos de entrada:

  • Intervalo de origen predeterminado: si omite una especificación de origen en una regla de entrada, Google Cloud se usa el intervalo de direcciones IPv4 de origen predeterminado 0.0.0.0/0 (cualquier dirección IPv4). El valor predeterminado no incluye fuentes IPv6.

  • Intervalos de IPv4 de origen: una lista de direcciones IPv4 en formato CIDR.

  • Intervalos de IPv6 de origen: una lista de direcciones IPv6 en formato CIDR.

  • Etiquetas de red de origen: una o varias etiquetas de red que identifican las interfaces de red de las instancias de VM de la misma red de VPC que la regla de cortafuegos. Para consultar el número máximo de etiquetas de red de origen por regla de cortafuegos, consulta los límites por regla de cortafuegos. Para obtener más información sobre cómo se emparejan las direcciones de origen de los paquetes cuando se usa esta especificación de origen implícita, consulta Cómo implican las etiquetas de red de origen y las cuentas de servicio de origen las fuentes de paquetes.

  • Cuentas de servicio de origen: una o varias cuentas de servicio que identifican las interfaces de red de las instancias de VM en la misma red VPC que la regla de cortafuegos. Para consultar el número máximo de cuentas de servicio de origen por regla de cortafuegos, consulta los límites por regla de cortafuegos. Para obtener información sobre cómo se emparejan las direcciones de origen de los paquetes cuando se usa esta especificación de origen implícita, consulta Cómo implican las etiquetas de red de origen y las cuentas de servicio de origen las fuentes de los paquetes.

  • Una combinación de fuentes válida: en todas las combinaciones siguientes, el conjunto de fuentes efectivo es la unión de las direcciones IPv4 o IPv6 que se especifican explícitamente y los intervalos de direcciones IP que implican la etiqueta de red de origen o la cuenta de servicio de origen:

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

Cómo implican las etiquetas de red de origen y las cuentas de servicio de origen las fuentes de paquetes

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

  • La interfaz de red debe estar en la red de VPC en la que se define la regla de cortafuegos.
  • La interfaz de red debe estar asociada a una máquina virtual que tenga una etiqueta de red que coincida con al menos una de las etiquetas de red de origen de la regla de firewall.

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

  • La interfaz de red debe estar en la red de VPC en la que se define la regla de cortafuegos.
  • La interfaz de red debe estar asociada a una VM que tenga una cuenta de servicio que coincida con una de las cuentas de servicio de origen de la regla de cortafuegos.

Además de especificar una interfaz de red, cuando una regla de cortafuegos 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 cortafuegos de entrada también contiene intervalos 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 intervalo de IP de destino.

No se implican otras direcciones IP de origen de paquetes cuando se usan etiquetas de red de origen o cuentas de servicio de origen. Por ejemplo, se excluyen los intervalos de IPs de alias y la dirección IPv4 externa asociada a la interfaz de red. Si necesitas crear reglas de cortafuegos de entrada cuyas fuentes incluyan intervalos de direcciones IP de alias o direcciones IPv4 externas, usa intervalos de IPv4 de origen.

Fuentes de las reglas de salida

Puedes usar las siguientes fuentes para las reglas de cortafuegos de salida:

  • Predeterminado: implícito en el destino. Si omite el parámetro de origen de una regla de salida, los orígenes de los paquetes se definen implícitamente, tal como se describe en Destinos y direcciones IP de las reglas de salida.

  • Intervalos de IPv4 de origen. Lista de direcciones IPv4 en formato CIDR.

  • Intervalos de IPv6 de origen. Lista de direcciones IPv6 en formato CIDR.

Sigue estas directrices para añadir intervalos de direcciones IP de origen a las reglas de salida:

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

  • Si especifica parámetros de origen y de destino en una regla de salida, utilice la misma versión de IP para ambos parámetros. Puedes usar un intervalo de direcciones IPv4 o un intervalo de direcciones IPv6, pero no ambos. Para obtener más información, consulta Destinos de las reglas de salida.

Parámetro de destino

Los destinos se pueden especificar mediante intervalos de direcciones IP, que admiten tanto las reglas de entrada como las de salida. El comportamiento predeterminado del destino depende de la dirección de la regla.

Destinos de las reglas de entrada

Puede usar los siguientes destinos para las reglas de cortafuegos de entrada:

  • Predeterminado: implícito en el destino. Si omite el parámetro de destino de una regla de entrada, los destinos de los paquetes se definen implícitamente, tal como se describe en Destinos y direcciones IP de las reglas de entrada.

  • Intervalos de IPv4 de destino. Lista de direcciones IPv4 en formato CIDR.

  • Intervalos de IPv6 de destino. Lista de direcciones IPv6 en formato CIDR.

Sigue estas directrices para añadir intervalos de direcciones IP de destino a las reglas de entrada:

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

  • Si especifica 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 intervalo de direcciones IP de destino. Para obtener más información sobre cómo definir fuentes para las reglas de entrada, consulta Fuentes para las reglas de entrada.

Destinos de las reglas de salida

Puede usar los siguientes destinos para las reglas de cortafuegos de salida:

  • Intervalo de destino predeterminado. Si omite una especificación de destino en una regla de salida, Google Cloud se usará el intervalo de direcciones IPv4 de destino predeterminado0.0.0.0/0 (cualquier dirección IPv4). El valor predeterminado no incluye destinos IPv6.

  • Intervalos de IPv4 de destino. Lista de direcciones IPv4 en formato CIDR.

  • Intervalos de IPv6 de destino. Lista de direcciones IPv6 en formato CIDR.

Filtrado de origen y destino por cuenta de servicio

Puedes usar cuentas de servicio para crear reglas de firewall más específicas:

  • Tanto en las reglas de entrada como en las de salida, puedes usar cuentas de servicio para especificar destinos.

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

La cuenta de servicio debe crearse en el mismo proyecto que la regla de cortafuegos antes de crear una regla de cortafuegos que dependa de ella. Aunque el sistema no te impide crear una regla que use una cuenta de servicio de otro proyecto, la regla no se aplica si la cuenta de servicio no existe en el proyecto de la regla de cortafuegos.

Las reglas de cortafuegos que usan cuentas de servicio para identificar instancias se aplican tanto a las instancias nuevas creadas y asociadas a la cuenta de servicio como a las instancias que ya existen si cambias sus cuentas de servicio. Para cambiar la cuenta de servicio asociada a una instancia, debes detenerla y reiniciarla. Puedes asociar cuentas de servicio a instancias individuales y a plantillas de instancias que usen grupos de instancias gestionados.

Filtrar por cuenta de servicio o etiqueta de red

En esta sección se destacan los puntos clave que debes tener en cuenta a la hora de decidir si debes usar cuentas de servicio o etiquetas de red para definir destinos y fuentes (en el caso de las reglas de entrada).

Si necesitas controlar estrictamente cómo se aplican las reglas de firewall a las VMs, usa cuentas de servicio de destino y cuentas de servicio de origen en lugar de etiquetas de red de destino y etiquetas de red de origen:

  • Una etiqueta de red es un atributo arbitrario. Cualquier principal de gestión de identidades y accesos que tenga permiso para editar una instancia puede asociar una o varias etiquetas de red a dicha instancia. Las entidades de gestión de identidades y accesos con el rol Administrador de instancias de Compute Engine en un proyecto tienen este permiso. Las entidades de IAM que pueden editar una instancia pueden cambiar sus etiquetas de red, lo que podría cambiar el conjunto de reglas de cortafuegos aplicables a esa instancia.

  • Una cuenta de servicio representa una identidad asociada a una instancia. Solo se puede asociar una cuenta de servicio a una instancia. Puedes controlar el acceso a la cuenta de servicio controlando la concesión del rol Usuario de cuenta de servicio a otras entidades principales de gestión de identidades y accesos. Para que un principal de IAM inicie una instancia mediante una cuenta de servicio, debe tener el rol Usuario de cuenta de servicio para usar al menos esa cuenta de servicio y los permisos adecuados para crear instancias (por ejemplo, tener el rol Administrador de instancias de Compute Engine en el proyecto).

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

  • No puedes usar cuentas de servicio de destino y etiquetas de red de destino juntas en ninguna regla de cortafuegos (de entrada o de salida).

  • Si especificas destinos por etiqueta de red de destino o cuenta de servicio de destino, los siguientes orígenes no serán válidos para las reglas de cortafuegos de entrada.

    Destinos Fuentes no válidas
    Etiquetas de red de destino Cuentas de servicio de origen

    Combinación de intervalos de IPs de origen y cuentas de servicio de origen
    Cuenta de servicio de destino Etiquetas de red de origen

    Combinación de intervalos de IP de origen y etiquetas de red de origen

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

  • Para cambiar la cuenta de servicio de una instancia, es necesario detenerla y reiniciarla. Las etiquetas de red se pueden añadir o quitar mientras la instancia está en ejecución.

  • Hay un número máximo de cuentas de servicio de destino, cuentas de servicio de origen, etiquetas de red de destino y etiquetas de red de origen que se pueden especificar en las reglas de cortafuegos. Para obtener más información, consulta los límites por regla de cortafuegos.

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

  • Las reglas de cortafuegos de cuentas de servicio se aplican al nodo de GKE, no al pod de GKE.

Roles y permisos

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

Tarea Permiso obligatorio Rol de ejemplo
Crear una regla de cortafuegos compute.firewalls.create Administrador de seguridad de Compute
(roles/compute.securityAdmin)
Eliminar una regla de cortafuegos compute.firewalls.delete Administrador de seguridad de Compute
(roles/compute.securityAdmin)
Cambiar las reglas de cortafuegos compute.firewalls.update Administrador de seguridad de Compute
(roles/compute.securityAdmin)
Ver los detalles de una regla de cortafuegos compute.firewalls.get Lector de red de Compute
(roles/compute.networkViewer)
Ver una lista de reglas de cortafuegos compute.firewalls.list Lector de red de Compute
(roles/compute.networkViewer)

Casos prácticos

En los siguientes casos prácticos se muestra cómo funcionan las reglas de cortafuegos. En estos ejemplos, todas las reglas de cortafuegos están habilitadas.

Casos de Ingress

Las reglas de cortafuegos de entrada controlan las conexiones entrantes de un origen a las instancias de destino de tu red de VPC. La fuente de una regla de entrada puede definirse de una de las siguientes formas:

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

La fuente predeterminada es cualquier dirección IPv4 (0.0.0.0/0). Si quieres controlar las conexiones entrantes de fuentes que no estén en tu red de VPC, incluidas otras fuentes de Internet, usa un intervalo de direcciones IP en formato CIDR.

Las reglas de entrada con una acción allow permiten el tráfico entrante en función de los otros componentes de la regla. Además de especificar el origen y el destino de la regla, puede limitar la regla para 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 las instancias bloqueando el tráfico entrante en función de los componentes de la regla de cortafuegos.

Ejemplos de Ingress

En la figura 1 se muestran algunos ejemplos de cómo las reglas de cortafuegos pueden controlar las conexiones entrantes. En los ejemplos se usa el parámetro target en las asignaciones de reglas para aplicar reglas a instancias específicas.

En esta red de VPC de ejemplo, las reglas de cortafuegos de entrada permiten anular la regla de denegación de entrada implícita de algunas VMs.
Imagen 1. En esta red de VPC, las reglas de cortafuegos de entrada permitida anulan la regla de entrada denegada implícita de algunas VMs (haz clic para ampliar la imagen).

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

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

  • Una regla de entrada con prioridad 1000 se aplica a la VM 3. Esta regla permite el tráfico TCP de las instancias de la red con la etiqueta de red client, como VM 4. Se permite el tráfico TCP de VM 4 a VM 3 porque VM 4 no tiene ninguna regla de salida que bloquee dicha comunicación (solo se aplica la regla de salida implícita). Como VM 3 no tiene una IP externa, no hay ninguna ruta a ella desde los hosts externos de Internet.

Casos de salida

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

Cada 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 usando un intervalo de direcciones IPv4 o IPv6 en formato CIDR. Al especificar un intervalo de direcciones IP, puedes controlar el tráfico a las instancias de tu red y a los destinos que se encuentran fuera de ella, incluidos los destinos de Internet.

Ejemplos de salida

En la figura 2 se muestran algunos ejemplos de cómo las reglas de cortafuegos pueden controlar las conexiones de salida. En los ejemplos se usa el parámetro target en las asignaciones de reglas para aplicar reglas a instancias específicas.

En esta red de VPC de ejemplo, las reglas de cortafuegos de salida denegada anulan la regla de salida permitida implícita de algunas VMs.
Imagen 2. En esta red de VPC, las reglas de cortafuegos de denegación de salida anulan la regla de salida implícita de algunas VMs (haz clic para ampliar).

  • La VM 1 no tiene ninguna regla de cortafuegos de salida especificada, por lo que la regla de salida implícita le permite enviar tráfico a cualquier destino. Se permiten las conexiones a otras instancias de la red de VPC, de acuerdo con las reglas de entrada aplicables a esas otras instancias. La VM 1 puede enviar tráfico a la VM 4 porque esta última tiene una regla de entrada que permite el tráfico entrante de cualquier intervalo de direcciones IP. Como VM 1 tiene una dirección IP externa, puede enviar tráfico a hosts externos en Internet. Se permiten las respuestas entrantes al tráfico enviado por VM 1 porque las reglas de cortafuegos tienen estado.

  • Una regla de salida con prioridad 1000 se aplica a VM 2. Esta regla deniega todo el tráfico saliente a todos los destinos IPv4 (0.0.0.0/0). El tráfico saliente a otras instancias de la red VPC se bloquea, independientemente de las reglas de entrada aplicadas a las otras instancias. Aunque VM 2 tiene una dirección IP externa, esta regla de cortafuegos bloquea su tráfico saliente a hosts externos en Internet.

  • Una regla de salida con prioridad 1000 se aplica a VM 3. Esta regla bloquea el tráfico TCP saliente a cualquier destino del intervalo de IPs 192.168.1.0/24. Aunque las reglas de entrada de VM 4 permiten todo el tráfico entrante, VM 3 no puede enviar tráfico TCP a VM 4. Sin embargo, VM 3 puede enviar tráfico UDP a 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 de la red VPC que no estén en el intervalo de IPs 192.168.1.0/24, siempre que esas otras instancias tengan reglas de entrada que permitan dicho tráfico. Como no tiene una dirección IP externa, no tiene ninguna ruta para enviar tráfico fuera de la red de VPC.

Siguientes pasos

Pruébalo

Si es la primera vez que utilizas Google Cloud, crea una cuenta para evaluar el rendimiento de Cloud NGFW en situaciones reales. Los nuevos clientes también reciben 300 USD en crédito gratuito para ejecutar, probar y desplegar cargas de trabajo.

Probar Cloud NGFW gratis