Os endereços BGP do Cloud VPN pertencem ao interior do túnel, não à placa de rede

Abra a página do Cloud Router da VPN e uma sessão BGP com um endereço em 169.254.0.0/16 encara você. A reação natural é colocar esse endereço em algum lugar da VM e esperar que a sessão suba. Essa reação está errada de uma forma específica: o par pertence à ligação lógica que o túnel IPsec cria, não à interface de rede comum da máquina. Nada que você adicione à NIC faz o túnel transportar BGP.

Siga o par pela pilha abaixo em vez de adicioná-lo ao host.

Comece onde o console mostra o par

A página da sessão lista um endereço BGP do Cloud Router e um endereço de par, ambos link-local para uma HA VPN IPv4. Ao lado deles estão os endereços de gateway externos que terminam os túneis. São objetos diferentes: o par link-local vive dentro, e os endereços de gateway vivem fora e precisam ser roteáveis antes que qualquer outra coisa funcione.

Anote os três antes de abrir um ficheiro de configuração, porque confundi-los é todo o modo de falha.

Desça até ao túnel que o transporta

O par link-local só significa algo quando existe uma associação de segurança IPsec entre os dois gateways. Do lado da Google, os túneis HA VPN criam-na nas duas interfaces; do seu lado é o que o par negociou. Verifique primeiro a associação de dados com swanctl --list-sas e anote qual túnel está ativo em qual interface, porque uma sessão BGP saudável sobre um túnel morto é impossível e um túnel morto com uma configuração cheia de esperança é o habitual.

O pacote BGP é tráfego IP interior. A rede exterior nunca o vê, por isso nenhum comutador precisa dos dois endereços na mesma VLAN.

Agora configure o par Linux para corresponder

Escolha o desenho de túnel suportado e deixe-o decidir os endereços interiores. Com uma interface baseada em rotas, a entrada de encaminhamento e os seletores de tráfego negociados têm de concordar, porque um nome de interface sozinho não permite nada. Aponte o BIRD para o endereço local interior e para o endereço interior do Cloud Router, defina os números AS da página da sessão e permita TCP 179 dentro do caminho protegido. Mantenha a rota para o endereço exterior distante no uplink físico para que o túnel não capture o seu próprio transporte.

Um túnel que se encaminha a si mesmo é um ciclo com um aperto de mão, e durante uma hora parecerá um problema de firewall.

Verifique cada etapa por ordem, não tudo ao mesmo tempo

Percorra as etapas: associação de segurança ativa, par interior alcançável a partir do endereço do túnel, sessão BGP estabelecida, prefixos aceites e depois um prefixo de carga de trabalho realmente utilizado. birdc show protocols responde à terceira pergunta e a mais nada, e é por isso que as pessoas declaram vitória cedo.

Um vizinho estabelecido não promete que ambos os lados anunciaram os prefixos de que precisa, nem que essas rotas foram instaladas como preferidas.

Se a sessão está estabelecida e o tráfego continua a seguir o caminho errado, compare os prefixos anunciados com o que a tabela de encaminhamento faz com eles. Uma rota mais específica noutro lugar, ou uma preferência por outro caminho, dá-lhe uma sessão BGP a funcionar e nenhum encaminhamento útil.

Pare antes de aplicar isto ao Router Appliance

O Network Connectivity Center Router Appliance é um modelo de ligação diferente. Os seus pares Cloud Router usam endereços internos da disposição de VPC e sub-rede em vez do par link-local da HA VPN. Se o objetivo real é BGP com uma VM de encaminhamento, siga os requisitos de interface desse produto em vez de copiar uma sessão link-local.

O âmbito link-local continua a significar o que diz. O túnel lógico fornece esta adjacência, e não licencia o encaminhamento de destinos link-local arbitrários pela VPC.