Enrutamiento Unificado en la Nube: Construcción de una superposición de ingreso multi-nube con WireGuard de unicast a anycast

Las implementaciones multi-nube modernas enfrentan un paradoja frustrante. La misma decisión arquitectónica que aumenta la resiliencia — distribuir cargas de trabajo en AWS, GCP y Azure — también fragmenta tu red en tres esquemas de direccionamiento privado incompatibles, tres dominios de enrutamiento y tres conjuntos de herramientas de tránsito específicas de cada nube. La respuesta predeterminada de cada proveedor (Direct Connect, ExpressRoute, Cloud Interconnect) es costosa, rígida y profundiza el bloqueo que intentabas evitar.

Una mejor arquitectura trata Internet público como una rampa simple y utiliza un borde BGP Anycast combinado con una malla de superposición WireGuard automatizada como la columna vertebral privada que conecta las tres nubes en una red plana y enrutable. Este artículo explica cómo funciona esa arquitectura en la práctica — la mecánica de enrutamiento, la capa de orquestación dinámica, las trampas de MTU y enrutamiento asimétrico, y el endurecimiento de seguridad necesario antes de exponer una IP globalmente alcanzable que túnel directamente en toda tu huella multi-nube.

---

El Modelo de Dos Niveles

La arquitectura se divide claramente en un nivel público y uno privado.

Nivel 1: BGP Anycast en el Borde

Anycast es un esquema de direccionamiento de red en el que un solo prefijo IP se anuncia simultáneamente desde múltiples ubicaciones físicas. Cuando un cliente envía un paquete a esa IP, el proceso de selección de ruta BGP que corre en Internet — principalmente la menor longitud del AS-path — enruta el paquete al Punto de Presencia (PoP) más cercano topológicamente a ese cliente.

              [ Cliente Global ]
                     |
         ( Internet / enrutamiento BGP )
                     |
      +--------------+--------------+
      |  Prefijo Anycast (misma IP)   |
      v                             v
+------------------+       +------------------+
| PoP 1 – Europa   |       | PoP 2 – US-East  |
| Proxy en el borde / |     | Proxy en el borde / |
| Nodo WireGuard     |     | Nodo WireGuard     |
+------------------+       +------------------+

El resultado es una coincidencia geográfica sin manipulación DNS: un cliente en Frankfurt llega al PoP europeo, un cliente en Virginia llega a US-East, y ninguno necesita saber qué PoP usar. El tráfico entra en la red controlada por el proveedor en la primera oportunidad, minimizando la exposición a rutas impredecibles de Internet público antes de llegar a tu infraestructura.

El Anycast ya es la columna vertebral de la infraestructura de Internet a gran escala. Los resolutores DNS como Cloudflare’s 1.1.1.1 y Google’s 8.8.8.8 dependen exactamente de este mecanismo para servir miles de millones de consultas globales con direccionamiento geográfico en menos de un milisegundo.

Nivel 2: La Malla de Superposición WireGuard

Una vez que un paquete llega a un nodo de borde Anycast, abandona completamente Internet público. El nodo de borde debe reenviar ese paquete al servicio backend correcto — que puede estar en AWS us-east-1, GCP asia-southeast1 o Azure West US — sin volver a Internet público ni pagar por circuitos de interconexión propietarios.

Aquí es donde la malla de superposición WireGuard toma el control. Cada nodo de borde y cada nodo backend en las tres nubes participa en una malla encriptada UDP. El tráfico se encapsula en un túnel WireGuard y se entrega directamente a través de la malla a la IP unicast objetivo dentro de la VPC correspondiente.

Las tres redes en la nube dejan de ser dominios separados. Desde la perspectiva del demonio de enrutamiento que corre en cada nodo, toda la huella multi-nube es una red privada plana y alcanzable a través de interfaces encriptadas WireGuard.

---

WireGuard: Rendimiento Nativo en Kernel, Criptografía Fija

WireGuard fue integrado en la línea principal del kernel Linux en la versión 5.6, lanzada en marzo de 2020, y ha sido incluido como módulo incorporado en todos los kernels Linux desde entonces. Para implementaciones en kernels antiguos o plataformas no Linux, existen implementaciones en espacio usuario como wireguard-go, así como planos de datos basados en eBPF que acercan el camino crítico al kernel.

El conjunto criptográfico del protocolo está intencionadamente fijo en lugar de negociable, eliminando la clase de ataques de degradación que afectan a protocolos con cifrado configurable como IPsec:

• Curve25519 para intercambio de claves Diffie-Hellman de curva elíptica
• ChaCha20-Poly1305 (RFC 7539) para cifrado autenticado de paquetes de datos
• BLAKE2s para hashing y hashing con clave
• SipHash24 para claves de tablas hash
• HKDF para derivación de claves

Toda la implementación del protocolo ocupa aproximadamente 4,000 líneas de código — un contraste deliberado con las más de 100,000 líneas de OpenVPN — lo que la hace auditable por equipos pequeños. Un análisis formal usando el cálculo de CryptoVerif ha verificado autenticación mutua, secreto de clave de sesión IND-CCA, secreto hacia adelante y seguridad post-compromiso en sesiones paralelas ilimitadas.

WireGuard genera nuevas claves cada 120 segundos (o cada 2⁶⁰ mensajes) para ofrecer secreto hacia adelante perfecto independiente del volumen de tráfico.

---

Cálculo de MTU: Ajustando los Números Correctamente

Esta es la sección donde la mayoría de las implementaciones de WireGuard fallan. WireGuard encapsula cada paquete con una pila de encabezados externos, y si no se cuenta correctamente el overhead, los paquetes sobredimensionados se descartan silenciosamente por las redes de tránsito intermedias, causando congelamientos misteriosos y fallos en el TLS.

Desglose del Overhead Real

Para una implementación de WireGuard en IPv4, la envoltura externa añade:

Capa	Tamaño
Encabezado IPv4 externo	20 bytes
Encabezado UDP	8 bytes
Encabezado de mensaje WireGuard (tipo, índice de clave, nonce)	32 bytes
Etiqueta de autenticación Poly1305	16 bytes
Overhead total	76 bytes

Para transporte IPv6, el encabezado IPv6 externo es de 40 bytes en lugar de 20, llevando el total a 96 bytes.

Dado un MTU Ethernet estándar de 1500 bytes, el MTU seguro para la interfaz WireGuard es:

• Transporte IPv4: 1500 − 76 = 1424 bytes (el valor práctico predeterminado de WireGuard se redondea a 1420 para margen de compatibilidad)
• Transporte IPv6: 1500 − 96 = 1404 bytes (normalmente redondeado a 1400)

El MTU predeterminado de WireGuard de 1420 se elige para funcionar de manera segura en IPv4 e IPv6 sobre una ruta Ethernet estándar de 1500 bytes.

Clamping de MSS en TCP

Para tráfico TCP, el proxy en el borde debe reescribir el campo Maximum Segment Size en los paquetes SYN de TCP para coincidir con el MTU reducido. Dentro de un túnel WireGuard con un MTU de interfaz de 1420, los valores MSS seguros son:

• TCP IPv4 dentro del túnel: 1420 − 20 (IP interno) − 20 (TCP) = 1380 bytes
• TCP IPv6 dentro del túnel: 1420 − 40 (IP interno) − 20 (TCP) = 1360 bytes

La regla iptables para hacer cumplir esto en la interfaz WireGuard es:

# Limitar MSS para TCP IPv4 transitando la interfaz wg0
iptables -t mangle -A FORWARD -i wg0 -p tcp \
  --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

# O limitar dinámicamente al MTU del camino descubierto
iptables -t mangle -A FORWARD -i wg0 -p tcp \
  --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sin limitar, un cliente que negocie un MSS estándar de 1460 (Ethernet 1500 − 40 bytes de encabezado) genera segmentos que exceden el MTU del túnel. Los paquetes en exceso se descartan silenciosamente, causando fallos intermitentes — transferencias grandes de archivos, SCP fallando mientras SSH funciona, cargas parciales de páginas — que son difíciles de depurar.

ICMP Fragmentation Needed

Para protocolos no TCP (UDP, ICMP, túneles personalizados dentro del túnel), el clamp de MSS no aplica. La Descubrimiento de MTU en ruta (PMTUD) debe funcionar de extremo a extremo, lo que requiere que los paquetes ICMP Tipo 3 Código 4 (“Destino inalcanzable — Fragmentación necesaria”) no sean bloqueados por grupos de seguridad en la nube o firewalls internos. Bloquear estos mensajes ICMP crea un agujero negro en PMTUD: el remitente nunca aprende que el MTU del camino es insuficiente y continúa enviando paquetes demasiado grandes que se descartan silenciosamente.

Muchos grupos de seguridad en la nube bloquean todo ICMP por defecto. Permitir explícitamente ICMP Tipo 3 desde los rangos de interfaz WireGuard es un paso necesario en cualquier implementación en producción.

---

Orquestación Dinámica de Peers

Una malla global de WireGuard en cientos de nodos efímeros en la nube — que se inicia y detiene con eventos de autoscaling en tres proveedores — no puede gestionarse con archivos de configuración estáticos. La capa de orquestación debe automatizar el descubrimiento de peers, la distribución de claves y el ciclo de vida de los túneles sin interrumpir sesiones activas.

Arranque de Nuevos Nodos

Cuando un nuevo nodo se inicia en un grupo de Auto Scaling de AWS o en un clúster GKE, ejecuta una secuencia de arranque antes de aceptar tráfico:

1. El nodo genera un par de claves WireGuard (wg genkey | tee privatekey | wg pubkey e publickey).
2. Registra su clave pública WireGuard y su IP unicast interna en un almacén de configuración distribuido — típicamente etcd o Consul — accesible desde las tres nubes.
3. El demonio de orquestación global detecta el evento de registro (mediante watch de etcd o flujo de eventos de Consul) y actualiza las configuraciones de peers en todos los miembros activos de la malla.
4. Los túneles con el nuevo nodo se establecen automáticamente. Como WireGuard es sin estado a nivel de sesión — no mantiene estado por conexión, solo tablas de enrutamiento criptográficas — agregar peers no requiere reiniciar túneles existentes ni interrumpir conexiones activas.

Herramientas de Orquestación de Código Abierto

Varios proyectos maduros gestionan esta capa de orquestación:

Tailscale envuelve WireGuard con un servidor de coordinación que gestiona descubrimiento de peers, traversal NAT, distribución de claves y la identidad del dispositivo. La capa de datos es WireGuard; la capa de control es propietaria (aunque los clientes son de código abierto). Soporta hasta 100 dispositivos en el nivel gratuito y añade ACLs fáciles de usar e integración SSO.

NetBird (licencia Apache 2.0, ~13,000 estrellas en GitHub a mediados de 2025) es una alternativa auto-hospedada completa a Tailscale. Proporciona toda la pila — servidor de gestión, panel, cliente — y soporta proveedores de identidad OIDC como Keycloak y Azure AD. Para infraestructura multi-nube donde la soberanía de datos o el control local del plano de coordinación son necesarios, NetBird es la opción más común.

Headscale reimplementa el servidor de coordinación de Tailscale para auto-hospedaje, manteniendo compatibilidad con los clientes oficiales de Tailscale. Gestiona la introducción de peers y traversal NAT sin depender del SaaS de Tailscale.

Para equipos que construyen orquestación personalizada, el patrón común es un demonio en Go que observa las APIs de autoscaling del proveedor cloud y el clúster de etcd simultáneamente, generando y distribuyendo comandos wg set a medida que cambia la membresía de la malla.

---

Enrutamiento Interno: iBGP sobre la Malla WireGuard

La capa de orquestación gestiona el descubrimiento de peers y el establecimiento de túneles. Una pregunta separada es: una vez que la malla está activa, ¿cómo decide un nodo de borde Anycast a qué nodo backend enviar un paquete dado, dado que el mismo microservicio puede estar desplegado en múltiples regiones y nubes simultáneamente?

La respuesta es ejecutar un demonio de BGP (iBGP) interno directamente en las interfaces WireGuard, tratándolas como el transporte físico para un protocolo de enrutamiento interno.

+-----------------------------------------------------------------------+
|                       MALLA DE SUPERPOSICIÓN WIREGUARD                |
|                                                                       |
|  +------------------------+          +------------------------+       |
|  | Nodo de borde Anycast  |<========>| Nodo backend AWS     |       |
|  | (BIRD / FRR)           | red WireGuard | (objetivo unicast) |       |
|  +------------------------+          +------------------------+       |
|           ^                                      ^                    |
|           |                                      |                    |
|           v                                      v                    |
|  +------------------------+          +------------------------+       |
|  | Nodo backend GCP      |<========>| Nodo backend Azure  |       |
|  | (objetivo unicast)    | red WireGuard | (objetivo unicast) |       |
|  +------------------------+          +------------------------+       |
+-----------------------------------------------------------------------+

Cada nodo de borde ejecuta un demonio de enrutamiento — BIRD o FRRouting (FRR) son las opciones principales — configurado para hacer pares sobre las IPs de la interfaz WireGuard.

BIRD (BIRD Internet Routing Daemon), mantenido por CZ.NIC Labs, lanzó la versión 3.0 en diciembre de 2024, introduciendo multihilo cooperativo para sesiones BGP a gran escala. A mediados de 2025, la última versión estable es 3.1.x. BIRD se despliega ampliamente como servidor de rutas y reflector en Puntos de Intercambio de Internet, manejando más de un millón de rutas BGP por par en hardware EC2 t3 modestos con aproximadamente 1.3 GB de RAM para cinco millones de rutas.

FRRouting (FRR) es la bifurcación de Quagga que se convirtió en la pila de enrutamiento de código abierto de facto para Linux desde 2017. Ofrece un conjunto completo de enrutamiento (BGP, OSPF, IS-IS, RIP, PIM) y es la mejor opción cuando los nodos de la malla también necesitan participar en topologías de enrutamiento multi-protocolo más complejas.

Anuncio de Rutas y Failover en la Práctica

Cada nodo backend anuncia los prefijos que sirve vía iBGP sobre su interfaz WireGuard. El nodo de borde recopila estos anuncios y construye una tabla de enrutamiento en toda la malla.

Considera un microservicio desplegado en GCP asia-southeast1 y Azure West US. Un nodo de borde en Singapur mide 8 ms de latencia hacia la interfaz WireGuard de la instancia GCP y 140 ms hacia Azure West US. La métrica de iBGP asigna la ruta a GCP como el siguiente salto activo.

Cuando la instancia GCP falla su chequeo de salud (o la interfaz WireGuard se cae y dispara un evento de interfaz caída en el demonio de enrutamiento), la sesión BGP sobre ese túnel se cae. El demonio retira la ruta y se reconverge en segundos, desplazando todo el tráfico al camino de Azure. Sin TTL DNS. Sin estado de sesión pegajosa que invalidar. El failover se propaga a la velocidad de convergencia del protocolo de enrutamiento en toda la malla.

---

El Problema del Enrutamiento Asimétrico

Anycast crea un peligro topológico: los caminos BGP del Internet público no son estables. Congestión transitoria, cambios de ruta en los carriers y ventanas de mantenimiento pueden hacer que dos paquetes consecutivos de un mismo flujo TCP lleguen a nodos de borde Anycast diferentes — uno en Nueva York, otro en Washington D.C.

Si cada nodo de borde mantiene estado de conexión TCP local, el segundo paquete llega a un nodo sin registro de la conexión y se descarta. La sesión TCP se rompe.

Enfoques de Mitigación

Ingreso sin estado o con estado compartido. Los nodos de borde Anycast no deben mantener estado por conexión localmente. Usar un balanceador de carga L4 sin estado (programas XDP basados en eBPF son particularmente eficientes aquí) combinado con una caché de sesiones compartida — Redis Cluster o una tabla hash distribuida accesible desde todos los PoPs — permite que cualquier nodo de borde maneje cualquier paquete de cualquier flujo TCP sin estado local. La estrategia de hashing consistente inspirada en Maglev de Cloudflare implementa esto a escala, donde el hash del 4-tupla (IP origen, IP destino, puerto origen, puerto destino) selecciona un backend de manera determinista en todos los nodos de borde.

Protocolo PROXY v2 para preservación de IP del cliente. Cuando el superposición WireGuard transporta la carga encapsulada al backend unicast, este ve la IP interna de WireGuard del nodo de borde como la fuente. Para preservar la IP original del cliente para registros, limitación de tasa y bloqueo geográfico, el proxy en el borde debe anteponer un encabezado PROXY Protocol v2 al flujo de bytes TCP antes de reenviarlo por el túnel. La aplicación backend debe estar configurada para leer la IP del cliente desde el encabezado PROXY en lugar de la capa de red.

Seguimiento de conexiones vía eBPF. Una alternativa a mantener estado externo compartido es adjuntar programas eBPF XDP a la interfaz de ingreso de cada nodo de borde Anycast que calcule un hash consistente del 4-tupla del flujo y reenvíe paquetes no coincidentes directamente al nodo hermano correcto a través de la malla WireGuard — sin romper la sesión ni involucrar la capa de aplicación.

---

Endurecimiento de Seguridad

Una IP de Anycast expuesta globalmente que conecta directamente en una malla WireGuard que abarca tres entornos en la nube es un objetivo de alto valor. Un nodo de borde comprometido sin controles adicionales podría ofrecer movimiento lateral a toda la subred backend en AWS, GCP y Azure.

Enrutamiento Criptográfico con WireGuard

La propiedad de seguridad fundamental de WireGuard es el enrutamiento criptográfico: cada peer tiene una clave pública estática, y el túnel aplica un mapeo estricto 1:1 entre los prefijos IP internos permitidos de un peer y su clave autenticada. Cualquier paquete que llegue a través de una interfaz WireGuard cuyo IP fuente interno no coincida con la configuración de clave autenticada para ese peer se descarta silenciosamente en el kernel, antes de que se tome una decisión de enrutamiento. No puedes falsificar tu IP de WireGuard sin la clave privada correspondiente.

Microsegmentación con eBPF

El enrutamiento criptográfico evita la suplantación de direcciones, pero no limita a qué puede acceder un nodo de borde autenticado una vez que su túnel está establecido. Adjuntar programas eBPF a las interfaces WireGuard (wg0) aplica políticas de control de acceso en Capa 3 y Capa 4 en el kernel, antes de que los paquetes lleguen a cualquier proceso en espacio usuario.

Un conjunto típico de políticas:

• Nodos de borde: solo pueden acceder a los VIPs del balanceador de carga y endpoints de chequeo de salud en cada VPC en la nube. Bloqueados para acceder a subredes de bases de datos, planos de gestión y servicios de metadatos en la nube (169.254.169.254, etc.).
• Nodos backend: solo pueden responder a conexiones iniciadas desde las IP internas WireGuard del borde. Bloqueados para iniciar conexiones a través de fronteras de nube sin política explícita.

La aplicación de eBPF funciona con latencia casi nula en comparación con los firewalls en espacio usuario, y dado que se ejecuta en un espacio kernel confiable, permanece vigente incluso si los procesos en espacio usuario del nodo de borde están completamente comprometidos.

Herramientas como Cilium (que combina Kubernetes NetworkPolicy, cifrado WireGuard y microsegmentación basada en eBPF) hacen que este patrón sea accesible sin escribir programas eBPF en crudo. La capa de observabilidad Hubble de Cilium proporciona telemetría de red por flujo en toda la malla sin requerir un sidecar en cada pod.

Claves Preshared y Post-Quantum

Opcionalmente, WireGuard soporta una clave preshared simétrica de 256 bits (PSK) por par de peers, mezclada en la derivación de claves HKDF durante el handshake. La PSK ofrece una capa adicional de defensa: si el intercambio de claves Curve25519 se ve comprometido (por ejemplo, por un adversario cuántico que registre los handshakes actuales para descifrar después), la PSK evita la descifrado porque recuperar las claves de sesión también requiere la PSK.

Nota crítica: la PSK refuerza contra ataques cuánticos, pero no elimina completamente el riesgo. El intercambio de claves Curve25519 sigue siendo vulnerable al algoritmo de Shor en una computadora cuántica criptográficamente relevante. Una sesión protegida con PSK es más resistente que una sin ella, pero para garantías de seguridad a largo plazo en sesiones de malla persistentes, la tendencia emergente es un intercambio de claves híbrido — combinando Curve25519 clásica con un Mecanismo de Encapsulación de Claves (KEM) post-cuántico como ML-KEM (NIST FIPS 203, anteriormente Kyber). Proyectos como OQS-WireGuard implementan este esquema híbrido sin modificar el protocolo WireGuard, entregando una PSK post-cuántica sobre un canal TLS 1.3 híbrido ML-KEM antes de establecer sesiones WireGuard.

La rotación de PSK debe automatizarse. Una vida útil máxima de 30 días, distribuida mediante el mismo almacén etcd/Consul usado para la configuración de peers, proporciona seguridad operacional adecuada sin intervención manual.

---

Observabilidad en toda la Malla

Uno de los beneficios menos valorados de esta arquitectura es la superficie de observabilidad uniforme que crea. La monitorización multi-nube tradicional requiere combinar CloudWatch (AWS), Cloud Monitoring (GCP) y Azure Monitor — cada uno con diferentes modelos de datos, latencias y lenguajes de consulta.

Con interfaces WireGuard como la capa de datos uniforme, toda la telemetría de red está disponible a través de herramientas estándar de Linux sin importar en qué nube se ejecute el nodo:

# Contadores de transferencia por peer (actualizados cada 30 segundos por defecto)
wg show wg0

# Contadores de paquetes y bytes a nivel de interfaz
i -s link show wg0

# Telemetría por flujo basada en BPF (si se despliega Cilium/Hubble)
hubble observe --follow --namespace production

Exportar métricas de la interfaz WireGuard mediante un recolector de archivos de texto node_exporter de Prometheus y alimentarlas en un panel centralizado de Grafana proporciona a los ingenieros de red una vista única para pérdida de paquetes, latencia y rendimiento en toda la malla — AWS a GCP, GCP a Azure, borde a backend — sin conectores específicos de nube.

Para decisiones de enrutamiento sensibles a la latencia, el demonio BIRD o FRR puede configurarse para consumir estas métricas y ajustar dinámicamente las preferencias de ruta BGP, cerrando el ciclo entre observabilidad y dirección del tráfico.

---

Compromisos y Cuando Esta Arquitectura No Aplica

Esta es una arquitectura compleja con costos operativos reales. Antes de adoptarla, vale la pena enunciar claramente las compensaciones.

La complejidad operativa es alta. Ejecutar daemons BGP, orquestación de malla WireGuard, políticas eBPF y estado de sesión compartido en tres proveedores requiere profunda experiencia en redes Linux. Los equipos sin este conocimiento dedicarán mucho tiempo a depurar problemas que una arquitectura más simple (balanceadores de carga nativos en la nube por región, con enrutamiento DNS) no enfrentaría.

WireGuard solo soporta UDP. El túnel usa UDP como transporte. Los entornos en la nube que realizan shaping agresivo de UDP, o redes con PMTUD roto, requieren ajuste y pruebas cuidadosas del MTU. Los túneles basados en TCP (como en algunos productos ZTNA) toleran estos entornos mejor, a costa de la penalización TCP sobre TCP.

Anycast BGP no garantiza el ruta de salida más cercana. La longitud del AS-path no es lo mismo que proximidad geográfica. Un cliente en el sudeste asiático puede ser dirigido a un PoP en Japón en lugar de Singapur si el ASN del PoP japonés tiene menos saltos en la ruta BGP desde el ISP del cliente. Se requiere ingeniería de tráfico (mediante comunidades BGP, prepending de AS o manipulación de preferencia local) para ajustar el direccionamiento para relaciones ISP específicas.

El problema del enrutamiento asimétrico nunca desaparece por completo. Se puede mitigar con ingreso sin estado y hashing consistente, pero la causa subyacente — inestabilidad de rutas BGP en Internet público — está fuera de tu control. Los despliegues que no toleran ninguna interrupción en sesiones TCP deben evaluar si Anycast es el mecanismo de ingreso correcto, o si necesitan un enfoque de direccionamiento geográfico basado en DNS con TTLs largos y failover con chequeo de salud.

---

Conclusión

La superposición de ingreso multi-nube con WireGuard de unicast a anycast logra algo que las herramientas de tránsito propietarias de la nube no pueden: una columna vertebral de red verdaderamente agnóstica a la nube, donde migrar una carga de trabajo de AWS a GCP solo requiere iniciar un nuevo peer WireGuard y anunciar su ruta en la malla iBGP.

Las fortalezas de la arquitectura están bien definidas. El enrutamiento Anycast de BGP proporciona direccionamiento geográfico sin manipulación DNS. La malla WireGuard ofrece conectividad encriptada, nativa en kernel, entre nubes sin los costos o la rigidez de Direct Connect o ExpressRoute. El enrutamiento dinámico iBGP sobre la superposición proporciona failover en menos de un segundo basado en chequeos de salud en tiempo real del demonio de enrutamiento. eBPF en el ingreso aplica políticas de red de mínimo privilegio por debajo de la capa de aplicación.

Sus costos también están bien definidos: complejidad operativa, necesidad de experiencia en redes Linux en cada capa, y las limitaciones inherentes de BGP como mecanismo de direccionamiento.

Para equipos de ingeniería que han superado los balanceadores de carga nativos por nube y necesitan una columna vertebral de red unificada, observable y neutral en proveedores, esta arquitectura representa un plan sólido — aunque exigente.

---

Registro de Cambios

• Borrador v1 → v1.1: Corrección del overhead de encapsulación de WireGuard de 60 bytes a 76 bytes (IPv4) / 96 bytes (IPv6), considerando la etiqueta de autenticación Poly1305 de 16 bytes que el borrador original omitió. Actualización del MTU recomendado de la interfaz WireGuard a 1420 (predeterminado) y corrección del valor de clamp MSS a 1380 para TCP IPv4. Fecha de lanzamiento del kernel mainline (Linux 5.6, marzo de 2020). Ampliación del conjunto criptográfico para incluir BLAKE2s, SipHash24 y HKDF según el whitepaper de WireGuard. Corrección en la afirmación post-cuántica de PSK: PSK refuerza pero no elimina el riesgo cuántico; se añadió un esquema híbrido ML-KEM. Inclusión del lanzamiento de BIRD 3.0 (diciembre de 2024) y nota sobre arquitectura multihilo. Reemplazo de