GCP HA VPN: a sessão BGP fica em Waiting for peer, a troca do par de endereços

Uma sessão BGP que nunca chega a Established num túnel Cloud VPN normalmente não é um problema de encaminhamento. É um problema de cablagem: dois endereços que têm de se refletir um no outro foram introduzidos na ordem errada, ou o par do primeiro túnel foi reutilizado no segundo. O túnel em si pode estar perfeitamente saudável enquanto a sessão fica em Waiting for peer, porque IPsec e BGP são negociações separadas entre os mesmos dois extremos. Decida qual dos dois está avariado antes de reconstruir qualquer coisa.

Uma pergunta resolve a maioria dos casos: o dispositivo par vê sequer o endereço do Cloud Router?

O estado do túnel e o estado da sessão são verificações diferentes

IKE e ESP vêm primeiro. Se o túnel não estiver estabelecido, nada lá dentro importa e a conversa sobre o endereço BGP é prematura. Leia o estado e o estado detalhado do túnel e depois o estado do par BGP do router para esse mesmo túnel.

Um túnel ativo enquanto o seu par BGP está em baixo reduz a falha à sessão: endereço do par, ASN ou TCP 179 a chegar ao endereço interno. Um túnel ativo, uma sessão ativa e ainda sem rotas na VPC é um terceiro caso. Mudar endereços não ajuda aí, porque a sessão já funciona e o prefixo simplesmente não é anunciado ou não é preferido. Separar estes três casos é a maior parte do trabalho.

Cada túnel precisa do seu próprio /30, com as duas pontas preenchidas

Cada túnel HA VPN recebe um /30 link-local de 169.254.0.0/16, com um endereço na interface do Cloud Router e o outro no seu par. O campo do par tem de nomear a ponta remota, nunca o endereço do próprio router.

Dois túneis significam duas interfaces no Cloud Router, cada uma com um /30 diferente. Reutilizar o par do túnel 0 no túnel 1 é o erro que parece arrumado numa tabela resumo e morre no pacote OPEN.

Leia o par a partir do recurso do router e não do resumo da consola. O resumo lista o endereço do par numa coluna fácil de ler mal, e o ipRange da interface mais o peerIpAddress do par têm de descrever pontas opostas de um mesmo /30.

A troca acontece normalmente durante uma reconstrução

É ao reconstruir um túnel que os pares se cruzam. O endereço do par do túnel antigo é copiado para o campo de interface do novo, ou a nova sessão é apontada ao par da sessão anterior. De uma forma ou de outra, o Cloud Router envia pacotes OPEN para um endereço que agora é ele próprio ou para um endereço sem túnel por trás.

Anote os pares antes de abrir a consola: nome do túnel, interface, endereço do router, endereço do par, ASN do par. Depois crie os dois túneis numa só passagem, para que o segundo não seja preenchido com os restos do primeiro.

Outras três razões pelas quais uma sessão espera

O ASN do par é a primeira: cada lado tem de ser configurado com o ASN do outro, e uma discrepância chega ao par mas nunca se estabelece. A segunda é a firewall do próprio par, que tem de permitir TCP 179 na interface do túnel; uma regra IKE ou ESP não cobre isso. A terceira é um par que responde de um endereço de origem diferente do configurado como seu vizinho.

O registo do próprio par é o discriminante. Se o resumo BGP não listar nenhum vizinho para esse endereço, os pacotes não chegam e o par ou o caminho estão errados. Se o vizinho estiver em Active ou Connect, os pacotes chegam e os parâmetros da sessão não batem certo.

Verifique pela ordem em que os pacotes viajam

Trabalhe para fora: estado do túnel, depois estado do par BGP do router, depois o resumo BGP do par, depois as rotas. Se os dois primeiros estiverem saudáveis, pare de editar o lado Cloud VPN e trabalhe no dispositivo par. Se o router reportar o par em baixo e o seu dispositivo não tiver nenhum vizinho, o par está errado ou a porta BGP está filtrada. Uma captura de pacotes na interface do túnel do par resolve-o num relance, porque os pacotes OPEN ou chegam lá ou nunca chegam.

gcloud compute routers get-status ROUTER --region=REGION imprime o estado do par ao lado do endereço que está a usar, e é exatamente o par que precisa de comparar.

Assim que a sessão se estabelecer, confirme que o prefixo aprendido aparece na tabela de rotas da VPC e que um anfitrião de cada lado responde. Depois registe os pares finais ao lado dos nomes dos túneis, para que a próxima reconstrução comece a partir de uma tabela verificada e não do resumo da consola.