WireGuard, IPsec y SD-WAN no están en el mismo nivel. WireGuard e IPsec protegen el tráfico dentro de túneles. SD-WAN describe un servicio gestionado de conexión entre sedes sobre una o varias conexiones subyacentes; el cifrado puede utilizar distintas tecnologías. Para varias sedes, la elección empieza por aplicaciones, líneas, responsabilidades y escenarios de fallo, antes que por el nombre de un producto.
Una empresa ficticia tiene una central y tres delegaciones. ERP y telefonía utilizan servicios centrales, Microsoft 365 accede a internet de la forma más directa posible y una empresa de mantenimiento solo necesita un acceso de servicio limitado. El artículo DAXS sobre mantenimiento de OPNsense trata el proceso de actualización de un cortafuegos; aquí se analiza la topología de las sedes y su decisión operativa. Una segunda conexión a internet en cada sede es un asunto independiente que el mero nombre SD-WAN no resuelve.
Cuatro comprobaciones antes de elegir un protocolo
Primero se registran por sede aplicaciones, redes de destino, picos de carga medidos, requisitos de latencia, accesibilidad pública y fallos de línea. Los rangos de direcciones privadas solapados complican el enrutamiento y los permisos independientemente del protocolo de túnel. Después se define si las delegaciones solo se comunican con la central o también directamente entre sí; hub-and-spoke necesita menos relaciones de túnel, pero puede convertir la central en un cuello de botella. Por último se asignan operación, mantenimiento de claves, monitorización y una ruta de recuperación probada.
| Enfoque | Encaja cuando… | Comprobaciones y límites |
|---|---|---|
| WireGuard | Pocos pares y redes claramente definidos permiten un mantenimiento de claves manejable | Probar en la práctica AllowedIPs, rutas, reglas de cortafuegos, NAT y accesibilidad de cada par; el protocolo no aporta automáticamente operación centralizada |
| IPsec con IKEv2 | Los equipos o pares existentes necesitan túneles IPsec estandarizados | Validar perfiles entre fabricantes, certificados, renovación de claves, NAT-T y conmutación en el par concreto de equipos |
| Servicio SD-WAN | Varias líneas, muchas sedes o rutas por aplicación deben controlarse y mantenerse centralmente | Revisar técnica y contractualmente underlay, equipos edge, políticas, puntos de medida, acceso de gestión, SLA y ruta de fallo |
Una red pequeña puede funcionar muy bien con WireGuard o IPsec si alguien se responsabiliza de la configuración y las incidencias. Una oferta SD-WAN puede agrupar este trabajo operativo y controlar las rutas, pero genera costes propios de plataforma, licencias, soporte y dependencias. Una disponibilidad mejor depende de líneas realmente independientes y de una conmutación probada.
WireGuard: pares claros, redes claras
WireGuard asocia claves públicas a rangos IP permitidos. En una conexión entre sedes, esos rangos deben coincidir con la tabla de enrutamiento y las reglas del cortafuegos; un handshake correcto no demuestra aún que ERP o telefonía sean accesibles. Puede hacer falta un keepalive cuando un par está detrás de NAT. La documentación de OPNsense muestra comprobaciones concretas de pares, rutas y cortafuegos para dos sedes, además de posibles problemas MTU/MSS. Con cuatro sedes aumentan la configuración y el mantenimiento de claves, especialmente si se desean rutas directas entre delegaciones. WireGuard por sí solo no añade gestión automática de políticas, monitorización del servicio ni SLA.
IPsec/IKEv2: la estandarización necesita validación
IPsec protege paquetes en la capa de red; IKEv2 negocia asociaciones de seguridad y claves. Puede tener sentido con cortafuegos heterogéneos o requisitos existentes de socios. La compatibilidad exige comprobación: suites criptográficas, certificados, selectores de red, renovación de claves y NAT traversal deben coincidir en ambos extremos. RFC 7296 describe, por ejemplo, la encapsulación UDP de IPsec con NAT. Por ello el piloto comprueba establecimiento del túnel, funcionamiento prolongado, cambios de claves y recuperación tras una interrupción de línea. Un ping correcto tampoco equivale aquí a una aceptación funcional.
SD-WAN: separar overlay, underlay y contrato
MEF 70.2 define SD-WAN como servicio con atributos acordados y lo distingue expresamente de los servicios de conectividad subyacentes. En el ejemplo, requisitos posibles serían «ERP por la ruta A y por B al detectar un fallo» o «telefonía solo con latencia adecuada»; su disponibilidad concreta depende del producto del proveedor, las mediciones y las prestaciones contratadas. Si una delegación solo tiene un acceso físico a internet, el control central no puede eliminar su fallo mediante configuración. Una segunda línea también ayuda poco si ambas comparten trazado, alimentación o equipo edge.
Por eso la oferta se evalúa por separado en hardware edge, ubicación de gestión, líneas, política central, límites de seguridad, registros, mantenimiento de firmware, horarios de soporte, recorrido de datos y escenario de salida. «Gestionado» solo supone una ventaja si están definidos escalado, datos de medida y responsabilidad ante incidencias.
Una prueba de fallo dice más que una ficha técnica
La central y una delegación prueban juntas cuatro casos: pérdida de la ruta principal, fallo del equipo edge, clave o certificado inválido y una aplicación que no funciona pese a tener un túnel activo. Se miden detección, conmutación, reconexión, efecto en la aplicación y restauración de la ruta normal. ERP y telefonía pueden admitir interrupciones distintas. El acta indica tiempos reales en lugar de prometer alta disponibilidad de forma general.
La decisión económica incluye equipos y repuestos, configuración de túneles y políticas, precios de líneas, redundancia adicional real, licencias o cuotas, monitorización y esfuerzo de guardia interno. Un túnel WireGuard propio quizá no tenga licencia de protocolo separada, pero sigue teniendo costes de operación y conexión. Un túnel IPsec en equipos existentes puede parecer barato si se cuentan mantenimiento y validación del fabricante. Un servicio SD-WAN puede reducir trabajo en muchas sedes, pero debe compararse con el mismo alcance de prestaciones. Sin mediciones y ofertas, una clasificación en euros sería inventada.
DAXS puede convertir con la empresa las cuatro sedes, aplicaciones y escenarios de fallo en una topología lista para la aceptación y comparar opciones operativas adecuadas. El punto de partida de una conversación con DAXS es el plano de red de las sedes, los contratos de las líneas y el historial previo de incidencias.
Fuentes: WireGuard: Quick Start; OPNsense: WireGuard Site-to-Site; IETF RFC 7296: IKEv2; Mplify/MEF 70.2: SD-WAN Service Attributes.
