Unha VPN na nube necesita BGP: por que fallan os demais protocolos de enrutamento

A asociación de seguridade IPsec está activa, os contadores do túnel móvense e o tráfico cara ao prefixo da nube desaparece. O operador intenta entón habilitar OSPF no router do cliente, esperando que se forme o veciño, e non ocorre nada. O túnel nunca foi a peza que faltaba: unha VPN na nube xestionada expón un contrato de enrutamento definido, e nas plataformas grandes ese contrato é BGP. Até que exista unha sesión e se acepte un prefixo, o túnel é só un camiño cifrado sen destinos detrás.

O túnel está activo e falta a ruta

Completar a fase 1 e a fase 2 demostra que os pares coinciden na protección, non que algún saiba onde enviar o tráfico. Son máquinas de estado separadas con modos de fallo separados.

Formule tres preguntas en orde: anunciouse o prefixo, aceptouno o par e instalouse para o reenvío? Un prefixo anunciado e filtrado é un problema de política. Un prefixo que nunca se anunciou é un problema de sesión ou de configuración. Un prefixo aceptado pero non instalado é un problema de selección de ruta, e cada resposta apunta a unha parte distinta da configuración.

Que lle entrega realmente o provedor

Unha pasarela VPN xestionada non é un router sen restricións. O provedor entrégalle unha pasarela con enderezos de par admitidos, un axuste de sistema autónomo, límites de prefixos e un comportamento de fallo definido. Esa superficie é o produto.

Google Cloud documenta o enrutamento dinámico BGP para HA VPN, con Cloud Router aprendendo as rutas dos pares e subministrando rutas dinámicas personalizadas elixibles á VPC. AWS Site-to-Site VPN documenta unha escolla entre enrutamento estático e dinámico, e describe as comprobacións de vitalidade BGP como útiles para a conmutación por erro do túnel, á vez que admite comprobacións de estado para dispositivos sen BGP. O comportamento de ningunha plataforma debe inferirse do nome de produto da outra.

A consecuencia práctica é que primeiro se escolle o modo xestionado e despois se len os parámetros admitidos. Un deseño que supón un tipo de adxacencia que o servizo non ofrece non é un problema de configuración que se resolva no router do cliente.

A protección do túnel e a alcanzabilidade son tarefas separadas

IPsec protexe o tráfico seleccionado para o túnel. BGP achega a información de alcanzabilidade que fai elixible un prefixo. Un túnel que funciona non demostra que o prefixo esperado se anunciase, aceptase ou instalase.

Imagine unha sucursal que anuncia 10.42.0.0/16 por dous camiños de túnel elixibles. Retire un camiño utilizable e a elección de ruta pode cambiar sen que ninguén edite a ruta de cada carga de traballo. A detección, a selección de ruta e a recuperación da aplicación non son instantáneas e non son idénticas entre despregamentos, así que a proba de conmutación debe observar toda a secuencia e non o primeiro paquete que pasa.

Cando un prefixo da nube non é alcanzable, revise o estado da sesión e as rutas aprendidas antes de tocar a criptografía. Unha SA activa sen ningunha ruta detrás é a forma máis común deste síntoma.

Onde se rompen as suposicións sobre OSPF

OSPF, IS-IS ou outro protocolo dentro dun túnel IPsec é totalmente posible nun dispositivo autoxestionado, onde vostede posúe ambos os extremos e o deseño de reenvío. Ese feito non di nada sobre un servizo xestionado que só ofrece BGP como modo de enrutamento dinámico.

Se un deseño proposto necesita unha adxacencia que o servizo non admite, cambie a arquitectura de forma deliberada. As opcións inclúen un dispositivo autoxestionado na VPC, enrutamento estático onde o servizo o admita, ou un produto de conectividade distinto. Configurar o protocolo só no router do cliente non pode engadir un par do lado da nube que non existe, e non fará aparecer o prefixo.

Non traslade a resposta dun provedor á pasarela doutro. As mesmas palabras, como enrutamento dinámico ou conmutación por erro do túnel, poden describir mecanismos e límites distintos.

Lea o requisito do servizo e despois deseñe

Antes da primeira liña de configuración, anote os enderezos dos veciños, os números de sistema autónomo, os prefixos que anunciará e aceptará, os límites de rutas e o comportamento esperado cando falla un túnel. Eses cinco elementos son o contrato co que deseña.

Despois verifique na mesma orde: sesión establecida, prefixo recibido, ruta presente na táboa de rutas da VPC e un fluxo real cara a un enderezo de servizo. Repita tras unha conmutación forzada, porque unha sesión que se restablece pode volver cun conxunto de rutas distinto. Se o deseño depende dunha converxencia inferior ao segundo, mídaa en lugar de supoñela.

Conserve o contrato do servizo xunto co rexistro de cambios. Cando alguén pregunte máis adiante por que o túnel non pode executar OSPF, a resposta é unha fronteira de produto, non unha limitación do protocolo, e o rexistro debería dicilo.