Cloud VPNs BGP-adresser hører hjemme inne i tunnelen, ikke på et nettverkskort

Åpne Cloud Router-siden for VPN-en, og en BGP-økt med en adresse i 169.254.0.0/16 stirrer tilbake på deg. Den naturlige reaksjonen er å plassere den adressen et sted på VM-en og vente på at økten kommer opp. Den reaksjonen er feil på en bestemt måte: paret tilhører den logiske lenken som IPsec-tunnelen lager, ikke maskinens vanlige nettverksgrensesnitt. Ingenting du legger til på NIC-en får tunnelen til å bære BGP.

Følg paret nedover stakken i stedet for å legge det til på verten.

Start der konsollen viser paret

Øktsiden lister opp en Cloud Router BGP-adresse og en peer-adresse, begge link-local for en IPv4 HA VPN. Ved siden av dem står de ytre gateway-adressene som terminerer tunnelene. Det er forskjellige objekter: link-local-paret lever inni, og gateway-adressene lever utenfor og må være rutbare før noe annet virker.

Skriv ned alle tre før du åpner en konfigurasjonsfil, fordi å blande dem er hele feilmodusen.

Gå ned til tunnelen som bærer det

Link-local-paret betyr noe først når det finnes en IPsec-sikkerhetsassosiasjon mellom de to gatewayene. På Googles side lager HA VPN-tunnelene den på de to grensesnittene; på din side er det det peer-en forhandlet. Kontroller først dataassosiasjonen med swanctl --list-sas og noter hvilken tunnel som er oppe på hvilket grensesnitt, fordi en sunn BGP-økt over en død tunnel er umulig, og en død tunnel med en håpefull konfigurasjon er hverdagslig.

BGP-pakken er indre IP-trafikk. Det ytre nettverket ser den aldri, så ingen svitsj trenger begge adressene på ett VLAN.

Konfigurer nå Linux-peer-en til å matche

Velg det støttede tunneldesignet og la det bestemme de indre adressene. Med et rutebasert grensesnitt må ruteposten og de forhandlede trafikkvelgerne stemme overens, fordi et grensesnittnavn alene ikke tillater noe. Rett BIRD mot den indre lokale adressen og Cloud Routers indre adresse, sett AS-numrene fra øktsiden, og tillat TCP 179 innenfor den beskyttede banen. Hold ruten til den fjerne ytre adressen på den fysiske uplinken, slik at tunnelen ikke fanger sin egen transport.

En tunnel som ruter seg selv, er en løkke med et håndtrykk, og den vil se ut som et brannmurproblem i en time.

Kontroller hvert trinn i rekkefølge, ikke alt på en gang

Gå gjennom trinnene: sikkerhetsassosiasjon oppe, indre peer nåbar fra tunneladressen, BGP-økt etablert, prefikser akseptert, deretter et arbeidsbelastningsprefiks faktisk brukt. birdc show protocols svarer på det tredje spørsmålet og ingenting annet, og derfor erklærer folk seier tidlig.

En etablert nabo lover ikke at begge sider annonserte prefiksene du trenger, eller at disse rutene ble installert som foretrukne.

Hvis økten er etablert og trafikken fortsatt tar feil vei, sammenlign de annonserte prefiksene med hva rutetabellen gjør med dem. En mer spesifikk rute et annet sted, eller en preferanse for en annen vei, gir deg en fungerende BGP-økt og ingen nyttig videresending.

Stopp før du bruker dette på Router Appliance

Network Connectivity Center Router Appliance er en annen tilknytningsmodell. Cloud Router-peer-ene bruker interne adresser fra VPC- og subnettordningen i stedet for HA VPN-link-local-paret. Hvis det egentlige målet er BGP med en ruting-VM, følg det produktets grensesnittkrav i stedet for å kopiere en link-local-økt.

Link-local-omfang betyr fortsatt det det sier. Den logiske tunnelen leverer dette naboskapet, og den gir ikke lisens til å rute vilkårlige link-local-destinasjoner over VPC-en.