Cómo resolver las diferencias entre ADVPN 2.0 y ADVPN 1.0 en Fortinet

En este artículo, abordaremos las limitaciones del ADVPN 1.0 y cómo el rediseño en ADVPN 2.0 ofrece una solución más eficiente y simplificada. Este problema es relevante porque la gestión ineficaz de las redes puede ocasionar fallos en la comunicación y un rendimiento subóptimo. Aprenderemos a implementar configuraciones que maximicen la usabilidad y la estabilidad de los túneles VPN, asegurando una mejor experiencia en la red.

Descripción del problema

El ADVPN 1.0 presenta complicaciones al gestionar múltiples conexiones entre varios clientes y el Hub. En la topología anterior, el Hub y los Spokes usaban dos enlaces de Internet, lo que complicaba el establecimiento de túneles eficientes. Cuando uno de los enlaces presentaba latencia alta, los Spokes no lo detectaban adecuadamente, lo que resultaba en intentos erróneos de establecer túneles directos, ocasionando lentitud y pérdida de eficiencia.

Alcance

Este artículo es aplicable a FortiGate versiones 7.2 y superiores.

Diagnóstico paso a paso

Para entender la robustez de ADVPN 2.0, es esencial conocer la estructura del ADVPN 1.0. El Hub alojaba las redes anunciadas por los Spokes y establecía túneles bajo demanda cuando había tráfico entre redes LAN. Sin embargo, cuando había problemas en los enlaces, como en el caso de ISP1 de Spoke2, el Spoke1 no detectaba estos problemas y continuaba con conexiones subóptimas.

Solución recomendada

La solución al problema radica en la implementación de varias configuraciones que optimizan la funcionalidad de ADVPN:

• Preferencia de Superposición de Ramas:
  • La rama receptora anuncia su superposición preferida para la comunicación.
  • La rama que envía respeta esta preferencia siempre que sea posible.
• Publicidad Condicionada de Preferencia de Superposición:
  • La rama receptora solo anuncia su superposición preferida si la superposición correspondiente cumple los requisitos de SLA.
  • Si no se cumplen los SLA, se anuncia una superposición secundaria como alternativa.
• Decisión de Sobrescritura de Rama que Envía:
  • La rama que envía respeta la preferencia de superposición de la rama remota si la superposición local también cumple los criterios de SLA.
  • Si la superposición local no cumple, se elige una superposición alternativa.

El protocolo BGP se utiliza para soportar este diseño, mediante mecanismos complejos como la publicidad de comunidades y etiquetas.

Comandos CLI utilizados

A continuación, se presentan los comandos CLI relevantes para configurar ADVPN 2.0:

config router bgp
    set as 
    config neighbor
        edit 
        set remote-as 
        next
    end
end

Buenas prácticas y recomendaciones

Con el diseño de ADVPN 2.0, los Spokes pueden ahora compartir información sobre la salud de los enlaces. Gracias a esto, un Spoke puede seleccionar el camino óptimo y establecer el túnel directo considerando la salud local del enlace. Las configuraciones iniciales son sencillas, con cada Spoke enviando sondeos SLA a la interfaz loopback del Hub. Durante la negociación del túnel directo, la respuesta del túnel directo incluye esta información sobre la salud.

Notas adicionales

Es significativo tener en cuenta que ADVPN 1.0 soporta FortiOS hasta la versión 7.2 y funciona tanto para IKEv1 como IKEv2, mientras que la versión 2.0 comienza desde FortiOS 7.2 en adelante y solo soporta IKEv2. La versión 1.0 no proporciona soporte para túneles cruzados, a diferencia de la versión 2.0, que sí lo hace, promoviendo una mejor integración con SD-WAN.