Google Cloud Los balanceadores de carga suelen requerir una o varias reglas de cortafuegos para asegurarse de que el tráfico de los clientes llegue a los back-ends.
La mayoría de los balanceadores de carga deben especificar una comprobación del estado de las instancias de backend. Para que las comprobaciones del estado lleguen a tus backends, debes crear una regla de cortafuegos de entrada que permita que las comprobaciones del estado lleguen a tus instancias de backend.
Los balanceadores de carga basados en Google Front Ends (GFEs) requieren una regla de cortafuegos 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 intervalos de IPs de origen que las sondas de comprobación de estado, por lo que no requieren una regla de firewall independiente. Las excepciones se indican en la siguiente tabla.
Los balanceadores de carga basados en el proxy Envoy de código abierto requieren una regla de cortafuegos que permita que el tráfico de entrada de la subred de solo proxy llegue a las instancias de backend. Estos balanceadores de carga finalizan las conexiones entrantes y el tráfico del balanceador de carga a los backends se envía desde direcciones IP de la subred de solo proxy.
En la siguiente tabla se resumen las reglas de cortafuegos mínimas necesarias para cada tipo de balanceador de carga.
| Tipo de balanceador de carga | Reglas de cortafuegos de entrada mínimas necesarias | Información general | Ejemplo |
|---|---|---|---|
| Balanceador de carga de aplicación externo global |
|
Descripción general | Ejemplo |
| Balanceador de carga de aplicación clásico |
|
Descripción general | Ejemplo |
| Balanceador de carga de aplicación externo regional |
|
Descripción general | Ejemplo |
| Balanceador de carga de aplicación interno entre regiones |
|
Descripción general | Ejemplo |
| Balanceador de carga de aplicación interno regional |
|
Descripción general | Ejemplo |
| Balanceador de carga de red con proxy externo global |
|
Descripción general | Ejemplo |
| Balanceador de carga de red de proxy clásico |
|
Descripción general | Ejemplo |
| Balanceador de carga de red con proxy externo regional |
|
Descripción general | Ejemplo |
| Balanceador de carga de red con proxy interno regional |
|
Descripción general | Ejemplo |
| Balanceador de carga de red con proxy interno interregional |
|
Descripción general | Ejemplo |
| Balanceador de carga de red de paso a través externo |
|
Descripción general |
Ejemplos |
| Balanceador de carga de red de paso a través interno |
|
Descripción general | Pila única Pila dual |
1 No es necesario permitir el tráfico de los intervalos de comprobación del estado de Google para los NEG híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.
2 En el caso de los NEGs de Internet regionales, las comprobaciones del estado son opcionales. El tráfico de los balanceadores de carga que usan NEGs de Internet regionales procede de la subred solo de proxy y, a continuación, se traduce mediante NAT (con Cloud NAT) a direcciones IP de NAT asignadas de forma manual o automática. Este tráfico incluye tanto las comprobaciones del estado como las solicitudes de los usuarios del balanceador de carga a los backends. Para obtener más información, consulta NEGs regionales: usar una pasarela de Cloud NAT.