BGP-adressen van Cloud VPN horen in de tunnel, niet op een netwerkkaart

Open de Cloud Router-pagina voor de VPN en een BGP-sessie met een adres in 169.254.0.0/16 staart je aan. De natuurlijke reactie is dat adres ergens op de VM te zetten en te wachten tot de sessie omhoogkomt. Die reactie is op een specifieke manier fout: het paar hoort bij de logische verbinding die de IPsec-tunnel maakt, niet bij de gewone netwerkinterface van de machine. Niets wat je aan de NIC toevoegt, zorgt dat de tunnel BGP draagt.

Volg het paar de stack af in plaats van het aan de host toe te voegen.

Begin waar de console het paar toont

De sessiepagina vermeldt een BGP-adres van de Cloud Router en een peer-adres, beide link-local voor een IPv4 HA VPN. Daarnaast staan de buitenste gateway-adressen die de tunnels beëindigen. Dat zijn verschillende objecten: het link-local paar leeft binnenin, en de gateway-adressen leven buiten en moeten routeerbaar zijn voordat iets anders werkt.

Schrijf ze alle drie op voordat je een configuratiebestand opent, want ze door elkaar halen is de hele faalmodus.

Loop naar beneden naar de tunnel die het draagt

Het link-local paar betekent pas iets als er een IPsec-beveiligingsassociatie tussen de twee gateways bestaat. Aan de Google-kant maken de HA VPN-tunnels die op de twee interfaces; aan jouw kant is het wat de peer heeft onderhandeld. Controleer eerst de data-associatie met swanctl --list-sas en noteer welke tunnel op welke interface omhoog is, want een gezonde BGP-sessie over een dode tunnel is onmogelijk en een dode tunnel met een hoopvolle configuratie is routine.

Het BGP-pakket is innerlijke IP-traffic. Het buitenste netwerk ziet het nooit, dus geen enkele switch heeft beide adressen op één VLAN nodig.

Configureer nu de Linux-peer zodat die past

Kies het ondersteunde tunnelontwerp en laat dat de binnenadressen bepalen. Met een route-gebaseerde interface moeten de routing-entry en de onderhandelde traffic-selectors overeenkomen, want een interfacenaam alleen staat niets toe. Richt BIRD op het binnenste lokale adres en het binnenadres van de Cloud Router, stel de AS-nummers van de sessiepagina in en sta TCP 179 binnen het beschermde pad toe. Houd de route naar het verre buitenadres op de fysieke uplink zodat de tunnel zijn eigen transport niet vangt.

Een tunnel die zichzelf routeert is een lus met een handdruk, en hij zal een uur lang op een firewallprobleem lijken.

Controleer elke fase in volgorde, niet alles tegelijk

Loop de fasen langs: beveiligingsassociatie omhoog, binnenste peer bereikbaar vanaf het tunneladres, BGP-sessie opgezet, prefixen geaccepteerd, en dan een workload-prefix die echt gebruikt wordt. birdc show protocols beantwoordt de derde vraag en niets anders, en daarom verklaren mensen vroeg de overwinning.

Een opgezette buur belooft niet dat beide kanten de prefixen hebben aangekondigd die je nodig hebt, of dat die routes als voorkeur zijn geïnstalleerd.

Als de sessie is opgezet en het verkeer nog steeds de verkeerde kant op gaat, vergelijk dan de aangekondigde prefixen met wat de routingtabel ermee doet. Een specifiekere route elders, of een voorkeur voor een ander pad, geeft je een werkende BGP-sessie en geen nuttige doorsturing.

Stop voordat je dit op Router Appliance toepast

Network Connectivity Center Router Appliance is een ander koppelingsmodel. De Cloud Router-peers gebruiken interne adressen uit de VPC- en subnetindeling in plaats van het HA VPN link-local paar. Als het echte doel BGP met een routing-VM is, volg dan de interface-eisen van dat product in plaats van een link-local sessie te kopiëren.

Link-local bereik betekent nog steeds wat het zegt. De logische tunnel levert dit nabuurschap, en die geeft geen licentie om willekeurige link-local bestemmingen over de VPC te routeren.