Qué es una VPN site-to-site

Una VPN tradicional de usuario final (road warrior) conecta un dispositivo individual a una red. Una VPN site-to-site va más allá: conecta redes enteras entre sí, como si estuvieran en el mismo cable. Es el tipo de VPN que usan las empresas para unir una oficina con otra, o un VPS con el datacenter corporativo, sin que cada máquina necesite instalar nada.

Casos de uso típicos

• Conectar dos oficinas en ciudades distintas para compartir impresoras, archivos y ERP.
• Enlazar un VPS con la red interna de una empresa para que las apps en la nube accedan al ERP local.
• Integrar un entorno de desarrollo en la nube con la red de staging on-premise.
• Unir múltiples datacenters para replicar bases de datos sin exponerlas a internet.

Topología

La idea central es simple: dos routers (o dos servidores haciendo de router) en cada extremo mantienen un túnel permanente. Todo el tráfico entre las subredes pasa por ese túnel, cifrado. El resto de las máquinas en cada red ni se enteran de la VPN: solo ven que pueden alcanzar IPs que antes no existían para ellos.

Normalmente cada lado tiene una subred distinta: por ejemplo, oficina A en 10.10.0.0/24 y oficina B en 10.20.0.0/24. El túnel hace que cualquier host de A pueda hablar con cualquier host de B usando esas IPs privadas.

Rutas: el punto crítico

Lo que define que funcione o no es el enrutamiento. En cada router debes decirle que para llegar a la subred del otro lado, el next hop es la interfaz del túnel. Con WireGuard esto se declara en AllowedIPs; con OpenVPN se usa push "route ..." o configuración manual.

Si olvidas rutas en los equipos finales (no solo en los routers), puede que los pings funcionen en un sentido pero no en el otro. Es el bug más común al debuggear site-to-site.

NAT: cuándo sí y cuándo no

Si las subredes son distintas y no se superponen, no necesitas NAT: los paquetes viajan con sus IPs reales y todo fluye. Pero si accidentalmente ambos lados usan el mismo rango (algo así como 192.168.1.0/24 en los dos), tienes un problema serio: no hay forma de distinguirlos. La solución es renumerar uno de los lados, o en casos extremos aplicar NAT en el túnel para traducir.

Split tunneling vs full tunnel

En site-to-site casi siempre usarás split tunneling: solo el tráfico hacia las subredes del otro lado va por la VPN. El tráfico hacia internet sigue saliendo por el gateway normal de cada oficina. Es más eficiente y más simple. El full tunnel (todo el tráfico del sitio A sale a internet por el sitio B) solo tiene sentido si necesitas filtrar salida centralizada.

Peer review de la configuración

Antes de poner en producción, pide a alguien más que revise tu archivo de configuración. Los errores típicos son: llaves mal copiadas, AllowedIPs que se solapan, puertos bloqueados por firewall, o un IP forwarding deshabilitado (net.ipv4.ip_forward = 1 en sysctl).

Troubleshooting básico

1. Verifica que el túnel esté arriba: sudo wg show o systemctl status openvpn.
2. Haz ping de router a router por las IPs del túnel.
3. Luego ping de router a un host del otro lado.
4. Finalmente ping de host a host.

Si falla en el paso 3 es problema de rutas; si falla en el 4 es firewall o NAT en el host final. Ir paso por paso ahorra horas.