BGP-adressene til Cloud VPN skal ligge i tunnelen, ikke på nettverkskortet

Åpne Cloud Router-siden for VPN-et, så stirrer en BGP-sesjon med adresse i 169.254.0.0/16 tilbake på deg. Den naturlige reaksjonen er å sette den adressen et sted på VM-en og vente på at sesjonen kommer opp. Reaksjonen er feil på en presis måte: paret hører til den logiske forbindelsen som IPsec-tunnelen etablerer, ikke til maskinens ordinære nettverksgrensesnitt. Det du måtte legge til på nettverkskortet får ikke tunnelen til å frakte BGP.

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

Begynn der konsollen viser paret

Sesjonssiden lister en BGP-adresse for Cloud Router og en peer-adresse, begge link-local for en IPv4 HA VPN. Ved siden av står de ytre gateway-adressene som avslutter tunnelene. Dette er forskjellige objekter: link-local-paret befinner seg inni, mens gateway-adressene befinner seg utenfor og må være rutbare før noe annet virker.

Noter alle tre før du åpner en konfigurasjonsfil, siden forveksling av dem er hele feilmønsteret.

Gå ned til tunnelen som frakter det

Link-local-paret har først betydning når det eksisterer en IPsec-sikkerhetsassosiasjon mellom de to gateway-ene. Hos Google oppretter HA VPN-tunnelene den på de to grensesnittene; hos deg er det det peer-en forhandlet frem. Sjekk dataassosiasjonen først med swanctl --list-sas og noter hvilken tunnel som er oppe på hvilket grensesnitt, siden en frisk BGP-sesjon over en død tunnel er umulig, mens en død tunnel med håpefull konfigurasjon er helt vanlig.

BGP-pakken er indre IP-trafikk. Det ytre nettet ser den aldri, så ingen switch trenger begge adressene på samme VLAN.

Sett nå opp Linux-peer-en slik at den samsvarer

Velg det støttede tunneldesignet og la det bestemme de indre adressene. Med et rutebasert grensesnitt må ruteposten og de forhandlede trafikkvelgerne være enige, siden et grensesnittnavn alene ikke tillater noe som helst. Pek BIRD mot den indre lokale adressen og den indre adressen til Cloud Router, sett AS-numrene fra sesjonssiden, og tillat TCP 179 innenfor den beskyttede stien. Hold ruten mot 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 håndtrykk, og den vil se ut som et brannmurproblem i en time.

Kontroller hvert trinn i rekkefølge, ikke alt samtidig

Gå gjennom trinnene: sikkerhetsassosiasjon oppe, indre peer nåbar fra tunneladressen, BGP-sesjon etablert, prefikser godtatt, og deretter et arbeidslastprefiks som faktisk brukes. birdc show protocols besvarer det tredje spørsmålet og ingenting annet, og det er derfor folk utroper seier for tidlig.

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

Dersom sesjonen er etablert og trafikken likevel tar feil vei, sammenlign de annonserte prefiksene med det rutetabellen gjør med dem. En mer spesifikk rute et annet sted, eller en preferanse for en annen vei, gir deg en fungerende BGP-sesjon og ingen nyttig videresending.

Stopp før du anvender dette på Router Appliance

Network Connectivity Center Router Appliance er en annen tilkoblingsmodell. Cloud Router-peer-ene bruker interne adresser fra VPC- og subnett-oppsettet i stedet for HA VPN-link-local-paret. Hvis det egentlige målet er BGP med en rute-VM, følg grensesnittkravene til det produktet i stedet for å kopiere en link-local-sesjon.

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