Gli indirizzi BGP di Cloud VPN stanno dentro il tunnel, non sulla scheda di rete

Aprite la pagina Cloud Router della VPN e una sessione BGP con un indirizzo in 169.254.0.0/16 vi fissa. La reazione naturale è mettere quell'indirizzo da qualche parte sulla VM e attendere che la sessione salga. Quella reazione è sbagliata in un modo preciso: la coppia appartiene al collegamento logico che il tunnel IPsec crea, non all'interfaccia di rete ordinaria della macchina. Nulla di ciò che aggiungete alla NIC fa trasportare BGP al tunnel.

Seguite la coppia lungo lo stack invece di aggiungerla all'host.

Cominciate da dove la console mostra la coppia

La pagina della sessione elenca un indirizzo BGP di Cloud Router e un indirizzo di peer, entrambi link-local per una HA VPN IPv4. Accanto ci sono gli indirizzi di gateway esterni che terminano i tunnel. Sono oggetti diversi: la coppia link-local vive all'interno, e gli indirizzi di gateway vivono all'esterno e devono essere instradabili prima che qualsiasi altra cosa funzioni.

Annotate tutti e tre prima di aprire un file di configurazione, perché confonderli è l'intera modalità di guasto.

Scendete fino al tunnel che lo trasporta

La coppia link-local significa qualcosa solo quando esiste un'associazione di sicurezza IPsec tra i due gateway. Sul lato Google i tunnel HA VPN la creano sulle due interfacce; sul vostro lato è ciò che il peer ha negoziato. Controllate prima l'associazione dati con swanctl --list-sas e annotate quale tunnel è attivo su quale interfaccia, perché una sessione BGP sana su un tunnel morto è impossibile e un tunnel morto con una configurazione speranzosa è la norma.

Il pacchetto BGP è traffico IP interno. La rete esterna non lo vede mai, quindi nessuno switch ha bisogno di entrambi gli indirizzi su una VLAN.

Ora configurate il peer Linux perché corrisponda

Scegliete il progetto di tunnel supportato e lasciate che decida gli indirizzi interni. Con un'interfaccia basata su routing, la voce di routing e i selettori di traffico negoziati devono concordare, perché un nome di interfaccia da solo non permette nulla. Puntate BIRD all'indirizzo locale interno e all'indirizzo interno di Cloud Router, impostate i numeri AS dalla pagina della sessione e consentite TCP 179 all'interno del percorso protetto. Mantenete la rotta verso l'indirizzo esterno remoto sull'uplink fisico così che il tunnel non catturi il proprio trasporto.

Un tunnel che instrada se stesso è un ciclo con una stretta di mano, e per un'ora sembrerà un problema di firewall.

Controllate ogni fase in ordine, non tutto insieme

Percorrete le fasi: associazione di sicurezza attiva, peer interno raggiungibile dall'indirizzo del tunnel, sessione BGP stabilita, prefissi accettati, poi un prefisso di carico di lavoro realmente usato. birdc show protocols risponde alla terza domanda e a nient'altro, ed è per questo che le persone dichiarano vittoria presto.

Un vicino stabilito non promette che entrambi i lati abbiano annunciato i prefissi che vi servono, né che quelle rotte siano state installate come preferite.

Se la sessione è stabilita e il traffico prende ancora la strada sbagliata, confrontate i prefissi annunciati con ciò che la tabella di routing ne fa. Una rotta più specifica altrove, o una preferenza per un altro percorso, vi dà una sessione BGP funzionante e nessun inoltro utile.

Fermatevi prima di applicarlo a Router Appliance

Network Connectivity Center Router Appliance è un modello di collegamento diverso. I suoi peer Cloud Router usano indirizzi interni dalla disposizione di VPC e sottorete invece della coppia link-local di HA VPN. Se l'obiettivo reale è BGP con una VM di routing, seguite i requisiti di interfaccia di quel prodotto invece di copiare una sessione link-local.

L'ambito link-local significa ancora ciò che dice. Il tunnel logico fornisce questa adiacenza, e non autorizza a instradare destinazioni link-local arbitrarie attraverso la VPC.