Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os balanceadores de carga do Google Cloud normalmente exigem uma ou mais regras de firewall
para garantir que o tráfego dos clientes chegue aos back-ends.
A maioria dos balanceadores de carga é necessária para especificar uma verificação de integridade para instâncias de back-end. Para que as sondagens de verificação de integridade alcancem seus back-ends, crie
uma regra de firewall de permissão de entrada que permita
que sondagens de verificação de integridade alcancem suas instâncias de back-end.
Os balanceadores de carga baseados em Google Front Ends (GFEs) exigem uma regra de firewall de permissão
de entrada que permita que o tráfego do proxy do GFE alcance as instâncias de
back-end. Na maioria dos casos, os proxies do GFE usam os mesmos intervalos de IP de origem que as sondagens da verificação de integridade. Portanto, não exigem uma regra de firewall separada.
Confira as exceções na tabela a seguir.
Os balanceadores de carga com base no proxy de código aberto Envoy
exigem uma regra de firewall de permissão de entrada que permita que o tráfego da sub-rede
somente proxy alcance as instâncias de back-end. Esses balanceadores de carga encerram as conexões de entrada e o tráfego do balanceador de carga para os back-ends é enviado dos endereços IP na sub-rede somente proxy.
Na tabela a seguir, há um resumo das regras de firewall mínimas necessárias para cada
tipo de balanceador de carga.
Tipo de balanceador de carga
Regras de firewall de permissão de entrada mínima obrigatória
Visão geral
Exemplo
Balanceador de carga de aplicativo externo global
Intervalos de verificação de integridade
35.191.0.0/16
130.211.0.0/22
Para tráfego IPv6 para os back-ends:
2600:2d00:1:b029::/64
2600:2d00:1:1::/64
Intervalos de proxy GFE:
Os mesmos intervalos de verificação de integridade se os back-ends forem grupos
de instâncias, NEGs zonais
(GCE_VM_IP_PORT) ou NEGs híbridos de conectividade
(NON_GCP_PRIVATE_IP_PORT).
Intervalos de endereços IP listados no registro TXT do DNS _cloud-eoips.googleusercontent.com. É possível extrair os endereços IP de origem para back-ends
de NEG de Internet globais usando o seguinte comando de exemplo em um
sistema Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Os mesmos intervalos de verificação de integridade se os back-ends forem grupos
de instâncias, NEGs zonais
(GCE_VM_IP_PORT) ou NEGs híbridos de conectividade
(NON_GCP_PRIVATE_IP_PORT).
Intervalos de endereços IP listados no registro TXT do DNS _cloud-eoips.googleusercontent.com. É possível extrair os endereços IP de origem para back-ends
de NEG de Internet globais usando o seguinte comando de exemplo em um
sistema Linux:
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
Endereços IP de origem externos de clientes na Internet.
Por exemplo, 0.0.0.0/0 (todos os clientes IPv4) ou
::/0 (todos os clientes IPv6) ou um
conjunto específico de intervalos de endereços IP.
Os balanceadores de carga baseados em pool de destino podem fazer proxy das verificações de integridade por meio do servidor de metadados. Nesse caso, as origens da sondagem de verificação de integridade correspondem ao endereço IP
do servidor de metadados: 169.254.169.254. No entanto, o tráfego do servidor de metadados sempre pode acessar as VMs. Nenhuma regra de firewall é necessária.
1
Não é necessário colocar intervalos de sondagem de verificação de integridade do Google na lista de permissões para
NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário usar lista de permissões dos intervalos de sondagem de verificação de integridade do Google para NEGs zonais.
2
Para NEGs regionais da Internet, as verificações de integridade são opcionais. O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT alocados automaticamente ou manualmente. Esse tráfego inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends. Para detalhes, consulte NEGs regionais: usar o Cloud NAT para sair.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
