Os enderezos BGP de Cloud VPN van dentro do túnel, non na tarxeta de rede

Abra a páxina de Cloud Router para a VPN e unha sesión BGP cun enderezo en 169.254.0.0/16 devólvelle a mirada. A reacción natural é poñer ese enderezo nalgún lugar da VM e agardar a que a sesión suba. Esa reacción é incorrecta dun xeito concreto: o par pertence á ligazón lóxica que crea o túnel IPsec, non á interface de rede ordinaria da máquina. Nada do que engada á NIC fará que o túnel transporte BGP.

Siga o par cara abaixo pola pila en lugar de engadilo ao host.

Comece onde a consola mostra o par

A páxina da sesión enumera un enderezo BGP de Cloud Router e un enderezo de par, ambos link-local para unha HA VPN IPv4. Xunto a eles están os enderezos de pasarela externos que rematan os túneles. Son obxectos distintos: o par link-local vive dentro, e os enderezos de pasarela viven fóra e deben ser encamiñables antes de que funcione calquera outra cousa.

Anote os tres antes de abrir un ficheiro de configuración, porque confundilos é todo o modo de fallo.

Baixe ata o túnel que o transporta

O par link-local só significa algo cando existe unha asociación de seguridade IPsec entre as dúas pasarelas. No lado de Google os túneles de HA VPN créana nas dúas interfaces; no seu lado é o que negociou o par. Comprobe primeiro a asociación de datos con swanctl --list-sas e anote que túnel está activo en que interface, porque unha sesión BGP sana sobre un túnel morto é imposible e un túnel morto cunha configuración esperanzada é o habitual.

O paquete BGP é tráfico IP interior. A rede exterior nunca o ve, así que ningún conmutador necesita ambos enderezos nunha VLAN.

Agora configure o par Linux para que coincida

Escolla o deseño de túnel admitido e deixe que decida os enderezos interiores. Cunha interface baseada en rutas, a entrada de encamiñamento e os selectores de tráfico negociados teñen que coincidir, porque un nome de interface por si só non permite nada. Apunte BIRD ao enderezo local interior e ao enderezo interior de Cloud Router, fixe os números AS da páxina da sesión e permita TCP 179 dentro da ruta protexida. Manteña a ruta ao enderezo exterior afastado na ligazón física para que o túnel non capture o seu propio transporte.

Un túnel que se encamiña a si mesmo é un bucle cunha aperta de mans, e durante unha hora parecerá un problema de devasa.

Comprobe cada etapa en orde, non todo á vez

Percorra as etapas: asociación de seguridade activa, par interior alcanzable desde o enderezo do túnel, sesión BGP establecida, prefixos aceptados e despois un prefixo de carga de traballo realmente usado. birdc show protocols responde a terceira pregunta e nada máis, e por iso a xente declara a vitoria demasiado pronto.

Un veciño establecido non promete que ambos lados anunciasen os prefixos que necesita, nin que esas rutas se instalasen como preferentes.

Se a sesión está establecida e o tráfico segue tomando o camiño equivocado, compare os prefixos anunciados co que a táboa de encamiñamento fai con eles. Unha ruta máis específica noutro lugar, ou unha preferencia por outro camiño, dálle unha sesión BGP funcionando e ningún reenvío útil.

Détase antes de aplicar isto a Router Appliance

Network Connectivity Center Router Appliance é un modelo de conexión distinto. Os seus pares de Cloud Router usan enderezos internos da disposición de VPC e subrede en lugar do par link-local de HA VPN. Se o obxectivo real é BGP cunha VM de encamiñamento, siga os requisitos de interface dese produto en lugar de copiar unha sesión link-local.

O ámbito link-local segue significando o que di. O túnel lóxico fornece esta adxacencia, e non autoriza a encamiñar destinos link-local arbitrarios pola VPC.