Cloud VPN BGP-adresser hører til inde i tunnelen, ikke på et netkort

Åbn Cloud Router-siden for VPN'en, og en BGP-session med en adresse i 169.254.0.0/16 stirrer tilbage på dig. Den naturlige reaktion er at placere den adresse et sted på VM'en og vente på, at sessionen kommer op. Den reaktion er forkert på en bestemt måde: parret hører til det logiske link, som IPsec-tunnelen opretter, ikke til maskinens almindelige netværksinterface. Intet, du tilføjer til NIC'en, får tunnelen til at bære BGP.

Følg parret ned gennem stakken i stedet for at tilføje det til værten.

Start hvor konsollen viser parret

Sessionssiden viser en Cloud Router BGP-adresse og en peer-adresse, begge link-local for en IPv4 HA VPN. Ved siden af dem står de ydre gateway-adresser, som terminerer tunnelerne. Det er forskellige objekter: link-local-parret lever indeni, og gateway-adresserne lever udenfor og skal kunne routes, før noget andet virker.

Skriv alle tre ned, før du åbner en konfigurationsfil, fordi at forveksle dem er hele fejlmåden.

Gå ned til den tunnel, der bærer det

Link-local-parret betyder først noget, når der findes en IPsec-sikkerhedsassociation mellem de to gateways. På Googles side opretter HA VPN-tunnelerne den på de to interfaces; på din side er det, hvad peer'en har forhandlet. Kontrollér først dataassociationen med swanctl --list-sas og notér, hvilken tunnel der er oppe på hvilket interface, for en sund BGP-session over en død tunnel er umulig, og en død tunnel med en håbefuld konfiguration er dagligdag.

BGP-pakken er indre IP-trafik. Det ydre netværk ser den aldrig, så ingen switch behøver begge adresser på ét VLAN.

Konfigurér nu Linux-peer'en, så den matcher

Vælg det understøttede tunneldesign, og lad det bestemme de indre adresser. Med et rutebaseret interface skal routingposten og de forhandlede trafikvælgere stemme overens, for et interfacenavn alene tillader intet. Ret BIRD mod den indre lokale adresse og Cloud Routers indre adresse, sæt AS-numrene fra sessionssiden, og tillad TCP 179 inden for den beskyttede sti. Hold ruten til den fjerne ydre adresse på det fysiske uplink, så tunnelen ikke fanger sin egen transport.

En tunnel, der router sig selv, er en løkke med et håndtryk, og den vil se ud som et firewall-problem i en time.

Kontrollér hvert trin i rækkefølge, ikke det hele på én gang

Gå trinnene igennem: sikkerhedsassociation oppe, indre peer nåbar fra tunneladressen, BGP-session etableret, præfikser accepteret, derefter et workload-præfiks faktisk brugt. birdc show protocols besvarer det tredje spørgsmål og intet andet, og derfor erklærer folk sejr tidligt.

En etableret nabo lover ikke, at begge sider har annonceret de præfikser, du har brug for, eller at disse ruter er installeret som foretrukne.

Hvis sessionen er etableret, og trafikken stadig tager den forkerte vej, sammenlign de annoncerede præfikser med, hvad routingtabellen gør ved dem. En mere specifik rute et andet sted, eller en præference for en anden vej, giver dig en fungerende BGP-session og ingen nyttig videresendelse.

Stop, før du anvender dette på Router Appliance

Network Connectivity Center Router Appliance er en anden tilknytningsmodel. Dets Cloud Router-peers bruger interne adresser fra VPC- og subnetordningen i stedet for HA VPN-link-local-parret. Hvis det egentlige mål er BGP med en routing-VM, så følg det produkts interfacekrav i stedet for at kopiere en link-local-session.

Link-local-omfang betyder stadig, hvad det siger. Den logiske tunnel leverer dette naboskab, og den giver ikke licens til at route vilkårlige link-local-destinationer over VPC'en.