¿Un cliente de WireGuard no puede llegar a un cliente de OpenVPN?

Ambos túneles se conectan, cada cliente alcanza la puerta de enlace, y en el momento en que uno prueba la dirección del otro los paquetes desaparecen. Nada falla en ninguno de los dos handshakes, y ninguna cantidad de reemisión de claves lo cambia. La puerta de enlace transporta paquetes IP normales sin cifrar entre dos de sus propias interfaces, así que los protocolos nunca necesitan entenderse entre sí; lo que necesitan son tres cosas que ningún handshake proporciona. Cobertura de destino en el cliente de origen, propiedad del origen en la puerta de enlace y un camino de vuelta en el lado remoto. El síntoma es el mismo para las tres, por eso se diagnostican juntas.

Al síntoma le falta una pieza a la vez

Este diseño usa un pool de WireGuard 10.71.0.0/24 en wg1 y un pool de OpenVPN 10.72.0.0/24 en tun1, ambos terminando en una sola puerta de enlace. La petición en pruebas va de 10.71.0.5 a HTTPS en 10.72.0.30. Cada paso de abajo trata de ese único flujo. Cada comprobación tiene una firma de fallo distinta aunque el usuario las vive igual, y normalmente solo falta una de las tres a la vez.

Empieza confirmando que ambos pools están realmente en esta puerta de enlace y que el reenvío está activado en el espacio de nombres donde viven los túneles. Una puerta de enlace que termina ambos protocolos en espacios de nombres distintos no reenvía nada entre ellos, y merece la pena descartarlo antes de leer cualquier configuración de par.

Amplía la cobertura de destino del nodo radial

En el cliente de WireGuard, la entrada de par existente tiene que seleccionar la puerta de enlace para el destino de OpenVPN, lo que significa que el prefijo de destino debe aparecer en la lista permitida de ese par. Añadirlo no crea un segundo túnel; cambia qué par elige el cliente cuando busca esa dirección, y con wg-quick la ruta normalmente sigue la lista de forma automática.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Deja intactas las líneas reales de clave y punto final, y recuerda que un gestor que use Table = off no toma ninguna ruta de esta lista. En ese caso el mismo prefijo tiene que instalarlo en la tabla de rutas del sistema quien lo posea, y una ruta que falte allí se ve exactamente igual que un prefijo permitido que falta.

Mantén la propiedad del origen en la puerta de enlace

La entrada de par de este cliente en la puerta de enlace debe seguir poseyendo exactamente la dirección de origen de ese cliente. Las direcciones permitidas se comprueban en ambos sentidos: eligen un par para el tráfico saliente y validan que el origen de un paquete entrante pertenece al par que lo envió. Poner el pool de OpenVPN en la entrada del nodo radial porque el nodo radial quiere alcanzarlo es el error que manda el tráfico hacia el participante equivocado.

AllowedIPs = 10.71.0.5/32

Lee esa entrada como una declaración de propiedad y no como una comodidad de enrutamiento. Todo lo demás a lo que el cliente deba llegar pertenece a la lista de destinos del cliente, no a la idea que la puerta de enlace tiene de lo que este par puede enviar.

Dale al lado de OpenVPN una ruta de vuelta

El objetivo necesita ahora una ruta de vuelta hacia el origen de WireGuard, y para los clientes de pool normalmente llega como una ruta empujada desde el servidor de OpenVPN. Empújala solo a los clientes que deban tenerla, y confirma en el cliente que se aceptó en lugar de suponer que la directiva se aplicó.

push "route 10.71.0.0 255.255.255.0"

La distribución de rutas no es autorización. Cuando el destino está detrás de otro cliente de OpenVPN en lugar de dentro del pool, la propiedad de la propia LAN de ese cliente y sus requisitos de reenvío se suman al diseño, y la ruta empujada es solo la primera mitad. Reformula el requisito como un grafo antes de añadir directivas: qué nodo posee qué prefijo y qué nodo reenvía hacia él.

Permite solo el servicio que querías permitir

Con el reenvío activado y ambos pools enrutables, la pregunta que queda es de política. Escribe la regla para el flujo concreto y no para el par de interfaces en general, previsualízala antes de aplicarla y mantén el camino de vuelta con estado para que las respuestas no se bloqueen como conexiones nuevas. Una prueba en seco no cuesta nada y muestra exactamente qué se añadiría.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Estas son reglas de tráfico reenviado, distintas de las reglas de escucha de la puerta de enlace para los dos servicios VPN. Abrir los puertos UDP exteriores no autoriza la petición interior, y autorizar la petición interior no exige SSH sin restricciones a la puerta de enlace ni un permiso por defecto en el reenvío. El cortafuegos propio del objetivo y la dirección de escucha también tienen que coincidir, ya que un servicio ligado a loopback rechaza el paquete mejor enrutado. Una política que solo cubre un sentido de la conversación suele fallar con una petición correcta y una respuesta silenciosa, que es el resultado más confuso de los tres.

Las rutas recíprocas suelen significar que no hace falta traducción de origen, lo que conserva la dirección de WireGuard en el objetivo y hace legibles los registros. No añadas un enmascaramiento general porque haya dos protocolos implicados, y no quites una regla de traducción existente sin saber qué depende de ella. Después verifica el único flujo de extremo a extremo, y prueba también una fuente o un puerto no permitidos: un handshake que funciona en cada lado no demuestra ni la ruta cruzada ni el aislamiento.