¿Rutas estáticas o un protocolo de enrutamiento sobre una VPN de sitio a sitio?

Ambas opciones transportan paquetes entre sitios, así que la decisión no va de qué protocolo es más nuevo, y el tamaño del túnel tampoco la resuelve. La resuelven tres condiciones: cuántos prefijos cambian y con qué frecuencia, si el diseño necesita conmutación automática entre rutas, y cuánta maquinaria de plano de control puede operar el equipo a las tres de la madrugada. Responda con sinceridad y la elección suele hacerse sola. El resto de este artículo es lo que cuesta cada respuesta.

Tres condiciones lo deciden

La primera condición es la volatilidad. Un puñado de subredes estables con una propiedad clara puede mantenerse a mano durante años, y cada ruta sigue siendo una línea que alguien puede leer y comprobar. Decenas de prefijos que se mueven según llegan y se van los proyectos son otro problema, porque cada movimiento tiene que llegar a cada dispositivo que aún recuerda la ruta antigua.

La segunda es el comportamiento ante fallos. Cuando una ruta de respaldo debe activarse sin que nadie lo note, algo tiene que detectar el fallo y retirar la ruta. El enrutamiento estático solo puede hacerlo mediante seguimiento o instalación condicional, y solo para los fallos que haya previsto.

La tercera es el apetito por un segundo plano de control. Un protocolo de enrutamiento añade sesiones, autenticación, filtros y política de selección, y cada uno de esos elementos necesita monitorización y un proceso de cambio. Es un coste operativo permanente, no una tarea de configuración puntual.

La tabla bajo el tercer párrafo es la versión corta, y las tres secciones que la siguen explican por qué cada fila está donde está. Lea las filas contra su propio recuento de sitios antes de elegir, porque una decisión que ignora el coste operativo es solo media decisión.

Lo que cuesta de verdad el enrutamiento estático

Una ruta estática tiene que ser correcta en ambos lados del túnel. Añadir una subred implica editar la puerta de enlace remota, la local y normalmente el camino de vuelta, y olvidar cualquiera de ellas produce un fallo unidireccional que parece un error de la aplicación. El equipo de aplicaciones ve tiempos de espera mientras el de red ve una ruta que está presente y aparentemente sana. Ninguno de los dos se equivoca, y por eso este fallo tarda tanto en ubicarse.

Una entrada estática también sigue instalada después de que desaparezca el camino que tiene debajo. Salvo que la plataforma proporcione seguimiento, la ruta sigue apuntando a un siguiente salto que ya no reenvía, y el tráfico desaparece en lugar de conmutar. Ese silencio es el gasto que acepta al elegir la opción simple.

Escriba el método de seguimiento junto a cada ruta, anote qué fallos cubre y guarde la lista con la configuración del túnel. De lo contrario, la próxima interrupción la descubre un usuario y no la red, que siempre es el descubrimiento más caro.

Lo que cuesta de verdad el enrutamiento dinámico

Un protocolo anuncia prefijos nuevos, retira los inalcanzables y expresa preferencia entre rutas. Eso es realmente útil cuando varios sitios o túneles redundantes necesitarían de otro modo ediciones coordinadas en cada cambio. También es la razón por la que el protocolo puede sorprenderle en el peor momento. Cada una de esas acciones es un cambio de estado que usted no hizo personalmente.

Crea dos estados que pueden discrepar. El túnel puede estar arriba mientras la sesión de enrutamiento está abajo, y la sesión puede estar arriba mientras sus anuncios omiten la subred que necesita la aplicación. Ambos parecen una red que funciona a medias, y ninguno es visible desde una página de estado del túnel.

Por eso los filtros y la política pasan a formar parte del diseño en vez de ser un añadido. Un protocolo que anuncia todo acabará anunciando algo incorrecto, y el prefijo incorrecto viaja más rápido que la persona que puede corregirlo. Escriba los filtros antes de habilitar la primera sesión, para que el primer anuncio ya sea deliberado.

Controle qué puede decir la sesión de enrutamiento

Decida la lista de prefijos permitidos por par y aplíquela en la entrada, porque un filtro de salida no puede impedir que un par le envíe una ruta por defecto. Las rutas por defecto y los agregados son los errores caros aquí: pueden sustituir en silencio rutas no relacionadas por una sola entrada aprendida que parece legítima. Recházelos de forma explícita salvo que el diseño los quiera de verdad.

Escriba el sitio propietario junto a cada red antes de que suba la primera sesión, porque ese mapeo es la fuente de la lista de filtros y no un adorno de documentación. Sin él, quien edita un filtro tiene que adivinar qué sitio debería anunciar el prefijo.

La redistribución entre dos protocolos es donde empiezan los bucles y donde el mismo prefijo llega dos veces con atributos que no se comparan limpiamente. Mantenga la redistribución fuera del diseño hasta que un requisito concreto la obligue, y si tiene que existir, marque y filtre las rutas en la frontera.

Las interfaces de túnel basadas en rutas facilitan representar el enrutamiento dinámico, porque el túnel pasa a ser una interfaz con rutas en lugar de una política que casa selectores. Eso no elimina la cuestión del alcance del par: los selectores de IPsec todavía tienen que permitir el tráfico que pretende enrutar.

Pruebe el camino del fallo, no el camino feliz

Elija lo que elija, baje un enlace ascendente y confirme que el tráfico se mueve, o que falla tal como lo documentó. Un diseño probado solo con ambos caminos sanos es un diseño que no se ha probado en absoluto. Mida la detección mientras está allí, porque el número que midió es el número que vivirán los usuarios.

Después confirme el camino de vuelta de forma independiente, porque el enrutamiento asimétrico sobre una VPN es habitual e invisible hasta que un dispositivo con estado descarta las respuestas. Un flujo que funciona en una dirección solo demuestra la mitad del camino.

Orden de trabajo: cuente los prefijos, decida cómo deben detectarse los fallos, compruebe quién puede operar el protocolo, controle qué se anuncia y luego pruebe una interrupción de extremo a extremo. Cada paso produce un hecho que el siguiente necesita.