¿Pueden los clientes de dos servidores OpenVPN alcanzarse entre sí?

Levantar un segundo OpenVPN servidor le da un segundo lugar donde los clientes pueden conectarse, y nada más. No coloca a esos clientes en la red del primer servidor, y la opción llamada client-to-client solo cambia el reenvío dentro de un único proceso de servidor. Los dos grupos se convierten en una red cuando enruta entre ellos a propósito, con un responsable para cada dirección. Todo lo siguiente supone el modo TUN en espacio de usuario con ese reenvío interno desactivado, de modo que el núcleo toma la decisión.

El mito: una lista de cuentas, una red

Autenticación y alcance se confunden porque ambos viven en la configuración del servidor. Un usuario que puede iniciar sesión en cualquiera de las dos pasarelas parece, desde fuera, un usuario de un solo sistema con dos puertas. Dentro, cada servidor reparte direcciones de su propio grupo e instala rutas solo para los clientes que termina. Así, un cliente en la pasarela A que envía un paquete a un cliente en la pasarela B pide un destino del que su propio servidor nunca ha oído hablar. El paquete va a la ruta predeterminada de A, sale del túnel y llega a un cortafuegos al que nunca se le pidió permitirlo.

Añadir un segundo servidor, por tanto, no añade redundancia, descubrimiento ni un dominio de difusión compartido. Añade una red enrutada que necesita un plan, y el plan empieza por el direccionamiento.

Dé a cada pasarela su propio grupo y dirección de tránsito

Dos rangos que no pueden solaparse con nada más, más un pequeño enlace de tránsito entre los hosts, son todo el plan de direcciones. Mantenga el tránsito en un segmento privado que controle, y anote los números antes de que ningún servidor entregue un arrendamiento.

Resista la tentación de dar a ambos servidores el mismo grupo para que los perfiles sigan idénticos. Una ruta del núcleo no puede decir cuál de dos hosts posee ahora una dirección arbitraria dentro de un rango compartido, así que la tabla de enrutamiento apuntaría a una pasarela y el cliente podría estar conectado a la otra. Los nombres de interfaz son convenciones locales, no estado compartido. Ambos hosts aquí llaman al dispositivo de túnel tun0 y al enlace de tránsito transit0, lo cual está bien porque ningún paquete lleva esos nombres.

Instale la ruta en ambos lados

Cada pasarela necesita una ruta para el grupo de la otra a través de la dirección de tránsito, y el reenvío debe estar activo para que cualquiera actúe como salto. Confirme primero la tabla actual, luego añada la entrada y hágalo persistente mediante el gestor de red del host en lugar de un gancho de reconexión.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Refleje eso en el otro host con los grupos intercambiados. Añadir repetidamente la misma ruta desde un script no relacionado es como un host acaba con varias copias y un cambio misterioso la próxima vez que alguien lee la tabla. Si el enlace de tránsito es a su vez un túnel, la ruta apunta a la topología de ese túnel y el salto debe sobrevivir a su reconexión. Una dirección de tránsito que desaparece durante treinta segundos se lleva consigo el camino entre grupos, lo que es una propiedad de diseño que conviene declarar en lugar de descubrir.

Empuje la ruta del cliente sin falsificar la propiedad

Los clientes necesitan una ruta hacia el grupo remoto, si no su propio sistema operativo envía el paquete a su pasarela predeterminada y el túnel nunca lo ve. La configuración del servidor es el lugar natural para entregarla.

push "route 10.64.20.0 255.255.255.0"

Ponga la línea espejo en la configuración del otro servidor, luego reconecte un cliente de prueba y lea su tabla. Un cliente que ignora las rutas empujadas necesita su propia configuración aprobada, y una ruta que nunca llega no es un control de acceso. No dé a un cliente un iroute para todo el grupo de la otra pasarela. Esa directiva existe para una subred detrás de un cliente conectado, y usarla para tapar una ruta ausente entre pasarelas produce un servidor que cree poseer direcciones que no puede alcanzar.

Demuestre una petición y rechace otra

Elija una operación real, por ejemplo HTTPS desde un cliente en 10.64.10.21 hacia un servicio en 10.64.20.37, y permita exactamente eso en ambos hosts. Cada cortafuegos admite la petición en su lado de entrada y la respuesta rastreada en el lado de retorno; la política de servicio del destino todavía tiene que aceptarla.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Con rutas recíprocas, el NAT de origen es innecesario y aquí activamente dañino: traducir el origen oculta qué cliente hizo la petición y derrota la política basada en origen del lado del destino. Compruebe que una regla de masquerade existente para la salida a internet no captura también este camino. Luego pruebe el rechazo. Un servicio que debe quedarse local en el grupo B debe seguir inalcanzable desde el grupo A, y las parejas de clientes de la misma pasarela también necesitan prueba, ya que la política de reenvío que acaba de cambiar también les afecta.

Una corrección más al modelo mental: el enlace de tránsito lleva paquetes internos descifrados, así que es un límite de confianza y no una garantía privada. Si cruza una red que no controla, proteja ese salto con un túnel cifrado aprobado y enrute por su topología real. El TLS de extremo a extremo sigue autenticando la aplicación por su cuenta, y por eso el servicio interno debe seguir usándolo.