Wolk-VPN-BGP-adresse hoort binne die tonnel, nie op 'n netwerkkaart nie

Maak die Cloud Router-bladsy vir die VPN oop en 'n BGP-sessie met 'n adres in 169.254.0.0/16 staar jou in die gesig. Die natuurlike reaksie is om daardie adres iewers op die VM te plaas en te wag dat die sessie opkom. Daardie reaksie is op 'n spesifieke manier verkeerd: die paar hoort by die logiese skakel wat die IPsec-tonnel skep, nie by die masjien se gewone netwerkkoppelvlak nie. Niks wat jy by die NIC voeg, laat die tonnel BGP dra nie.

Volg die paar af in die stapel in plaas daarvan om dit by die gasheer te voeg.

Begin waar die konsole die paar wys

Die sessiebladsy lys 'n Cloud Router BGP-adres en 'n eweknie-adres, albei link-local vir 'n IPv4 HA VPN. Langs hulle is die buitenste gateway-adresse wat die tonnels beëindig. Dit is verskillende objekte: die link-local-paar leef binne, en die gateway-adresse leef buite en moet roetebaar wees voordat enigiets anders werk.

Skryf al drie neer voordat jy 'n konfigurasielêer oopmaak, want om hulle te verwar is die hele foutmodus.

Stap af na die tonnel wat dit dra

Die link-local-paar beteken iets eers wanneer 'n IPsec-sekuriteitsassosiasie tussen die twee gateways bestaan. Aan die Google-kant skep die HA VPN-tonnels dit op die twee koppelvlakke; aan jou kant is dit wat die eweknie beding het. Kontroleer eers die data-assosiasie met swanctl --list-sas en let op watter tonnel op watter koppelvlak op is, want 'n gesonde BGP-sessie oor 'n dooie tonnel is onmoontlik en 'n dooie tonnel met 'n hoopvolle konfigurasie is alledaags.

Die BGP-pakkie is binne-IP-verkeer. Die buitenste netwerk sien dit nooit, so geen skakelaar het albei adresse op een VLAN nodig nie.

Konfigureer nou die Linux-eweknie om te pas

Kies die ondersteunde tonnelontwerp en laat dit die binne-adresse bepaal. Met 'n roetegebaseerde koppelvlak moet die roetevermelding en die bedinge verkeerskeuses ooreenstem, want 'n koppelvlaknaam alleen laat niks toe nie. Wys BIRD na die binne-plaaslike adres en die Cloud Router se binne-adres, stel die AS-nommers vanaf die sessiebladsy in, en laat TCP 179 binne die beskermde pad toe. Hou die roete na die verre buitenste adres op die fisiese oplyn sodat die tonnel nie sy eie vervoer vasvang nie.

'n Tonnel wat homself roeteer is 'n lus met 'n handskud, en dit sal vir 'n uur soos 'n firewall-probleem lyk.

Kontroleer elke stadium in volgorde, nie die hele ding gelyk nie

Stap deur die stadiums: sekuriteitsassosiasie op, binne-eweknie bereikbaar vanaf die tonneladres, BGP-sessie gevestig, prefikse aanvaar, dan 'n werklading-prefiks wat werklik gebruik word. birdc show protocols antwoord die derde vraag en niks anders nie, en daarom verklaar mense vroeg oorwinning.

'n Gevestigde buur belowe nie dat albei kante die prefikse geadverteer het wat jy nodig het nie, of dat daardie roetes as voorkeur geïnstalleer is nie.

As die sessie gevestig is en verkeer steeds die verkeerde pad neem, vergelyk die geadverteerde prefikse met wat die roetevermelding daarmee doen. 'n Spesifiker roete elders, of 'n voorkeur vir 'n ander pad, gee jou 'n werkende BGP-sessie en geen nuttige aanstuur nie.

Stop voordat jy dit op Router Appliance toepas

Network Connectivity Center Router Appliance is 'n ander aanhegtingsmodel. Sy Cloud Router-eweknieë gebruik interne adresse uit die VPC- en subnet-reëling eerder as die HA VPN link-local-paar. As die werklike doel BGP met 'n roeter-VM is, volg daardie produk se koppelvlakvereistes eerder as om 'n link-local-sessie na te kopieer.

Link-local-omvang beteken steeds wat dit sê. Die logiese tonnel verskaf hierdie aangrensing, en dit lisensieer nie die roetering van willekeurige link-local-bestemmings oor die VPC nie.