Cloud VPN:s BGP-adresser hör hemma inne i tunneln, inte på ett nätverkskort

Öppna Cloud Router-sidan för VPN:en och en BGP-session med en adress i 169.254.0.0/16 stirrar tillbaka på dig. Den naturliga reaktionen är att placera den adressen någonstans på VM:en och vänta på att sessionen kommer upp. Den reaktionen är fel på ett särskilt sätt: paret tillhör den logiska länken som IPsec-tunneln skapar, inte maskinens vanliga nätverksgränssnitt. Ingenting du lägger till på NIC:en får tunneln att bära BGP.

Följ paret nedåt i stacken i stället för att lägga det på värden.

Börja där konsolen visar paret

Sessionssidan listar en BGP-adress för Cloud Router och en peer-adress, båda link-local för en IPv4 HA VPN. Bredvid dem står de yttre gateway-adresserna som terminerar tunnlarna. Det är olika objekt: link-local-paret lever inuti, och gateway-adresserna lever utanför och måste vara routbara innan något annat fungerar.

Skriv ner alla tre innan du öppnar en konfigurationsfil, eftersom att blanda ihop dem är hela felmoden.

Gå ner till tunneln som bär det

Link-local-paret betyder något först när det finns en IPsec-säkerhetsassociation mellan de två gatewayerna. På Googles sida skapar HA VPN-tunnlarna den på de två gränssnitten; på din sida är det vad peern förhandlade. Kontrollera först dataassociationen med swanctl --list-sas och notera vilken tunnel som är uppe på vilket gränssnitt, eftersom en frisk BGP-session över en död tunnel är omöjlig och en död tunnel med en hoppfull konfiguration är vardag.

BGP-paketet är inre IP-trafik. Det yttre nätet ser det aldrig, så ingen switch behöver båda adresserna på ett VLAN.

Konfigurera nu Linux-peern så att den matchar

Välj den stödda tunneldesignen och låt den bestämma de inre adresserna. Med ett ruttbaserat gränssnitt måste ruttposten och de förhandlade trafikväljarna stämma överens, eftersom ett gränssnittsnamn ensamt inte tillåter något. Rikta BIRD mot den inre lokala adressen och Cloud Routers inre adress, sätt AS-numren från sessionssidan och tillåt TCP 179 inom den skyddade vägen. Håll rutten till den avlägsna yttre adressen på den fysiska upplänken så att tunneln inte fångar sin egen transport.

En tunnel som routar sig själv är en loop med ett handslag, och den kommer att se ut som ett brandväggsproblem i en timme.

Kontrollera varje steg i ordning, inte allt på en gång

Gå igenom stegen: säkerhetsassociation uppe, inre peer nåbar från tunneladressen, BGP-session etablerad, prefix accepterade, sedan ett arbetslastprefix faktiskt använt. birdc show protocols svarar på den tredje frågan och ingenting annat, och det är därför folk utropar seger tidigt.

En etablerad granne lovar inte att båda sidor annonserade de prefix du behöver, eller att dessa rutter installerades som föredragna.

Om sessionen är etablerad och trafiken fortfarande tar fel väg, jämför de annonserade prefixen med vad routingtabellen gör med dem. En mer specifik rutt någon annanstans, eller en preferens för en annan väg, ger dig en fungerande BGP-session och ingen nyttig vidarebefordran.

Stanna innan du tillämpar detta på Router Appliance

Network Connectivity Center Router Appliance är en annan anslutningsmodell. Dess Cloud Router-peers använder interna adresser från VPC- och subnätuppsättningen i stället för HA VPN-link-local-paret. Om det egentliga målet är BGP med en routing-VM, följ den produktens gränssnittskrav i stället för att kopiera en link-local-session.

Link-local-omfång betyder fortfarande vad det säger. Den logiska tunneln levererar detta grannskap, och den ger ingen licens att routa godtyckliga link-local-destinationer över VPC:n.