La VPN al núvol necessita BGP: per què fallen els altres protocols d'encaminament

L'associació de seguretat IPsec està activa, els comptadors del túnel es mouen i el trànsit cap al prefix del núvol desapareix. L'operador aleshores intenta habilitar OSPF al router del client, esperant que el veí es formi, i no passa res. El túnel no era mai la peça que faltava: una VPN al núvol gestionada exposa un contracte d'encaminament definit, i a les plataformes grans aquest contracte és BGP. Fins que no existeixi una sessió i s'accepti un prefix, el túnel només és un camí xifrat sense destinacions al darrere.

El túnel està actiu i la ruta falta

Completar la fase 1 i la fase 2 demostra que els parells coincideixen en la protecció, no que cap dels dos sàpiga on enviar el trànsit. Són màquines d'estat separades amb modes de fallada separats.

Feu tres preguntes en ordre: es va anunciar el prefix, el va acceptar el parell i es va instal·lar per a l'encaminament? Un prefix anunciat i filtrat és un problema de política. Un prefix que mai no s'ha anunciat és un problema de sessió o de configuració. Un prefix acceptat però no instal·lat és un problema de selecció de ruta, i cada resposta apunta a una part diferent de la configuració.

Què us dona realment el proveïdor

Una passarel·la VPN gestionada no és un encaminador sense restriccions. El proveïdor us dona una passarel·la amb adreces de parell admeses, un paràmetre de sistema autònom, límits de prefix i un comportament de fallada definit. Aquesta superfície és el producte.

Google Cloud documenta l'encaminament dinàmic BGP per a HA VPN, amb Cloud Router aprenent les rutes dels parells i subministrant rutes dinàmiques personalitzades elegibles a la VPC. AWS Site-to-Site VPN documenta una tria entre encaminament estàtic i dinàmic, i descriu les comprovacions de vitalitat BGP com a útils per al basculament del túnel, alhora que admet comprovacions de salut per a dispositius sense BGP. El comportament de cap plataforma no s'ha d'inferir del nom del producte de l'altra.

La conseqüència pràctica és que primer trieu el mode gestionat i després llegiu els paràmetres admesos. Un disseny que pressuposa un tipus d'adjacència que el servei no ofereix no és un problema de configuració a resoldre al router del client.

La protecció del túnel i l'abastabilitat són feines separades

IPsec protegeix el trànsit seleccionat per al túnel. BGP proporciona la informació d'abastabilitat que fa elegible un prefix. Un túnel que funciona no demostra que el prefix esperat s'hagi anunciat, acceptat o instal·lat.

Imagineu una sucursal que anuncia 10.42.0.0/16 per dos camins de túnel elegibles. Traieu un camí utilitzable i la tria de ruta pot canviar sense que ningú editi la ruta de cada càrrega de treball. La detecció, la selecció de ruta i la recuperació de l'aplicació no són instantànies, i no són idèntiques entre desplegaments, així que la prova de basculament ha d'observar tota la seqüència i no el primer paquet que passa.

Quan un prefix del núvol no és abastable, comproveu l'estat de la sessió i les rutes apreses abans de tocar la criptografia. Una SA activa sense cap ruta al darrere és la forma més comuna d'aquest símptoma.

On es trenquen les suposicions sobre OSPF

OSPF, IS-IS o un altre protocol dins d'un túnel IPsec és del tot possible en un aparell autogestionat, on posseïu els dos extrems i el disseny d'encaminament. Aquest fet no diu res sobre un servei gestionat que només ofereix BGP com a mode d'encaminament dinàmic.

Si un disseny proposat necessita una adjacència que el servei no admet, canvieu l'arquitectura deliberadament. Les opcions inclouen un aparell autogestionat a la VPC, encaminament estàtic on el servei l'admet, o un producte de connectivitat diferent. Configurar el protocol només al router del client no pot afegir un parell del costat del núvol que no existeix, i no farà aparèixer el prefix.

No porteu la resposta d'un proveïdor a la passarel·la d'un altre. Les mateixes paraules, com encaminament dinàmic o basculament del túnel, poden descriure mecanismes i límits diferents.

Llegiu el requisit del servei i després dissenyeu

Abans de la primera línia de configuració, anoteu les adreces dels veïns, els números de sistema autònom, els prefixos que anunciareu i acceptareu, els límits de rutes i el comportament esperat quan falli un túnel. Aquests cinc elements són el contracte contra el qual dissenyeu.

Després verifiqueu en el mateix ordre: sessió establerta, prefix rebut, ruta present a la taula de rutes de la VPC i un flux real cap a una adreça de servei. Repetiu-ho després d'un basculament forçat, perquè una sessió que es restableix pot tornar amb un conjunt de rutes diferent. Si el disseny depèn d'una convergència inferior al segon, mesureu-la en lloc de suposar-la.

Manteniu el contracte del servei amb el registre de canvis. Quan algú pregunti més endavant per què el túnel no pot executar OSPF, la resposta és una frontera de producte, no una limitació del protocol, i el registre ho hauria de dir.