GCP Cloud VPN: verifique gateway, túnel e firewall na ordem certa

O console mostra um túnel verde, o monitoramento local continua sem alcançar uma única instância, e reconstruir o túnel parece a solução óbvia. Raramente é. Um túnel estabelecido prova apenas que dois gateways concluíram a troca IKE. Ele não diz nada sobre se um pacote chegou a ser permitido na sua VPC.

Quatro decisões separam esse ícone verde de uma resposta, e elas falham numa ordem previsível. Comece pela mais barata.

Três objetos, e apenas um deles cifra

Um gateway VPN possui o endereço externo para o qual o seu par cifra. No console você nunca o cria à mão: escolha ou reserve um endereço dentro do formulário de conexão e o gateway aparece com ele. Um gateway HA ocupa dois endereços em duas interfaces, o que conta na verificação de cotas mais adiante.

Um túnel é o emparelhamento entre esse gateway e o par. Ele transporta o segredo compartilhado e os seletores de tráfego que promete proteger. É nesses seletores que começam a maioria das falhas silenciosas. Um túnel cujo seletor local cobre 10.0.0.0/24 não entregará 10.0.1.0/24, por mais saudável que o status pareça.

O lado remoto mantém a própria lista, normalmente chamada de domínio de criptografia, e o hardware de terminação a compara com a sua. Nenhum lado negocia um seletor que nunca lhe foi dado.

O tipo de roteamento decide o que chega à tabela de rotas

O Cloud VPN oferece três formas de roteamento e elas não se misturam de forma limpa. O roteamento baseado em políticas mantém os pares de seletores estáticos, o roteamento baseado em rotas espera que você mesmo adicione rotas estáticas, e o roteamento dinâmico anuncia prefixos por meio de um Cloud Router sobre BGP. Escolha uma de propósito.

Um túnel dinâmico com rotas estáticas escritas à mão ao lado produz uma tabela de rotas que se esvazia sempre que a sessão BGP oscila.

O dinâmico é a única forma que permite que os prefixos protegidos mudem sem reconstruir o túnel, e arrasta o Cloud Router para o conjunto de objetos que você precisa verificar. Seletores estáticos continuam viáveis quando o par é um firewall de hardware que não sabe falar BGP. Então as duas pontas precisam dos mesmos intervalos, e a entrada mais específica tem de vencer nos dois lados. Um par que discorda em uma sub-rede estabelece e depois carrega metade do seu tráfego.

A negação implícita fica atrás do túnel

O tráfego de entrada é avaliado contra uma negação implícita na prioridade mais baixa, e essa regra não se importa que o pacote tenha chegado cifrado. Até que uma regra de firewall nomeie o intervalo local e a porta em uso, o pacote é decifrado, inspecionado e descartado. O log da VPN permanece limpo o tempo todo, porque o túnel fez exatamente o que prometeu.

Leia em vez disso o log de negações do firewall quando o túnel estiver ativo e o teste expirar, e então limite uma regra ao intervalo de origem e às portas de que você precisa:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Funcionar em apenas uma direção é uma pista do firewall

A saída se comporta de forma diferente, porque a regra de permissão implícita deixa as instâncias enviarem para qualquer lugar. Um data center que não alcança uma VM costuma ficar atrás de um caminho de saída perfeitamente funcional na outra direção. Essa assimetria separa uma omissão de firewall de uma falha de roteamento, já que uma falha de roteamento quebra as duas direções ao mesmo tempo. Teste a direção inversa antes de editar mais uma regra.

A criação de endereços também é uma operação de cota. Um projeto perto do limite de endereços externos em uso recusa a conexão com um erro que parece falha de permissão.

Seletores, cotas e depois as quatro verificações

Túneis criados no console às vezes retornam um seletor de tráfego remoto vazio a partir do gcloud compute vpn-tunnels describe, enquanto as rotas geradas transportam o tráfego corretamente. Compare o que a API registra com os intervalos que você realmente protege antes de concluir que o túnel está errado. Criá-lo pela API ou SDK mantém o seletor explícito.

As cotas são o outro esquecimento fácil. Solicite o aumento antes da janela de manutenção e não durante ela, e verifique a contagem de endereços no mesmo projeto do gateway.

Trabalhe de fora para dentro: status do par, as duas listas de seletores, uma rota por lado, uma regra de entrada para o intervalo de origem e a porta, e então uma captura de pacotes. Anote o endereço do gateway, as duas listas de seletores e o tipo de roteamento no ticket de mudança enquanto o túnel é novo, porque o próximo engenheiro que adicionar uma sub-rede vai precisar dos três.