Balanceamento de carga TCP/UDP interno e redes conectadas

Nesta página, você verá cenários para acessar um balanceador de carga interno na sua rede de nuvem privada virtual (VPC, na sigla em inglês) usando uma rede conectada. Antes de analisar as informações desta página, você precisa estar familiarizado com os conceitos do guia a seguir:

Como usar peering de rede VPC

Quando você usa o peering de rede VPC para conectar sua rede VPC a outra rede, o Google Cloud compartilha rotas de sub-rede entre as redes. As rotas de sub-rede permitem que o tráfego da rede de peering alcance os balanceadores de carga internos na sua rede. O acesso é permitido se as afirmações abaixo forem verdadeiras:

  • Para balanceadores de carga TCP/UDP internos, você precisa criar regras de firewall de entrada para permitir o tráfego de VMs cliente na rede com peering. As regras de firewall do Google Cloud não são compartilhadas entre redes ao usar o peering de rede VPC.
  • As instâncias de máquina virtual (VM) do cliente na rede com peering estão localizadas na mesma região do balanceador de carga interno. Somente para balanceadores de carga TCP/UDP internos, essa restrição será desconsiderada se você configurar o acesso global.

Não é possível compartilhar apenas alguns balanceadores de carga TCP/UDP ou HTTP(S) internos usando peering de rede VPC. Todos os balanceadores de carga internos são compartilhados automaticamente. Você pode limitar o acesso aos back-ends do balanceador de carga das seguintes maneiras:

  • Para balanceadores de carga TCP/UDP internos, é possível usar regras de firewall de entrada aplicáveis a instâncias de VM de back-end.

  • Para balanceadores de carga HTTP(S) internos, é possível configurar as VMs ou os endpoints de back-end para controlar o acesso usando cabeçalhos HTTP. Por exemplo, X-Forwarded-For.

Como usar o Cloud VPN e o Cloud Interconnect

É possível acessar um balanceador de carga interno usando uma rede de peering conectada por um túnel do Cloud VPN ou por um anexo da VLAN para uma conexão de Interconexão dedicada ou Interconexão por parceiro. A rede de peering pode ser uma rede local, outra rede VPC do Google Cloud ou uma rede virtual hospedada por um provedor de nuvem diferente.

Acesso por meio de túneis do Cloud VPN

É possível acessar um balanceador de carga interno por meio de um túnel do Cloud VPN quando todas as condições a seguir forem atendidas.

Na rede do balanceador de carga interno

  • O gateway e os túneis do Cloud VPN precisam estar localizados na mesma região do balanceador de carga quando o acesso global estiver desativado. Se o acesso global estiver ativado na regra de encaminhamento do balanceador de carga, essa restrição será dispensada.

  • As rotas precisam fornecer caminhos de resposta dos back-ends do balanceador de carga para a rede local ou peering em que o cliente está localizado. Se você estiver usando os túneis do Cloud VPN com roteamento dinâmico, considere o modo de roteamento dinâmico da rede do Cloud VPN do balanceador de carga. O modo de roteamento dinâmico determina quais rotas dinâmicas personalizadas estão disponíveis para os back-ends do balanceador de carga.

  • Configure regras de firewall de permissão de entrada com intervalos de endereços IP de origem locais para que os clientes locais possam enviar pacotes para o balanceador de carga. Os destinos dessas regras de firewall precisam incluir os back-ends do balanceador de carga. Consulte Destinos e endereços IP para detalhes.

Na rede de peering

A rede de peering precisa ter pelo menos um túnel do Cloud VPN com rotas para a sub-rede em que o balanceador de carga interno está definido.

Se a rede de peering for outra rede VPC do Google Cloud:

  • O gateway e os túneis do Cloud VPN da rede de peering podem estar localizados em qualquer região.

  • Em túneis do Cloud VPN que usam roteamento dinâmico, o modo de roteamento dinâmico da rede VPC determina quais rotas estão disponíveis para os clientes de cada região. Para fornecer um conjunto consistente de rotas dinâmicas personalizadas para os clientes de todas as regiões, use o modo de roteamento dinâmico global.

  • Verifique se os firewalls de rede local ou de peering permitem pacotes enviados ao endereço IP da regra de encaminhamento do balanceador de carga. Verifique se os firewalls de rede locais ou de peering permitem pacotes de resposta recebidos do endereço IP da regra de encaminhamento do balanceador de carga.

O diagrama a seguir destaca os principais conceitos ao acessar um balanceador de carga interno por meio de um gateway do Cloud VPN e seu túnel associado. O Cloud VPN conecta sua rede local com segurança à rede VPC do Google Cloud usando túneis do Cloud VPN.

Balanceamento de carga TCP/UDP interno e Cloud VPN (clique para ampliar)
Balanceamento de carga interno e Cloud VPN (clique para ampliar)

Observe os seguintes elementos de configuração associados a este exemplo:

  • Na lb-network, foi configurado um túnel do Cloud VPN que usa roteamento dinâmico. O túnel VPN, o gateway e o Cloud Router estão localizados em us-west1, a mesma região dos componentes do balanceador de carga interno.
  • As regras de firewall de entrada permitidas foram configuradas para serem aplicadas às VMs de back-end nos grupos de instâncias ig-a e ig-c para que eles possam receber tráfego de endereços IP na rede VPC e da rede local, 10.1.2.0/24 e 192.168.1.0/24. Nenhuma regra de firewall de negação de saída foi criada. Portanto, a regra de saída de permissão implícita se aplica.
  • Pacotes enviados de clientes nas redes locais, inclusive de 192.168.1.0/24, para o endereço IP do balanceador de carga interno, 10.1.2.99, são entregues diretamente a uma VM de back-end íntegra, como vm-a2, de acordo com a afinidade de sessão configurada.
  • As respostas enviadas das VMs de back-end, como vm-a2, são entregues por meio do túnel VPN aos clientes locais.

Veja como resolver problemas do Cloud VPN em Solução de problemas do Cloud VPN.

Acessar pelo Cloud Interconnect

É possível acessar um balanceador de carga interno de uma rede de peering local conectada à rede VPC do balanceador de carga quando todas as condições a seguir forem atendidas na rede do balanceador de carga interno:

  • O anexo do Cloud Interconnect (VLAN) e o Cloud Router precisam estar localizados na mesma região que o balanceador de carga quando o acesso global estiver desativado. Se o acesso global estiver ativado na regra de encaminhamento do balanceador de carga, essa restrição será dispensada.

  • Os roteadores locais precisam fornecer caminhos de resposta dos back-ends do balanceador de carga para a rede local. Os anexos de interconexão (VLANs) para a Interconexão dedicada e a Interconexão por parceiro precisam usar os Cloud Routers. Assim, as rotas dinâmicas personalizadas fornecem caminhos de resposta. O conjunto de rotas dinâmicas personalizadas que eles aprendem depende do modo de roteamento dinâmico da rede do balanceador de carga.

  • Configure regras de firewall de permissão de entrada com intervalos de endereços IP de origem locais para que os clientes locais possam enviar pacotes para o balanceador de carga. Os destinos dessas regras de firewall precisam ser os back-ends do balanceador de carga. Consulte Destinos e endereços IP para detalhes.

  • Verifique se os firewalls locais permitem pacotes enviados para o endereço IP da regra de encaminhamento do balanceador de carga. Verifique se os firewalls locais permitem pacotes de resposta recebidos do endereço IP da regra de encaminhamento do balanceador de carga.

Acesso global para balanceamento de carga TCP/UDP interno

Quando você configura o acesso global para o balanceamento de carga TCP/UDP interno, os recursos a seguir podem ser localizados em qualquer região:

  • Cloud Routers
  • Gateways e túneis do Cloud VPN
  • Anexos do Cloud Interconnect (VLANs)

No diagrama:

  • O Cloud Router está na região europe-west1.
  • O front-end e os back-ends do balanceador de carga TCP/UDP interno estão na região us-east1.
  • O Cloud Router usa peering com o roteador VPN local.
  • A sessão de peering do protocolo do gateway de borda (BGP) pode ser feita por meio do Cloud VPN ou do Cloud Interconnect com o peering direto ou com a Interconexão por parceiro.
Balanceamento de carga TCP/UDP interno com acesso global (clique para ampliar)
Balanceamento de carga TCP/UDP interno com acesso global (clique para ampliar)

O modo de roteamento dinâmico da rede VPC está definido como global para ativar o Cloud Router em europe-west1 e divulgar as rotas de sub-redes em qualquer região da rede VPC do balanceador de carga TCP/UDP interno.

Vários caminhos de saída

Em ambientes de produção, você precisa usar vários túneis do Cloud VPN ou anexos do Cloud Interconnect (VLANs) para redundância. Esta seção discute os requisitos ao usar vários túneis ou VLANs.

No diagrama a seguir, dois túneis do Cloud VPN conectam lb-network a uma rede local. Embora aqui sejam usados túneis do Cloud VPN, os mesmos princípios se aplicam ao Cloud Interconnect.

Balanceamento de carga TCP/UDP interno e vários túneis do Cloud VPN (clique para
       ampliar)
Balanceamento de carga interno e vários túneis do Cloud VPN (clique para ampliar)

É necessário configurar cada túnel ou cada anexo do Cloud Interconnect (VLAN) na mesma região do balanceador de carga interno. Esse requisito será desconsiderado para o balanceamento de carga TCP/UDP interno se você tiver ativado o acesso global.

Vários túneis ou VLANs podem fornecer largura de banda extra ou ser usados como caminhos em espera para redundância.

Tenha em mente os seguintes pontos:

  • Se a rede local tiver duas rotas com as mesmas prioridades, cada uma com um destino de 10.1.2.0/24 e um próximo salto correspondente a um túnel VPN diferente na mesma região do balanceador de carga interno, o tráfego poderá ser enviado da rede local (192.168.1.0/24) para o balanceador de carga usando vários caminhos de custo igual (ECMP, na sigla em inglês).
  • Depois que os pacotes são entregues à rede VPC, o balanceador de carga interno os distribui para as VMs de back-end de acordo com a afinidade de sessão configurada.
  • Se lb-network tiver duas rotas, cada uma com o destino 192.168.1.0/24 e um próximo salto correspondente a diferentes túneis VPN, as respostas das VMs de back-end poderão ser entregues em cada túnel de acordo com a prioridade das rotas na rede. Se diferentes prioridades de rota forem usadas, um túnel poderá servir como um backup para o outro. Se as mesmas prioridades forem usadas, as respostas serão entregues usando ECMP.
  • As respostas enviadas das VMs de back-end, como vm-a2, são entregues diretamente aos clientes locais por meio do túnel apropriado. Da perspectiva de lb-network, se as rotas ou os túneis VPN forem alterados, o tráfego poderá sair usando um túnel diferente. Isso pode resultar em redefinições de sessão TCP se uma conexão em andamento for interrompida.

A seguir