Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Por lo general, los balanceadores de cargas de Google Cloud requieren 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 los 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 (GFE) 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:
35.191.0.0/16
130.211.0.0/22
Para el tráfico IPv6 a los backends:
2600:2d00:1:b029::/64
2600:2d00:1:1::/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 mediante 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 mediante 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
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 una regla de firewall.
1
No se requiere incluir en la lista de entidades permitidas 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 incluir en la lista de entidades permitidas 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 los manuales o direcciones IP de NAT asignadas 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 Cloud NAT para la salida.
[[["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: 2024-12-22 (UTC)"],[],[],null,["# Firewall rules\n\nGoogle Cloud load balancers typically require one or more firewall rules\nto ensure that traffic from clients reaches the backends.\n\n- Most load balancers are required to specify a health check for backend\n instances. For the health check probes to reach your backends, you must create\n an ingress allow [firewall rule](/firewall/docs/using-firewalls) that allows\n health check probes to reach your backend instances.\n\n- Load balancers based on Google Front Ends (GFEs) require an ingress allow\n firewall rule that permits traffic from the GFE proxy to reach the backend\n instances. In most cases, GFE proxies use the same source IP ranges as the\n health check probes and therefore don't require a separate firewall rule.\n Exceptions are noted in the following table.\n\n- Load balancers based on the open source Envoy proxy require an ingress allow\n firewall rule that permits traffic from the *proxy-only subnet* to reach the\n backend instances. These load balancers terminate incoming connections and\n traffic from the load balancer to the backends is then sent from IP addresses\n in the proxy-only subnet.\n\nThe following table summarizes the minimum required firewall rules for each\ntype of load balancer.\n\n^1^\nAllowing traffic from Google's health check probe ranges isn't required for hybrid\nNEGs. However, if you're using a combination of hybrid and zonal NEGs in\na single backend service, you need to allow traffic from the [Google\nhealth check probe ranges](/load-balancing/docs/health-check-concepts#ip-ranges) for the zonal NEGs.\n\n^2^\nFor regional internet NEGs, health checks are optional. Traffic from load\nbalancers using *regional* internet NEGs originates from the [proxy-only subnet](/load-balancing/docs/proxy-only-subnets) and is then\nNAT-translated (by using Cloud NAT) to either manually or automatically allocated\nNAT IP addresses. This traffic includes both health check probes and user\nrequests from the load balancer to the backends. For details, see [Regional NEGs:\nUse a Cloud NAT gateway](/load-balancing/docs/negs/internet-neg-concepts#nat-support)."]]
