Reglas de firewall
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Google Cloud Los balanceadores de cargas suelen requerir una o más reglas de firewall para garantizar que el tráfico de los clientes llegue a los backends.
Se requiere la mayoría de los balanceadores de cargas a fin de especificar una verificación de estado para las instancias de backend. Para que los sondeos de verificación de estado lleguen a tus backends, debes crear una regla de firewall de permiso de entrada que permita que los sondeos lleguen a tus instancias de backend.
Los balanceadores de cargas basados en Google Front Ends (GFEs) requieren una regla de firewall de permiso de entrada que permita que el tráfico del proxy de GFE llegue a las instancias de backend. En la mayoría de los casos, los proxies de GFE usan los mismos rangos de IP de origen que los sondeos de verificación de estado y, por lo tanto, no requieren una regla de firewall independiente.
Las excepciones se indican en la siguiente tabla.
Los balanceadores de cargas regionales basados en el proxy Envoy de código abierto requieren una regla de firewall de permiso de entrada que permita que el tráfico de la subred de solo proxy llegue a las instancias de backend. Estos balanceadores de cargas finalizan las conexiones entrantes y el tráfico del balanceador de cargas a los backends se envía desde las direcciones IP en la subred de solo proxy.
En la siguiente tabla, se resumen las reglas de firewall mínimas requeridas para cada tipo de balanceador de cargas.
Tipo de balanceador de cargas
Reglas de firewall de entrada mínimas requeridas
Resumen
Ejemplo
Balanceador de cargas de aplicaciones externo global
Rangos de verificación de estado:
Para el tráfico IPv4 a los backends:
35.191.0.0/16
130.211.0.0/22
Para el tráfico IPv6 a los backends:
2600:2d00:1:1::/64
2600:2d00:1:b029::/64
Rangos de proxy de GFE:
Igual que los rangos de verificación de estado si los backends son grupos de instancias, NEGs zonales (GCE_VM_IP_PORT) o NEGs de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT)
Los rangos de direcciones IP que aparecen en el registro TXT de DNS de _cloud-eoips.googleusercontent.com. Puedes extraer las direcciones IP de origen para los backends de NEG de Internet globales con el siguiente comando de ejemplo en un sistema Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Igual que los rangos de verificación de estado si los backends son grupos de instancias, NEG zonales (GCE_VM_IP_PORT) o NEG de conectividad híbrida (NON_GCP_PRIVATE_IP_PORT)
Los rangos de direcciones IP que aparecen en el registro TXT de DNS de _cloud-eoips.googleusercontent.com. Puedes extraer las direcciones IP de origen para los backends de NEG de Internet globales con el siguiente comando de ejemplo en un sistema Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Balanceador de cargas de red de transferencia externo regional
Rangos de verificación de estado:
Para el tráfico IPv4 a los backends:
35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Para el tráfico IPv6 a los backends:
2600:1901:8001::/48
Direcciones IP de origen externas de clientes en Internet. Por ejemplo, 0.0.0.0/0 (todos los clientes IPv4) o ::/0 (todos los clientes IPv6) o un conjunto específico de rangos de direcciones IP.
Los balanceadores de cargas basados en grupos de destino pueden realizar verificaciones de estado con proxy a través del servidor de metadatos. En este caso, las fuentes de sondeos de verificación de estado coinciden con la dirección IP del servidor de metadatos: 169.254.169.254. Sin embargo, el tráfico del servidor de metadatos siempre puede llegar a las VMs. No se requiere ninguna regla de firewall.
1
No se requiere permitir el tráfico de los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes permitir el tráfico de los rangos de sondeo de verificación de estado de Google para los NEG zonales.
2 Para los NEGs de Internet regionales, las verificaciones de estado son opcionales. El tráfico de los balanceadores de cargas que usan NEGs de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (mediante Cloud NAT) a cualquiera de las direcciones IP de NAT asignadas manual o automáticamente. Este tráfico incluye sondeos de verificación de estado y solicitudes de usuario del balanceador de cargas a los backends. Para obtener más detalles, consulta NEG regionales: Usa una puerta de enlace de Cloud NAT.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2026-04-18 (UTC)"],[],[]]
