GCP HA VPN: sessione BGP ferma su Waiting for peer, lo scambio delle coppie di indirizzi

Una sessione BGP che non raggiunge mai Established su un tunnel Cloud VPN di solito non è un problema di routing. È un problema di cablaggio: due indirizzi che devono rispecchiarsi sono stati inseriti nell'ordine sbagliato, oppure la coppia del primo tunnel è stata riusata sul secondo. Il tunnel stesso può essere perfettamente sano mentre la sessione resta su Waiting for peer, perché IPsec e BGP sono negoziazioni separate tra gli stessi due endpoint. Decidete quale dei due è rotto prima di ricostruire qualsiasi cosa.

Una domanda risolve la maggior parte dei casi: il dispositivo peer vede l'indirizzo del Cloud Router?

Stato del tunnel e stato della sessione sono controlli diversi

IKE ed ESP vengono prima. Se il tunnel non è stabilito, nulla al suo interno conta e la discussione sull'indirizzo BGP è prematura. Leggete lo stato e lo stato dettagliato del tunnel, poi lo stato del peer BGP del router per quello stesso tunnel.

Un tunnel attivo mentre il suo peer BGP è abbassato restringe il guasto alla sessione: indirizzo del peer, ASN oppure TCP 179 che arriva sull'indirizzo interno. Un tunnel attivo, una sessione attiva e ancora nessuna rotta nella VPC è un terzo caso. Cambiare gli indirizzi non aiuterà, perché la sessione funziona già e il prefisso semplicemente non viene annunciato o non viene preferito. Tenere separati questi tre casi è la maggior parte del lavoro.

Ogni tunnel richiede il proprio /30, con entrambe le estremità compilate

Ogni tunnel HA VPN riceve un /30 link-local da 169.254.0.0/16, con un indirizzo sull'interfaccia del Cloud Router e l'altro sul vostro peer. Il campo peer deve indicare l'estremità remota, mai l'indirizzo del router stesso.

Due tunnel significano due interfacce sul Cloud Router, ciascuna con un /30 diverso. Riusare la coppia del tunnel 0 sul tunnel 1 è l'errore che sembra ordinato in una tabella riassuntiva e muore nel pacchetto OPEN.

Leggete la coppia dalla risorsa del router invece che dal riepilogo della console. Il riepilogo elenca l'indirizzo del peer in una colonna facile da leggere male, e l'ipRange dell'interfaccia più il peerIpAddress del peer devono descrivere estremità opposte di un unico /30.

Lo scambio avviene di solito durante una ricostruzione

È ricostruendo un tunnel che le coppie si incrociano. L'indirizzo del peer del vecchio tunnel viene copiato nel campo interfaccia del nuovo, oppure la nuova sessione punta al peer della sessione precedente. In entrambi i casi il Cloud Router invia pacchetti OPEN a un indirizzo che ora è se stesso o a un indirizzo senza tunnel dietro.

Scrivete le coppie prima di aprire la console: nome del tunnel, interfaccia, indirizzo del router, indirizzo del peer, ASN del peer. Poi create entrambi i tunnel in un solo passaggio, così il secondo non viene compilato con gli avanzi del primo.

Tre altri motivi per cui una sessione attende

L'ASN del peer è il primo: ogni lato deve essere configurato con l'ASN dell'altro, e una discrepanza raggiunge il peer ma non si stabilisce mai. Il secondo è il firewall del peer stesso, che deve consentire TCP 179 sull'interfaccia del tunnel; una regola IKE o ESP non lo copre. Il terzo è un peer che risponde da un indirizzo sorgente diverso da quello configurato come suo vicino.

Il log del peer è il discriminante. Se il suo riepilogo BGP non elenca alcun vicino per quell'indirizzo, i pacchetti non arrivano e la coppia o il percorso sono sbagliati. Se il vicino resta in Active o Connect, i pacchetti arrivano e i parametri della sessione non concordano.

Verificate nell'ordine in cui viaggiano i pacchetti

Lavorate verso l'esterno: stato del tunnel, poi stato del peer BGP del router, poi il riepilogo BGP del peer, poi le rotte. Se i primi due sono sani, smettete di modificare il lato Cloud VPN e lavorate sul dispositivo peer. Se il router segnala il peer come abbassato e il vostro dispositivo non ha alcun vicino, la coppia è sbagliata oppure la porta BGP è filtrata. Una cattura di pacchetti sull'interfaccia del tunnel del peer lo risolve con uno sguardo, perché i pacchetti OPEN o arrivano lì o non arrivano mai.

gcloud compute routers get-status ROUTER --region=REGION stampa lo stato del peer accanto all'indirizzo che sta usando, cioè esattamente la coppia che dovete confrontare.

Una volta stabilita la sessione, confermate che il prefisso appreso compaia nella tabella delle rotte della VPC e che un host per lato risponda. Poi annotate le coppie definitive accanto ai nomi dei tunnel, così la prossima ricostruzione parte da una tabella affidabile invece che dal riepilogo della console.