VPN sitio a sitio: conectar dos oficinas en una sola red (un plan simple que funciona)

Lo que realmente quieres (y lo que probablemente no)

Cuando la gente dice “conectar dos oficinas en una sola red”, normalmente se refieren a una o más de estas cosas:

• Usuarios en la Oficina B pueden acceder a aplicaciones internas alojadas en la Oficina A (y viceversa).
• Ambos sitios pueden acceder a infraestructura compartida: AD/LDAP, comparticiones de archivos, Git, monitorización, VoIP, impresoras (sí, todavía).
• Políticas de acceso consistentes: “RRHH puede acceder a los sistemas de RRHH” es verdad independientemente de qué edificio tenga mejor café.
• Rendimiento estable y modos de fallo predecibles.

Lo que creen que quieren es “hacerlo como si hubiéramos estirado un switch entre edificios”. No lo hagas. Extender L2 a través de internet es la forma de acabar depurando tormentas de broadcast con un CFO en la sala.

Tu objetivo es simple: enrutar tráfico entre dos (o más) redes IP bien definidas sobre un túnel encriptado, con límites claros, DNS claro y observabilidad suficiente para responder “¿qué está roto?” en menos de cinco minutos.

Y recuerda: una VPN no es un portal mágico a la productividad. Es un transporte. Si tus aplicaciones no toleran latencia, pérdida de paquetes o enlaces intermitentes, el túnel solo hará que el dolor sea geográficamente diverso.

Broma corta #1: Una VPN no “hace las redes más rápidas”, pero sí hace que la culpa viaje a la velocidad del cable.

Algunos hechos e historia que explican las trampas actuales

Algo de contexto ayuda, porque la mitad de los problemas vienen de ideas heredadas que sobreviven mucho más allá de su utilidad.

1. IPsec es anterior al “pensamiento cloud” moderno. Los estándares centrales llegaron a mediados y finales de los 90; muchos fabricantes aún incluyen supuestos de esa época.
2. IKEv1 vs IKEv2 importa. IKEv2 (mediados de los 2000) arregló problemas reales: complejidad de negociación, movilidad y estabilidad. Si tienes opción, elige IKEv2.
3. La traversía de NAT (NAT-T) existe porque internet se inundó de NAT. IPsec ESP no se lleva bien con NAT; la encapsulación en UDP (normalmente puerto 4500) fue la solución práctica.
4. “VPN sobre UDP” no es nuevo. L2TP/IPsec y luego WireGuard se apoyaron en UDP porque se comporta mejor a través de middleboxes que ESP crudo en muchos entornos.
5. WireGuard es intencionalmente pequeño. Fue diseñado para ser auditable y minimalista comparado con las pilas IPsec tradicionales. Eso es una ventaja operativa real.
6. BGP sobre túneles es más antiguo que tu firewall actual. Los carriers han hecho enrutamiento dinámico sobre enlaces encapsulados durante décadas; no es exagerado cuando necesitas conmutación por error limpia.
7. El dolor del MTU es histórico, no un fallo personal. La encapsulación añade sobrecarga; Path MTU Discovery a menudo se bloquea o se desconfigura; “funciona en mi ping” ha mentido desde siempre.
8. Las redes corporativas solían ser de confianza por defecto. La era de LAN plana dejó muchas organizaciones con acceso interno amplio. Una VPN sitio a sitio puede recrear eso accidentalmente, a escala de internet.

Elige una topología que falle bien

La predeterminada: túnel enrutado sitio a sitio (hub-and-spoke o punto a punto)

Para dos oficinas, un túnel enrutado simple suele ser suficiente: la Oficina A tiene una puerta de enlace, la Oficina B tiene otra, y enrutas las subredes de A hacia las subredes de B a través del túnel.

Si vas a añadir más sitios más adelante, elige un hub-and-spoke desde el principio: uno o dos hubs (centro de datos o cloud), y spokes en las oficinas. Eso simplifica las políticas y la monitorización, y evita la “malla completa de la tristeza” donde cada oficina debe hablar de forma segura con cada otra con túneles separados.

IPsec vs WireGuard (opinión)

Si ya tienes firewalls empresariales y necesitas soporte de vendor: usa IPsec con IKEv2. Está en todas partes, interoperable, puede ser HA y los auditores lo reconocen.

Si quieres simplicidad y controlas ambos extremos: WireGuard es difícil de superar. Menos negociación. Menos partes móviles. Depurar es más “paquetes dentro/paquetes fuera” y menos “Fase 1 está arriba pero la Fase 2 está poseída”.

En cualquier caso, no elijas basándote en una sola gráfica de benchmark. Elige según lo que puedas operar a las 3 a.m. y lo que puedas reemplazar limpiamente.

Puenteo de Capa 2: la trampa

Extender redes L2 entre oficinas suena atractivo cuando quieres “cero cambios”. También transporta cada broadcast, ARP y bucle accidental a través de un túnel. Enruta. Siempre enruta. Si alguien insiste en L2, haz que esa persona se haga cargo del momento de la caída.

Listas de verificación / plan paso a paso (el plan simple que funciona)

Fase 0: prerequisitos antes de tocar un túnel

• Elige subredes no solapadas. Si la Oficina A usa 192.168.1.0/24, la Oficina B no debe usarla. Esto no es negociable.
• Define qué subredes necesitan comunicarse. “Todo con todo” es perezoso y peligroso.
• Elige un modelo de enrutamiento. Rutas estáticas para redes pequeñas y estables. BGP si necesitas conmutación por error o planeas crecer.
• Elige un método de autenticación. Pre-shared key (PSK) está bien para configuraciones pequeñas; certificados escalan mejor y rotan de forma más limpia.
• Inventaría NAT y firewalls. Saber quién posee IPs públicas, qué puertos están permitidos y si alguno de los lados está detrás de carrier-grade NAT.

Fase 1: plan IP y política de tráfico

Haz esto en papel primero:

• LAN Oficina A: por ejemplo, 10.10.0.0/16
• LAN Oficina B: por ejemplo, 10.20.0.0/16
• Rangos de infraestructura reservados (servidores, VoIP, impresoras) con subredes más pequeñas para orden
• Decide si los clientes deben salir a internet localmente (split tunnel) o a través de un egreso central (full tunnel)

Opinión: Para dos oficinas, por defecto opta por split tunnel a menos que tengas una razón de cumplimiento para centralizar el egreso. Tunelizar todo el tráfico a través de sitio a sitio es una forma clásica de convertir un problema del ISP de una oficina en un incidente de toda la empresa.

Fase 2: configuración del túnel (mínimo viable, apto para producción)

• Cifrado: usa suites modernas. Evita algoritmos obsoletos y “porque es compatible”. Si estás atrapado por compatibilidad, aísla y planifica una actualización.
• Perfect Forward Secrecy: actívalo.
• Intervalos de rekey: mantén los valores por defecto a menos que tengas una razón; rekeyear agresivamente puede crear apagones periódicos.
• DPD/keepalives: habilita la detección de pares muertos para fallar rápido.
• Reglas de firewall: permite solo el tráfico necesario sobre el túnel (por subred y puerto), y luego amplía de forma intencional.

Fase 3: enrutamiento y DNS

• Enrutamiento: instala rutas en las puertas de enlace (o vía BGP). Confirma con traceroute que el camino pase por el túnel.
• DNS: haz que la resolución de nombres funcione entre sitios. Aquí es donde vive “el túnel está arriba pero la app falla”.
• Sincronización horaria: asegura que ambos sitios tengan NTP fiable. La validación de certificados y Kerberos no son fans del viaje en el tiempo.

Fase 4: endurecimiento y observabilidad

• Registra cambios de estado del túnel y eventos de rekey.
• Monitoriza pérdida de paquetes y latencia entre hosts representativos, no solo “túnel arriba”.
• Registra configuraciones MTU/MSS y valida con transferencias reales.
• Documenta: subredes, rutas, puertos permitidos, propietarios y un plan de reversión.

Fase 5: prueba como pesimista

• Simula una caída del ISP en un sitio (deshabilita WAN, provoca la falla del enlace de respaldo si lo tienes).
• Prueba la resolución DNS desde ambos sitios hacia servicios compartidos.
• Prueba transferencias grandes y conexiones de larga duración (llamadas VoIP, RDP/SSH, conexiones a bases de datos).
• Prueba después de un rekey (espera al menos un intervalo de rekey).

Enrutamiento: estático vs dinámico, y la regla que no debes romper

La regla única: no solapar espacio IP

Si el mismo rango RFC1918 existe en ambos lados, tarde o temprano terminarás haciendo NAT hasta quedarte sin salida. A veces funciona unas semanas. Luego añades un tercer sitio, o una VPC en la nube, o una VPN de contratista, y todo se convierte en una aventura de elegir caminos de enrutamiento rotos.

Renumerar es doloroso. Aun así es más fácil que hacks permanentes con NAT.

Enrutamiento estático: bueno para redes pequeñas y estables

Si cada oficina tiene un solo enlace WAN y tus subredes no cambian con frecuencia, las rutas estáticas están bien. Son simples, depurables y no requieren demonios de enrutamiento.

El enrutamiento estático falla cuando:

• Añades redundancia y quieres conmutación por error limpia.
• Añades más redes y olvidas una ruta en un lado (sucede).
• Dependes de humanos para actualizar rutas durante un incidente (los humanos son poco fiables bajo estrés, incluido quien escribe esto).

BGP: no es obligatorio, pero a menudo es la herramienta de conmutación por error más limpia

Si tienes dos túneles (o dos ISPs) y quieres que el tráfico cambie rápidamente, BGP vale la pena. Puedes ejecutar BGP sobre IPsec o WireGuard, anunciar solo los prefijos que quieras y dejar que el protocolo gestione la conmutación por error.

Manténlo conservador:

• Usa listas de prefijos.
• Usa límites de max-prefix.
• Usa route-maps para prevenir “ups, anuncié 0.0.0.0/0”.

Broma corta #2: BGP es como el chisme de oficina: poderoso, rápido y absolutamente difundirá lo equivocado si no pones límites.

DNS e identidad: el asesino silencioso

La mayoría de los “problemas de VPN” son en realidad problemas de DNS disfrazados de VPN. El túnel está arriba. La ruta existe. Pero los usuarios no pueden alcanzar intranet, falla la autenticación o un cliente de base de datos se queda parpadeando.

Decide tu modelo de nombres

• Dominio interno único (común en entornos AD): ambas oficinas resuelven las mismas zonas internas.
• DNS split-horizon: los nombres se resuelven de forma diferente según el sitio de origen.
• Nombres de servicio explícitos: las apps usan FQDN que apuntan a VIPs locales del sitio o balanceadores globales; menos “la oficina como concepto”.

Haz el DNS resistente a través del túnel

Como mínimo:

• Cada oficina debe tener resolutores DNS locales.
• Los resolutores deben reenviar o replicar zonas según sea necesario.
• Los clientes no deben depender del “DNS de la otra oficina” como primario. Así es como un fallo de WAN se convierte en una tormenta de autenticación.

Los sistemas de identidad odian la conectividad parcial

Kerberos, LDAP y la autenticación basada en certificados pueden fallar de formas que parecen “lentitud aleatoria”. Si el DNS cambia entre sitio A y B, puedes obtener timeouts intermitentes en la autenticación. Mantén los servicios de identidad locales cuando sea posible, o diseña conmutación por error explícita con comprobaciones de salud.

MTU, MSS y por qué “hace ping” no significa nada

La encapsulación suma bytes. IPsec añade sobrecarga (cabeceras ESP, posible encapsulación UDP). WireGuard también añade sobrecarga. Si no lo tienes en cuenta, creas un tipo especial de apagón: los paquetes pequeños funcionan, los grandes se quedan atascados. Los usuarios informan “algunos sitios cargan, las comparticiones de archivos cuelgan, las videollamadas se congelan”. Empiezas a culpar a los equipos de aplicaciones. Es MTU.

Guía práctica

• Asume que tu MTU efectiva sobre el túnel es menor que 1500.
• Ajusta la MSS de TCP en el borde del túnel si puedes (común en firewalls y routers). Es una herramienta contundente, pero evita miserias relacionadas con la fragmentación.
• Prueba con ping y la opción “no fragmentar” y tamaños de carga realistas.

Lo que buscas lograr

Quieres un camino donde TCP pueda establecer sesiones y transferir datos grandes sin generar agujeros negros. Si PMTUD está bloqueado en la ruta (común), el ajuste de MSS a menudo te salva de una semana de reuniones sin sentido.

Postura de seguridad: la encriptación no es control de acceso

Una VPN sitio a sitio encripta el tráfico entre las puertas de enlace. No decide quién debe acceder a qué. Ese es tu trabajo.

No conviertas “la otra oficina” en una zona confiable

Muchas redes tratan la subred remota como si fuera otra VLAN. Entonces un portátil comprometido en la Oficina B puede sondear servidores en la Oficina A. La encriptación protege fielmente el tráfico del atacante. Eso no es la victoria que quieres.

Segmentación mínima viable

• Permite solo los flujos necesarios subnet-to-subnet (por ejemplo, clientes a subredes de aplicaciones, aplicaciones a subredes de BD).
• Bloquea el este-oeste entre VLANs de clientes por defecto.
• Registra flujos denegados durante el despliegue para ajustar sin adivinanzas.

Gestión y rotación de claves

Para PSKs de IPsec: trátalos como contraseñas; róta-los, guárdalos en un gestor de secretos y no los envíes por email. Para certificados: automatiza la emisión y renovación si puedes. Los certificados expirados son el tipo de fallo que se siente personal.

Idea parafraseada (Werner Vogels, operaciones/fiabilidad): “Construye sistemas asumiendo que las cosas fallan; la resiliencia viene de diseñar para esa realidad”.

Alta disponibilidad: qué significa realmente “redundante”

La redundancia es una cadena, y el eslabón más débil suele ser “un solo ISP”. Puedes montar un par HA de VPN y aun así un solo zanjado de la calzada puede dejarte fuera.

Patrones HA que realmente funcionan

• WAN dual en cada sitio (idealmente carriers diferentes, rutas físicas distintas).
• Dos gateways VPN (activo/standby o activo/activo) con sincronización de estado si se soporta.
• Dos túneles (uno por WAN) con conmutación por error de enrutamiento (preferido BGP, o rutas estáticas monitorizadas).

Cuidado con el “HA que falla durante la conmutación”

Modo de fallo común: HA está configurado, pero nadie lo probó. Luego el enlace primario cae, el túnel se cambia y las sesiones de larga duración mueren. Los usuarios lo llaman “la VPN es inestable”. La VPN hace lo que pediste. Pediste un cambio sin tolerancia a nivel de aplicación.

Sé explícito sobre lo que prometes:

• “Conmutación en 30 segundos, las sesiones TCP existentes pueden reiniciarse.” (honesto)
• “Sin impacto perceptible.” (raro, caro y requiere más que una VPN)

Monitorización y SLOs para el túnel (sí, en serio)

Si tu monitorización es “el túnel está arriba”, aprenderás sobre pérdida de paquetes por Slack. Eso no es observabilidad; es crowdsourcing para detectar incidentes.

Qué medir

• Estado: túnel establecido, eventos de rekey, flaps.
• Latencia: RTT entre hosts representativos a través del túnel.
• Pérdida: porcentaje de pérdida de paquetes, preferiblemente a múltiples tamaños de paquete.
• Rendimiento: pruebas periódicas con iperf entre dos endpoints de prueba (programadas, con límite de tasa).
• Errores: drops de interfaz, contadores de fragmentación, denegaciones de firewall sobre el túnel.

Establece expectativas (SLO ligero)

Ejemplo: “Conectividad entre oficinas: 99.9% de disponibilidad mensual; RTT p95 bajo 40 ms en horario laboral; pérdida de paquetes bajo 0.5%.” Ajusta a la realidad. Luego alerta cuando lo violes, no cuando alguien se queje.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son centradas en Linux porque Linux es honesto sobre lo que hace. Incluso si tus puertas de enlace son appliances, puedes ejecutar estas desde hosts de prueba en cada lado.

Tarea 1: Confirma tu IP local y la ruta hacia la subred remota

cr0x@server:~$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.10.12.34/24 brd 10.10.12.255 scope global eth0
       valid_lft forever preferred_lft forever

cr0x@server:~$ ip route get 10.20.8.50
10.20.8.50 via 10.10.12.1 dev eth0 src 10.10.12.34 uid 1000
    cache

Qué significa: Tu host piensa que el tráfico a 10.20.8.50 va al gateway local (10.10.12.1). Bien. Si en su lugar enruta a otra interfaz (o a una ruta por defecto que no esperabas), estás depurando la caja equivocada.

Decisión: Si la ruta está mal, arregla el enrutamiento local/opción DHCP 121/rutas estáticas antes de tocar las configuraciones de la VPN.

Tarea 2: Comprueba que la subred remota realmente enruta de vuelta

cr0x@server:~$ traceroute -n 10.20.8.50
traceroute to 10.20.8.50 (10.20.8.50), 30 hops max, 60 byte packets
 1  10.10.12.1  0.407 ms  0.352 ms  0.331 ms
 2  172.16.100.1  10.982 ms  11.104 ms  11.015 ms
 3  10.20.8.50  12.201 ms  12.144 ms  12.087 ms

Qué significa: El salto 2 es probablemente tu gateway VPN/interfaz de túnel. Puedes ver que el camino va por el intermedio esperado.

Decisión: Si traceroute muere en el salto 2, sospecha política de túnel, reglas de firewall o rutas de retorno faltantes en el extremo remoto.

Tarea 3: Verifica que no tengas subredes solapadas (en un host)

cr0x@server:~$ ip route | egrep '10\.10\.|10\.20\.|192\.168\.'
10.10.12.0/24 dev eth0 proto kernel scope link src 10.10.12.34
10.20.0.0/16 via 10.10.12.1 dev eth0

Qué significa: Tu host tiene una ruta limpia a la red remota. Los solapamientos suelen aparecer como múltiples rutas para el mismo prefijo o redes conectadas inesperadas.

Decisión: Si ves el prefijo remoto como “conectado” localmente, tienes solapamiento o una configuración DHCP errante. Para y arregla el direccionamiento.

Tarea 4: Prueba la conectividad básica y distingue “sin ruta” de “filtrado”

cr0x@server:~$ ping -c 3 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 56(84) bytes of data.
64 bytes from 10.20.8.50: icmp_seq=1 ttl=62 time=12.4 ms
64 bytes from 10.20.8.50: icmp_seq=2 ttl=62 time=12.2 ms
64 bytes from 10.20.8.50: icmp_seq=3 ttl=62 time=12.5 ms

--- 10.20.8.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.210/12.378/12.512/0.121 ms

Qué significa: ICMP funciona y la latencia es razonable. Esto no prueba que TCP funcione a escala, pero es un comienzo.

Decisión: Si ping falla pero traceroute llega al host, ICMP puede estar bloqueado; prueba TCP a continuación en lugar de declarar la VPN muerta.

Tarea 5: Prueba de conectividad TCP (chequeo a nivel servicio)

cr0x@server:~$ nc -vz -w 2 10.20.8.50 443
Connection to 10.20.8.50 443 port [tcp/https] succeeded!

Qué significa: El enrutamiento y la política de firewall permiten TCP/443. Esto se parece más a lo que experimentan los usuarios que un ping.

Decisión: Si esto falla pero ping funciona, sospecha reglas de firewall, security groups o firewall a nivel host en el servidor.

Tarea 6: Valida la resolución DNS entre sitios

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.20.0.53

cr0x@server:~$ dig +short app.internal.example
10.20.8.50

Qué significa: Tienes resolutores de ambos sitios disponibles y el nombre resuelve a la IP remota esperada.

Decisión: Si la resolución cambia entre respuestas diferentes (o se agota), arregla el reenvío/replicación de DNS antes de tocar el enrutamiento.

Tarea 7: Detecta problemas de MTU con pings “no fragmentar”

cr0x@server:~$ ping -M do -s 1472 -c 2 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420

cr0x@server:~$ ping -M do -s 1392 -c 2 10.20.8.50
PING 10.20.8.50 (10.20.8.50) 1392(1420) bytes of data.
1400 bytes from 10.20.8.50: icmp_seq=1 ttl=62 time=13.1 ms
1400 bytes from 10.20.8.50: icmp_seq=2 ttl=62 time=13.0 ms

Qué significa: El PMTU está alrededor de 1420 bytes. Si los endpoints intentan paquetes de 1500 sin MSS clamping o PMTUD, obtendrás bloqueos.

Decisión: Ajusta MSS (por ejemplo, 1360–1380) o modifica el MTU de la interfaz para evitar fragmentación/agujeros negros.

Tarea 8: Comprueba el MSS negociado en TCP (control puntual de clamping)

cr0x@server:~$ ss -ti dst 10.20.8.50:443 | sed -n '1,20p'
ESTAB  0  0  10.10.12.34:52514  10.20.8.50:443
	 cubic wscale:7,7 rto:204 rtt:13.1/1.2 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:10 bytes_sent:2145 bytes_acked:2145 segs_out:17 segs_in:14 data_segs_out:10 data_segs_in:9

Qué significa: MSS es 1360 y PMTU 1420; esto es consistente con un escenario de sobrecarga por túnel.

Decisión: Si MSS muestra 1460 mientras PMTU es ~1420, te estás buscando problemas. Implementa MSS clamping en el gateway.

Tarea 9: Mide latencia y pérdida con mtr (no solo ping)

cr0x@server:~$ mtr -n -r -c 50 10.20.8.50
Start: 2025-12-27T11:12:41+0000
HOST: server                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.12.1                0.0%    50   0.4   0.4   0.3   0.9   0.1
  2.|-- 172.16.100.1              0.0%    50  11.2  11.0  10.7  13.9   0.6
  3.|-- 10.20.8.50                1.0%    50  12.5  12.7  12.0  18.4   1.2

Qué significa: 1% de pérdida en el destino es suficiente para que ciertas apps se sientan “lentas”, especialmente las que hacen muchas trocas de paquetes.

Decisión: Si la pérdida aparece en el salto 2 y 3, sospecha WAN o transporte del túnel. Si solo en el salto 3, sospecha el host o su red local.

Tarea 10: Verifica el estado de SA de IPsec en un gateway Linux (strongSwan)

cr0x@server:~$ sudo ipsec statusall | sed -n '1,40p'
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0, x86_64):
  uptime: 2 hours, since Dec 27 09:11:02 2025
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
Connections:
 office-a-office-b:  10.0.0.1...203.0.113.20  IKEv2, dpddelay=30s
 office-a-office-b:   local:  [gw-a] uses pre-shared key authentication
 office-a-office-b:   remote: [gw-b] uses pre-shared key authentication
Security Associations (1 up, 0 connecting):
 office-a-office-b[12]: ESTABLISHED 15 minutes ago, 10.0.0.1[gw-a]...203.0.113.20[gw-b]
 office-a-office-b{8}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c9f2a1d1_i c6f8b02f_o
 office-a-office-b{8}:   10.10.0.0/16 === 10.20.0.0/16

Qué significa: IKEv2 está establecido y la SA hija (ESP) está instalada para las subredes esperadas.

Decisión: Si IKE está arriba pero no se instala child SA, probablemente tienes selectores de tráfico/subredes desajustados o problemas de política.

Tarea 11: Busca flaps de rekey y errores de negociación en logs

cr0x@server:~$ sudo journalctl -u strongswan --since "2 hours ago" | egrep -i "rekey|established|failed|proposal" | tail -n 20
Dec 27 10:55:03 gw-a charon[1124]: 12[IKE] initiating IKE_SA office-a-office-b[12] to 203.0.113.20
Dec 27 10:55:03 gw-a charon[1124]: 12[IKE] IKE_SA office-a-office-b[12] established between 10.0.0.1[gw-a]...203.0.113.20[gw-b]
Dec 27 10:55:03 gw-a charon[1124]: 12[CHD] CHILD_SA office-a-office-b{8} established with SPIs c9f2a1d1_i c6f8b02f_o and TS 10.10.0.0/16 === 10.20.0.0/16

Qué significa: Establecimiento limpio. Si ves fallos repetidos, probablemente tienes WAN intermitente, propuestas desajustadas o problemas de NAT.

Decisión: Rekeys frecuentes durante horas laborales: investiga saturación de CPU, pérdida de paquetes o lifetimes demasiado agresivos.

Tarea 12: Verifica el estado de peers en WireGuard (si usas WireGuard)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 0u9z4x2m3u9l4t...
  listening port: 51820

peer: 2q8m9n0b1v2c3x...
  endpoint: 203.0.113.20:51820
  allowed ips: 10.20.0.0/16
  latest handshake: 52 seconds ago
  transfer: 1.32 GiB received, 1.08 GiB sent
  persistent keepalive: every 25 seconds

Qué significa: Handshake reciente y contadores de tráfico en aumento. Si “latest handshake” es “never”, tienes problemas de enrutamiento/NAT/firewall.

Decisión: Si ocurren handshakes pero el tráfico falla, sospecha allowed IPs/rutas o política de firewall más allá del túnel.

Tarea 13: Confirma reenvío y policy routing en un gateway Linux

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

cr0x@server:~$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Qué significa: El reenvío está habilitado; no hay reglas de enrutamiento de política inusuales presentes.

Decisión: Si forwarding es 0, tu gateway es un host muy caro. Habilita el reenvío y asegúrate de que las reglas de firewall permitan el reenvío.

Tarea 14: Inspecciona contadores de firewall para tráfico de túnel descartado (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" ip saddr 10.20.0.0/16 ip daddr 10.10.0.0/16 tcp dport { 53, 443, 445 } accept
    counter packets 184 bytes 11040 drop
  }
}

Qué significa: La política de forward es drop y tienes una regla de allow específica desde wg0 hacia office-a. El contador en la regla final de drop indica que algo está siendo denegado.

Decisión: Si los contadores de drop aumentan cuando los usuarios se quejan, revisa qué puertos/subredes faltan. Añade reglas de forma intencional; no “permitas todo” por frustración.

Tarea 15: Mide el rendimiento (controlado) para detectar límites de CPU o shaping

cr0x@server:~$ iperf3 -c 10.20.8.50 -P 4 -t 10
Connecting to host 10.20.8.50, port 5201
[  5] local 10.10.12.34 port 46318 connected to 10.20.8.50 port 5201
[  7] local 10.10.12.34 port 46334 connected to 10.20.8.50 port 5201
[  9] local 10.10.12.34 port 46344 connected to 10.20.8.50 port 5201
[ 11] local 10.10.12.34 port 46356 connected to 10.20.8.50 port 5201
[SUM]   0.00-10.00  sec   420 MBytes   352 Mbits/sec  sender
[SUM]   0.00-10.00  sec   418 MBytes   350 Mbits/sec  receiver

Qué significa: Estás obteniendo ~350 Mbps a través del túnel entre estos hosts. Eso puede ser excelente o pésimo según tu WAN y hardware del gateway.

Decisión: Si el rendimiento está muy por debajo de la capacidad WAN, revisa CPU del gateway, offload de cifrado, shaping de tráfico o un cuello de botella de un solo hilo.

Tarea 16: Comprueba CPU del gateway bajo carga (indicio de cuello de botella por cifrado)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (gw-a) 	12/27/2025 	_x86_64_	(4 CPU)

11:14:01 AM  CPU   %usr   %nice    %sys %iowait  %irq  %soft  %steal  %guest  %gnice  %idle
11:14:02 AM  all   35.12    0.00   20.44    0.00  0.00   5.33    0.00    0.00    0.00  39.11
11:14:02 AM    0   80.00    0.00   18.00    0.00  0.00   2.00    0.00    0.00    0.00   0.00
11:14:02 AM    1   10.00    0.00   25.00    0.00  0.00   8.00    0.00    0.00    0.00  57.00
11:14:02 AM    2   20.00    0.00   15.00    0.00  0.00   5.00    0.00    0.00    0.00  60.00
11:14:02 AM    3   30.00    0.00   24.00    0.00  0.00   6.00    0.00    0.00    0.00  40.00

Qué significa: CPU0 está saturada. Eso a menudo indica un problema de afinidad de colas/interrupts o un proceso que no escala bien. El rendimiento VPN puede colapsar con un núcleo caliente.

Decisión: Si ves un núcleo caliente durante tráfico pico, considera ajustar afinidad de IRQ, habilitar multiqueue, actualizar hardware o cambiar cifrado/offload (con cuidado).

Guion de diagnóstico rápido

Este es el flujo “cinco minutos, sin drama”. Intentas encontrar rápido el cuello de botella: enrutamiento, estado del túnel, MTU, DNS o el servicio del extremo remoto.

Primero: ¿es realmente el túnel, o solo una app?

1. Elige un host de prueba en cada oficina (o un jump box) que controles.
2. Prueba TCP a un servicio conocido (por ejemplo, nc -vz remote-ip 443).
3. Prueba la resolución DNS para el mismo nombre de servicio desde ambos lados.

Si solo una app falla pero TCP básico funciona, deja de culpar a la VPN. Sube en la pila (TLS, auth, dependencias de la app).

Segundo: confirma enrutamiento y camino de retorno

1. Haz traceroute en ambos sentidos si es posible (A→B y B→A). El enrutamiento asimétrico es común cuando un lado tiene múltiples gateways.
2. Revisa rutas en las gateways para asegurar que cada subred sea conocida y apunte al túnel.
3. Busca NAT donde no esperabas. El NAT dentro de un sitio enrutado suele ser síntoma de solapamiento o un parche.

Tercero: sanity check MTU/MSS

1. Ejecuta pings DF para encontrar el PMTU aproximado.
2. Revisa MSS de una sesión TCP establecida (ss -ti).
3. Si es probable un agujero negro, ajusta MSS en el gateway.

Cuarto: ¿está enfermo el enlace de transporte?

1. Ejecuta mtr por 50–200 paquetes para ver pérdida y jitter.
2. Revisa errores/drops en las interfaces WAN de los gateways.
3. Comprueba si el enlace ISP está saturado (shaping o bufferbloat pueden imitar “lentitud de VPN”).

Quinto: logs y estado del daemon de túnel

1. Para IPsec: confirma que IKE y child SAs estén instaladas y estables.
2. Para WireGuard: confirma handshakes y que los contadores de tráfico aumenten.
3. Busca eventos periódicos: rekeys, timeouts DPD, cambios de endpoint (NAT).

Errores comunes: síntomas → causa raíz → solución

1) “El túnel está arriba, pero SMB/RDP/transferencias de archivos cuelgan”

Síntomas: Ping funciona. Peticiones HTTP pequeñas funcionan. Descargas grandes se quedan.

Causa raíz: Agujero negro de MTU o falta de MSS clamping; PMTUD bloqueado en algún lugar.

Solución: Determina el PMTU con ping DF; ajusta MSS de TCP en el gateway VPN; considera bajar MTU del túnel. Re-prueba con iperf y transferencias reales.

2) “Solo una dirección funciona”

Síntomas: Oficina A alcanza Oficina B, pero no al revés. O una subred puede iniciar pero no recibir respuestas.

Causa raíz: Ruta de retorno faltante, enrutamiento asimétrico por una salida a internet distinta o supuestos de estado en firewalls.

Solución: Verifica rutas en ambas gateways. Confirma que el extremo remoto sabe cómo alcanzar la subred que inició. Asegura que firewalls stateful vean ambos sentidos por la misma ruta.

3) “Funciona por una hora, luego cae a ratos”

Síntomas: Desconexiones periódicas. Llamadas VoIP caen a intervalos previsibles. Logs muestran rekeys o timeouts DPD.

Causa raíz: Lifetimes agresivos, timeouts de mapeo NAT, o WAN inestable con pérdida breve que rompe keepalives.

Solución: Ajusta keepalives/persistent keepalive (WireGuard) o DPD (IPsec). Evita intervalos de rekey muy cortos. Si estás detrás de NAT, asegúrate de NAT-T y agujeros UDP estables.

4) “DNS falla aleatoriamente, los inicios de sesión son lentos, aparecen errores Kerberos”

Síntomas: Timeouts intermitentes a nombres internos; autenticación a veces falla; los reintentos a veces funcionan.

Causa raíz: Clientes usando DNS del sitio remoto como primario; reenvío DNS sobre un túnel inestable; configuración split-horizon errónea; desincronización horaria.

Solución: Prefiere resolutores locales; replica zonas; añade reenvío condicional; valida NTP en ambos sitios; mantiene dependencias DNS locales cuando sea factible.

5) “Añadimos NAT para lidiar con solapamientos; ahora todo es raro”

Síntomas: Algunos servicios funcionan, otros no. Logs muestran IPs de origen inesperadas. Control de acceso falla. La depuración parece arqueología.

Causa raíz: Subredes solapadas enmascaradas con NAT; suposiciones de aplicaciones sobre IP de origen o búsquedas reversas.

Solución: Renumera un sitio (sí, en serio). Si debes usar NAT temporalmente, documentalo, aísla la solución y pon una fecha límite para quitarlo.

6) “El rendimiento es terrible pero el enlace ISP es rápido”

Síntomas: Tests de velocidad a internet son buenos; transferencias sobre VPN son lentas; CPU del gateway sube.

Causa raíz: Cifrado limitado por CPU; núcleo único saturado; falta de offload; colas pobres; MTU pequeño que añade sobrecarga.

Solución: Mide con iperf. Revisa CPU por núcleo. Mejora hardware del gateway, ajusta afinidad de IRQ o usa un camino de cifrado/offload soportado por tu plataforma. No adivines: mide antes y después.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: el incidente causado por una suposición incorrecta

La compañía tenía dos oficinas tras una adquisición. La Oficina A gestionaba todo: identidad, comparticiones, apps internas. La Oficina B tenía una red pequeña que “parecía estar bien” y un firewall configurado años atrás. El plan era un túnel IPsec sitio a sitio sencillo. La frase favorita del gestor de proyecto era “es solo un túnel”.

El día uno, el túnel se levantó. Todos aplaudieron. La Oficina B seguía sin poder iniciar sesión al CRM por hostname. Por IP sí funcionaba. La sala de crisis inmediatamente culpó a la VPN porque eso fue lo que cambió. El equipo de VPN empezó a cambiar cifrados y tiempos de rekey como si fuera un concurso de cocina.

Dos horas después, alguien finalmente ejecutó dig desde un cliente de Oficina B. Estaba usando el servidor DNS de la Oficina A como primario, a través del túnel. Con poco tráfico funcionaba. Bajo la carga de inicios de mañana, las peticiones DNS se encolaban tras grandes transferencias SMB. Las búsquedas de nombres fallaban, la autenticación encadenaba timeouts y los usuarios experimentaron “internet roto”.

La suposición incorrecta fue considerar que DNS es “tráfico pequeño” y puede viajar junto con todo lo demás sin prioridad ni localización. La solución fue aburrida: añadir resolutores DNS locales en Oficina B, implementar reenvío condicional para zonas internas y permitir tráfico DNS con mayor prioridad. El túnel no cambió. El resultado sí.

Después, escribieron una regla operativa: “Cada sitio debe poder resolver nombres internos localmente durante una caída de WAN”. Esa regla evitó al menos tres incidentes posteriores, incluido uno donde el ISP cayó y nadie lo notó durante quince minutos porque el sitio siguió funcional.

Mini-historia 2: la optimización que salió mal

Otra organización tenía conectividad sólida pero quería “más velocidad”. Sus enlaces WAN se actualizaron y alguien decidió que la VPN ahora era el cuello de botella. Habilitaron un conjunto de “perillas de rendimiento” en el gateway: intervalos de rekey más cortos, DPD agresivo y una suite de cifrado más intensiva en CPU porque “más fuerte es mejor”. También activaron shaping “solo para suavizar”, sin definir objetivos.

El túnel siguió levantándose. La mayoría del tráfico parecía bien. Entonces, exactamente de vez en cuando, una ola de quejas de usuarios: llamadas de voz caían, escritorios remotos se congelaban y transferencias de archivos se detenían y luego reanudaban. El patrón parecía un reloj embrujado.

No era un embrujo. Era churn por rekey combinado con shaping que introdujo colas durante ráfagas de negociación. Los paquetes de rekey competían con datos. DPD se activaba cuando la latencia subía. Los gateways desmontaban y reconstruían estado, provocando reinicios de sesiones. Todos vivieron “inestabilidad aleatoria” que en realidad estaba perfectamente sincronizada.

El rollback lo arregló de inmediato: restablecer lifetimes razonables, mantener DPD sensato y quitar el shaping hasta medir requisitos. Más tarde añadieron QoS selectivo para voz, no un “todo bonito”. La lección quedó: optimizar sin un cuello de botella medido es añadir complejidad con un temporizador incorporado.

Mini-historia 3: la práctica aburrida pero correcta que salvó el día

Un equipo de operaciones mantenía un VPN hub-and-spoke que conectaba dos oficinas y una pequeña VPC en la nube. Nada sofisticado: dos túneles por sitio, BGP con filtros de prefijo, y un trabajo de monitorización que probaba DNS, TCP/443 y un ping de paquete grande cada minuto desde cada lado. Los dashboards no eran bonitos, pero eran honestos.

Una tarde, la Oficina B reportó “lentitud hacia todo lo de Oficina A”. El estado del túnel estaba arriba. Desde la perspectiva del usuario, eso significaba “la VPN está arriba, así que deben ser las apps”. El equipo de apps se preparó para el impacto.

La monitorización contó otra historia: la latencia y la pérdida de paquetes subieron solo en el camino que usaba el ISP #1 en Oficina B. El túnel de respaldo por ISP #2 estaba limpio. BGP todavía prefería ISP #1 porque el túnel “estaba arriba”. El equipo ajustó las métricas BGP para preferir el camino limpio y temporalmente bajó la prioridad del enlace malo.

Los usuarios se recuperaron en minutos. Sin depuraciones heroicas. Sin culpas. Más tarde añadieron tracking basado en pérdida/latencia medida para que “arriba” no fuera la única señal. La práctica aburrida de tener pruebas sintéticas que replicaran el dolor del usuario y un diseño de enrutamiento capaz de reaccionar salvó el día porque el día no necesitaba ser salvado; necesitaba evidencia.

Preguntas frecuentes

1) ¿Debería usar IPsec o WireGuard para una VPN sitio a sitio?

Si necesitas soporte de appliances, casillas de cumplimiento o integración fácil con firewalls existentes, usa IPsec con IKEv2. Si controlas ambos endpoints y quieres simplicidad operativa, WireGuard suele ser más fácil de ejecutar y depurar.

2) ¿Puedo conectar dos oficinas si un lado está detrás de NAT o carrier-grade NAT?

Usualmente sí. Para IPsec, usa NAT-T (UDP 4500) y asegúrate de configurar keepalives/DPD. Para WireGuard, persistent keepalive ayuda a mantener los mapeos NAT. Si la entrada es imposible, puede que necesites un hub alcanzable (VM en cloud) y conectar ambos sitios saliendo hacia él.

3) ¿Necesito una IP pública estática en ambos sitios?

Hace la vida más fácil, pero no es estrictamente necesario. IPs dinámicas funcionan con DDNS o con un enfoque de hub. Aun así, para producción: paga por IPs estáticas si puedes. Sale más barato que las horas depurando “¿por qué cambió el endpoint?”.

4) ¿Debemos enrutar todo el tráfico de internet de la Oficina B a través de la Oficina A?

Sólo si tienes una razón clara (herramientas centralizadas de seguridad, cumplimiento). De lo contrario, mantén el egreso a internet local y enruta solo prefijos internos sobre la VPN. Tunelizar todo sitio a sitio es una forma clásica de crear apagones sorpresa.

5) ¿Cuántas subredes deberían estar permitidas a través del túnel?

Las menos posible. Comienza con subredes específicas de servidores y puertos requeridos. Expande según necesidades observadas. “Permitir any-any” es cómo incidentes internos se convierten en incidentes entre sitios.

6) ¿Por qué todo se rompe cuando alguien inicia una gran copia de archivos?

Más comúnmente problemas de MTU/MSS o bufferbloat/saturación en el enlace WAN. Valida PMTU con pings DF, revisa MSS con ss -ti y mide pérdida/latencia con mtr mientras la copia corre.

7) ¿Podemos ejecutar BGP sobre la VPN, o es demasiado sofisticado?

Puedes, y a menudo es la forma más limpia de manejar redundancia y evitar ediciones manuales de rutas. Si solo tienes un túnel y dos subredes, estático está bien. Si tienes dos túneles y quieres conmutación por error fiable, BGP es la opción sensata.

8) ¿Cómo hacemos para que la conmutación no rompa sesiones de usuario?

Normalmente no puedes garantizar eso solo con un cambio de VPN. Puedes minimizar la interrupción con convergencia rápida y MTU estable, pero muchas apps y sesiones TCP se reiniciarán en un cambio de ruta. Si “sin interrupción” es un requisito, estás en el terreno de la resiliencia a nivel de aplicación y balanceo de carga.

9) ¿Qué puertos debemos abrir para una configuración típica?

Depende. Comúnmente: IPsec usa UDP 500 y UDP 4500 (más ESP si no hay NAT-T). WireGuard usa un solo puerto UDP que elijas (a menudo 51820). Luego tus puertos internos permitidos son decisión de política, no un requisito de la VPN.

10) ¿Es seguro tratar dos oficinas como una sola red confiable si el tráfico está encriptado?

No. La encriptación protege los datos en tránsito; no te protege de un dispositivo comprometido al otro lado. Segmenta, restringe y registra. Asume brecha, porque la realidad ya lo hace.

Próximos pasos que no te avergonzarán después

1. Escribe el plan IP y prohíbe solapamientos. Si ya tienes solapamientos, planifica la renumeración en lugar de “NAT temporal para siempre”.
2. Elige túneles enrutados con prefijos permitidos claros. Evita la extensión L2 a menos que disfrutes del dolor.
3. Elige IPsec (IKEv2) o WireGuard según lo que puedas operar, no lo que diga una presentación de vendor.
4. Decide split vs full tunnel deliberadamente. Por defecto, split. Full tunnel solo con una razón.
5. Haz que el DNS sea local en cada sitio, con reenvío/replicación. Prueba la resolución durante una simulación de caída de WAN.
6. Arregla MTU/MSS temprano y valida con pings DF y transferencias reales. “Hace ping” no es un plan de pruebas.
7. Añade monitorización que refleje el dolor del usuario: DNS, TCP, pérdida/latencia, no solo “túnel arriba”.
8. Prueba la conmutación como si lo pensaras en serio. Luego documenta qué se rompe (las sesiones pueden reiniciarse) para que la dirección no se sorprenda luego.

Si haces esto en orden, tendrás una VPN sitio a sitio que se comporta como infraestructura adulta: aburrida, predecible y solo emocionante en las formas que tú elijas.