BGP-adressene til Cloud VPN høyrer heime inne i tunnelen, ikkje på eit netverkskort

Opne Cloud Router-sida for VPN-en, og ei BGP-økt med ei adresse i 169.254.0.0/16 stirer tilbake på deg. Den naturlege reaksjonen er å plassere den adressa ein stad på VM-en og vente på at økta kjem opp. Den reaksjonen er feil på ein bestemt måte: paret høyrer til den logiske lenkja som IPsec-tunnelen lagar, ikkje til det vanlege netverksgrensesnittet til maskina. Ingenting du legg til på NIC-en får tunnelen til å bera BGP.

Følg paret nedover stakken i staden for å leggje det til på verten.

Start der konsollen viser paret

Øktsida listar opp ei Cloud Router BGP-adresse og ei peer-adresse, begge link-local for ein IPv4 HA VPN. Ved sida av dei står dei ytre gateway-adressene som terminerer tunnelane. Det er ulike objekt: link-local-paret lever inni, og gateway-adressene lever utanfor og må vere rutbare før noko anna verkar.

Skriv ned alle tre før du opnar ei konfigurasjonsfil, fordi å blande dei er heile feilmodusen.

Gå ned til tunnelen som ber det

Link-local-paret tyder noko først når det finst ein IPsec-tryggleiksassosiasjon mellom dei to gatewayane. På Google-sida lagar HA VPN-tunnelane han på dei to grensesnitta; på di side er det det peer-en forhandla. Kontroller først dataassosiasjonen med swanctl --list-sas og noter kva tunnel som er oppe på kva grensesnitt, fordi ei sunn BGP-økt over ein død tunnel er umogleg, og ein død tunnel med ein håpefull konfigurasjon er kvardag.

BGP-pakken er indre IP-trafikk. Det ytre netverket ser han aldri, så ingen svitsj treng båe adressene på eitt VLAN.

Konfigurer no Linux-peer-en til å passe

Vel det støtta tunneldesignet og la det avgjere dei indre adressene. Med eit rutebasert grensesnitt må ruteposten og dei forhandla trafikkveljarane stemme overeins, fordi eit grensesnittnamn åleine ikkje tillèt noko. Rett BIRD mot den indre lokale adressa og den indre adressa til Cloud Router, set AS-numra frå øktsida, og tillèt TCP 179 innanfor den verna banen. Hald ruta til den fjerne ytre adressa på den fysiske uplinken, slik at tunnelen ikkje fangar sin eigen transport.

Ein tunnel som ruter seg sjølv, er ei løkke med eit handtrykk, og han vil sjå ut som eit brannmurproblem i ein time.

Kontroller kvart trinn i rekkjefølgje, ikkje alt på ein gong

Gå gjennom trinna: tryggleiksassosiasjon oppe, indre peer nåbar frå tunneladressa, BGP-økt etablert, prefiks godtekne, deretter eit arbeidslastprefiks faktisk brukt. birdc show protocols svarar på det tredje spørsmålet og ingenting anna, og difor erklærer folk siger tidleg.

Ein etablert nabo lovar ikkje at båe sider annonserte prefiksa du treng, eller at desse rutene vart installerte som føretrekte.

Viss økta er etablert og trafikken framleis tek feil veg, samanlikn dei annonserte prefiksa med kva rutetabellen gjer med dei. Ei meir spesifikk rute ein annan stad, eller ei preferanse for ein annan veg, gjev deg ei fungerande BGP-økt og inga nyttig videresending.

Stopp før du brukar dette på Router Appliance

Network Connectivity Center Router Appliance er ein annan tilknytingsmodell. Cloud Router-peer-ane brukar interne adresser frå VPC- og subnettordninga i staden for HA VPN-link-local-paret. Viss det eigentlege målet er BGP med ein ruting-VM, følg grensesnittkrava til det produktet i staden for å kopiere ei link-local-økt.

Link-local-omfang tyder framleis det det seier. Den logiske tunnelen leverer dette naboskapet, og han gjev ikkje løyve til å rute vilkårlege link-local-destinasjonar over VPC-en.