JConsole se conecta al registro y entonces RMI la envía a otro sitio

Conéctate al puerto del registro a través del túnel, observa cómo empieza la negociación y luego mira cómo JConsole agota el tiempo de espera igualmente. Eso ocurre porque la primera conexión TCP no es la conexión de gestión: es una consulta. El registro RMI responde con una referencia que nombra un host y un segundo puerto, y JConsole va entonces adonde se le ha indicado. Si el túnel solo alcanza el primer puerto del servidor, o si la referencia nombra una dirección que solo existe en la LAN del propio servidor, el cliente se queda bloqueado después de haber parecido tener éxito.

El mito: un puerto abierto es una conexión

JMX remoto sobre RMI implica al menos dos extremos, y los eligen partes distintas del sistema. El puerto del registro es el que escribes en el cliente, y existe para entregar el stub que describe el conector real. Tomar el primer socket exitoso como prueba de que la ruta de gestión está abierta es lo que convierte un diagnóstico de dos minutos en una tarde de tickets de firewall.

Fíjate en el error del propio cliente en lugar de en la lista de escuchas del servidor. Un fallo después de que empiece la negociación te dice que la segunda conexión, no la primera, no se completó.

Qué devuelve el registro

El stub contiene una dirección y un puerto, serializados en el momento en que se creó el conector. En un servidor con varias interfaces, la pila puede haber elegido una dirección alcanzable desde la red local e inalcanzable desde la tuya. El cliente no conoce la diferencia; simplemente marca el valor que se le dio, y el paquete sigue la ruta que exista para esa dirección, que en un cliente VPN a menudo no es ninguna. Ese es el momento en que se intenta la segunda conexión.

Es también la razón de que el fallo sea intermitente entre entornos: el mismo servidor puede comportarse de forma distinta para un usuario en la LAN y otro en el túnel, sin ningún cambio en la configuración de JMX.

Dos puertos y dos propiedades que los fijan

El puerto del registro viene de com.sun.management.jmxremote.port, y el conector puede fijarse con com.sun.management.jmxremote.rmi.port en lugar de dejarlo a lo que asigne la pila. Define ambos explícitamente cuando haya un firewall o un grupo de seguridad entre el cliente y el servidor, porque un segundo puerto impredecible no se puede permitir de antemano, y un rango amplio abierto para acomodarlo es peor que fijar un solo valor.

Confirma después con ss -ltn o netstat -an en el servidor que ambos puertos están escuchando y en qué direcciones. Un listener atado a loopback es correcto para un despliegue solo local e inútil para este.

Cuando el nombre anunciado es incorrecto

El nombre de host que aparece en la referencia remota lo fija java.rmi.server.hostname. Afecta a lo que anuncia el stub; no es en sí mismo una instrucción de atar todos los listeners a una interfaz, y por eso fijarlo no siempre produce el comportamiento de un solo puerto que la gente espera. Fíjalo, reinicia el proceso y verifica después qué contiene realmente el stub. Elige un nombre o dirección que el cliente pueda resolver y alcanzar a través del túnel, y reinicia el proceso para que el stub se reconstruya.

Las redes de contenedores lo empeoran, porque la dirección que ve el proceso puede ser una interna a la que nada fuera del contenedor puede enrutar. Publica el nombre de host previsto explícitamente en lugar de dejar que la plataforma elija.

Si haces el túnel con SSH en lugar de una VPN, el mismo problema aparece con otro disfraz: reenviar solo el puerto del registro deja el segundo extremo apuntando a una dirección que tu cliente no puede alcanzar. Reenvía ambos puertos y haz que el nombre anunciado resuelva a algo que el cliente pueda alcanzar localmente.

No desactives la seguridad de gestión para simplificarlo

Los fragmentos que desactivan la autenticación y TLS son fáciles de encontrar y hacen que la conexión funcione de una manera que tendrás que deshacer más tarde. JMX remoto es una interfaz de gestión con los mismos privilegios que el proceso que inspecciona; mantén sus controles de acceso y, si el cliente no puede presentar credenciales, arréglalo en su lugar.

Cuando los extremos sean correctos, conserva el siguiente error que veas. Un rechazo del truststore o de la cuenta es una etapa posterior a un conector inalcanzable y significa que el trabajo de red ha terminado.