Adresele BGP ale Cloud VPN aparțin în interiorul tunelului, nu plăcii de rețea

Deschideți pagina Cloud Router pentru VPN și o sesiune BGP cu o adresă în 169.254.0.0/16 se uită la dumneavoastră. Reacția firească este să puneți acea adresă undeva pe VM și să așteptați ca sesiunea să urce. Acea reacție este greșită într-un mod specific: perechea aparține legăturii logice pe care o creează tunelul IPsec, nu interfeței de rețea obișnuite a mașinii. Nimic din ce adăugați la NIC nu face tunelul să transporte BGP.

Urmați perechea în jos pe stivă în loc să o adăugați la gazdă.

Începeți de unde consola arată perechea

Pagina sesiunii listează o adresă BGP a Cloud Router și o adresă de partener, ambele link-local pentru un HA VPN IPv4. Lângă ele sunt adresele de gateway exterioare care termină tunelurile. Sunt obiecte diferite: perechea link-local trăiește în interior, iar adresele de gateway trăiesc în exterior și trebuie să fie rutabile înainte ca orice altceva să funcționeze.

Notați-le pe toate trei înainte de a deschide un fișier de configurare, pentru că încurcarea lor este întregul mod de eșec.

Coborâți la tunelul care o transportă

Perechea link-local înseamnă ceva doar când există o asociere de securitate IPsec între cele două gateway-uri. De partea Google, tunelurile HA VPN o creează pe cele două interfețe; de partea dumneavoastră este ceea ce a negociat partenerul. Verificați mai întâi asocierea de date cu swanctl --list-sas și notați ce tunel este sus pe ce interfață, pentru că o sesiune BGP sănătoasă peste un tunel mort este imposibilă, iar un tunel mort cu o configurație plină de speranță este obișnuit.

Pachetul BGP este trafic IP interior. Rețeaua exterioară nu îl vede niciodată, așa că niciun comutator nu are nevoie de ambele adrese într-un singur VLAN.

Acum configurați partenerul Linux ca să corespundă

Alegeți designul de tunel acceptat și lăsați-l să decidă adresele interioare. Cu o interfață bazată pe rutare, intrarea de rutare și selectoarele de trafic negociate trebuie să fie de acord, pentru că un nume de interfață singur nu permite nimic. Îndreptați BIRD către adresa locală interioară și adresa interioară a Cloud Router, setați numerele AS de pe pagina sesiunii și permiteți TCP 179 în interiorul căii protejate. Țineți ruta către adresa exterioară îndepărtată pe uplink-ul fizic, astfel încât tunelul să nu își captureze propriul transport.

Un tunel care se rutează pe sine este o buclă cu o strângere de mână și va arăta ca o problemă de firewall timp de o oră.

Verificați fiecare etapă în ordine, nu totul deodată

Parcurgeți etapele: asocierea de securitate sus, partenerul interior accesibil din adresa tunelului, sesiunea BGP stabilită, prefixele acceptate, apoi un prefix de sarcină de lucru chiar utilizat. birdc show protocols răspunde la a treia întrebare și la nimic altceva, motiv pentru care oamenii declară victoria prea devreme.

Un vecin stabilit nu promite că ambele părți au anunțat prefixele de care aveți nevoie sau că acele rute au fost instalate ca preferate.

Dacă sesiunea este stabilită și traficul tot ia calea greșită, comparați prefixele anunțate cu ceea ce face tabela de rutare cu ele. O rută mai specifică în altă parte, sau o preferință pentru altă cale, vă dă o sesiune BGP funcțională și nicio redirecționare utilă.

Opriți-vă înainte de a aplica acest lucru la Router Appliance

Network Connectivity Center Router Appliance este un model de atașare diferit. Partenerii săi Cloud Router folosesc adrese interne din aranjamentul VPC și subrețea în locul perechii link-local a HA VPN. Dacă scopul real este BGP cu un VM de rutare, urmați cerințele de interfață ale acelui produs în loc să copiați o sesiune link-local.

Domeniul link-local încă înseamnă ceea ce spune. Tunelul logic furnizează această vecinătate și nu autorizează rutarea unor destinații link-local arbitrare prin VPC.