JConsole conecta co rexistro e despois RMI mándaa a outro sitio

Conéctate á porta do rexistro a través do túnel, observa como comeza a negociación e despois mira como JConsole caduca igualmente. Isto ocorre porque a primeira conexión TCP non é a conexión de xestión: é unha consulta. O rexistro RMI responde cunha referencia que nomea un servidor e unha segunda porta, e JConsole vai entón alí onde se lle dixo. Se o túnel só chega á primeira porta do servidor, ou se a referencia nomea un enderezo que só existe na LAN do propio servidor, o cliente queda parado despois de aparentemente ter éxito.

O mito: unha porta aberta é unha conexión

JMX remoto sobre RMI implica polo menos dous extremos, e escóllenos partes distintas do sistema. A porta do rexistro é a que escribes no cliente, e existe para entregar o stub que describe o conector real. Tomar o primeiro socket con éxito como proba de que a ruta de xestión está aberta é o que converte un diagnóstico de dous minutos nunha tarde de tickets de firewall.

Fíxate no erro do propio cliente en lugar da lista de escoitas do servidor. Un fallo despois de comezar a negociación dinos que a segunda conexión, e non a primeira, non se completou.

Que devolve o rexistro

O stub contén un enderezo e unha porta, serializados no momento en que se creou o conector. Nun servidor con varias interfaces, a pila pode ter escollido un enderezo alcanzable desde a rede local e non desde a túa. O cliente non coñece a diferenza; simplemente marca o valor que se lle deu, e o paquete segue a ruta que exista para ese enderezo, que nun cliente VPN moitas veces non é ningunha. Ese é o momento en que se tenta a segunda conexión.

É tamén a razón de que o fallo sexa intermitente entre contornos: o mesmo servidor pode comportarse de forma distinta para un usuario na LAN e outro no túnel, sen ningún cambio na configuración de JMX.

Dúas portas e dúas propiedades que as fixan

A porta do rexistro vén de com.sun.management.jmxremote.port, e o conector pode fixarse con com.sun.management.jmxremote.rmi.port en lugar de deixalo ao que asigne a pila. Define ambas explicitamente cando haxa un firewall ou un grupo de seguridade entre o cliente e o servidor, porque unha segunda porta imprevisible non se pode permitir por adiantado, e un rango amplo aberto para acomodala é peor que fixar un único valor.

Confirma despois con ss -ltn ou netstat -an no servidor que ambas as portas están a escoitar e en que enderezos. Un listener ligado a loopback é correcto para un despregamento só local e inútil para este.

Cando o nome anunciado é incorrecto

O nome de servidor que aparece na referencia remota defíneo java.rmi.server.hostname. Afecta o que anuncia o stub; non é en si mesmo unha instrución de ligar todos os listeners a unha soa interface, e por iso definilo non sempre produce o comportamento dunha soa porta que a xente espera. Defíneo, reinicia o proceso e despois verifica que contén realmente o stub. Escolle un nome ou enderezo que o cliente poida resolver e alcanzar a través do túnel, e reinicia o proceso para que o stub se reconstrua.

As redes de contedores empeoran isto, porque o enderezo que ve o proceso pode ser interno e non encamiñable desde fóra do contedor. Publica explicitamente o nome de servidor previsto en lugar de deixar que a plataforma escolla.

Se fas o túnel con SSH en lugar dunha VPN, o mesmo problema aparece con outra roupa: encamiñar só a porta do rexistro deixa o segundo extremo apuntando a un enderezo que o teu cliente non pode alcanzar. Encamiña as dúas portas e fai que o nome anunciado resolva a algo que o cliente poida alcanzar localmente.

Non desactives a seguridade de xestión para simplificalo

Os fragmentos que desactivan a autenticación e TLS son fáciles de atopar e fan que a conexión funcione dunha maneira que terás que desfacer máis tarde. JMX remoto é unha interface de xestión cos mesmos privilexios que o proceso que inspecciona; mantén os seus controis de acceso e, se o cliente non pode presentar credenciais, arranxa iso no seu lugar.

Cando os extremos sexan correctos, conserva o seguinte erro que vexas. Un rexeitamento do truststore ou da conta é unha etapa posterior a un conector inalcanzable e significa que o traballo de rede rematou.