GCP HA VPN: la sessió BGP es queda a Waiting for peer, l'intercanvi del parell d'adreces

Una sessió BGP que no arriba mai a Established en un túnel Cloud VPN normalment no és un problema d'encaminament. És un problema de cablejat: dues adreces que s'han de reflectir mútuament es van introduir en l'ordre equivocat, o el parell del primer túnel es va reutilitzar al segon. El túnel mateix pot estar perfectament sa mentre la sessió resta a Waiting for peer, perquè IPsec i BGP són negociacions separades entre els mateixos dos extrems. Decidiu quin dels dos està trencat abans de reconstruir res.

Una pregunta resol la majoria de casos: el dispositiu parell veu l'adreça del Cloud Router?

L'estat del túnel i l'estat de la sessió són comprovacions diferents

IKE i ESP van primer. Si el túnel no està establert, res del seu interior no importa i la conversa sobre l'adreça BGP és prematura. Llegiu l'estat i l'estat detallat del túnel, i després l'estat del parell BGP de l'encaminador per a aquest mateix túnel.

Un túnel actiu mentre el seu parell BGP està caigut redueix la fallada a la sessió: adreça del parell, ASN o TCP 179 arribant a l'adreça interna. Un túnel actiu, una sessió activa i encara cap ruta a la VPC és un tercer cas. Canviar les adreces no hi ajudarà, perquè la sessió ja funciona i el prefix simplement no s'anuncia o no es prefereix. Mantenir aquests tres casos separats és la major part de la feina.

Cada túnel necessita la seva pròpia /30, amb tots dos extrems omplerts

Cada túnel HA VPN rep una /30 link-local de 169.254.0.0/16, amb una adreça a la interfície del Cloud Router i l'altra al vostre parell. El camp del parell ha de nomenar l'extrem remot, mai l'adreça del mateix encaminador.

Dos túnels volen dir dues interfícies al Cloud Router, cadascuna amb una /30 diferent. Reutilitzar el parell del túnel 0 al túnel 1 és l'error que sembla endreçat en una taula resum i mor al paquet OPEN.

Llegiu el parell des del recurs de l'encaminador i no des del resum de la consola. El resum llista l'adreça del parell en una columna fàcil de llegir malament, i l'ipRange de la interfície més el peerIpAddress del parell han de descriure extrems oposats d'una mateixa /30.

L'intercanvi sol passar durant una reconstrucció

És en reconstruir un túnel que els parells es creuen. L'adreça del parell del túnel antic es copia al camp d'interfície del nou, o la nova sessió apunta al parell de la sessió anterior. En tots dos casos el Cloud Router envia paquets OPEN a una adreça que ara és ell mateix o a una adreça sense túnel al darrere.

Anoteu els parells abans d'obrir la consola: nom del túnel, interfície, adreça de l'encaminador, adreça del parell, ASN del parell. Després creeu tots dos túnels en una sola passada, perquè el segon no s'ompli amb les restes del primer.

Tres raons més per les quals una sessió espera

L'ASN del parell és la primera: cada costat s'ha de configurar amb l'ASN de l'altre, i una discrepància arriba al parell però no s'estableix mai. La segona és el tallafoc del mateix parell, que ha de permetre TCP 179 a la interfície del túnel; una regla IKE o ESP no ho cobreix. La tercera és un parell que respon des d'una adreça d'origen diferent de la configurada com a veí seu.

El registre del mateix parell és el discriminant. Si el seu resum BGP no llista cap veí per a aquesta adreça, els paquets no arriben i el parell o el camí són incorrectes. Si el veí està en Active o Connect, els paquets arriben i els paràmetres de la sessió no concorden.

Verifiqueu en l'ordre en què viatgen els paquets

Treballeu cap enfora: estat del túnel, després estat del parell BGP de l'encaminador, després el resum BGP del parell i després les rutes. Si els dos primers són sans, deixeu d'editar el costat Cloud VPN i treballeu al dispositiu parell. Si l'encaminador informa que el parell està caigut i el vostre dispositiu no té cap veí, el parell és incorrecte o el port BGP està filtrat. Una captura de paquets a la interfície del túnel del parell ho resol d'un cop d'ull, perquè els paquets OPEN o hi arriben o no hi arriben mai.

gcloud compute routers get-status ROUTER --region=REGION imprimeix l'estat del parell al costat de l'adreça que utilitza, que és exactament el parell que cal comparar.

Quan la sessió s'estableixi, confirmeu que el prefix après apareix a la taula de rutes de la VPC i que un amfitrió de cada costat respon. Després anoteu els parells definitius al costat dels noms dels túnels, perquè la propera reconstrucció comenci des d'una taula fiable i no des del resum de la consola.