JConsole es connecta al registre i després RMI l'envia a un altre lloc

Connecta't al port del registre a través del túnel, mira com comença l'apretada de mans i després observa com JConsole fa temps d'espera igualment. Això passa perquè la primera connexió TCP no és la connexió de gestió: és una consulta. El registre RMI respon amb una referència que nomena un amfitrió i un segon port, i JConsole va després on se li ha indicat. Si el túnel només arriba al primer port del servidor, o si la referència nomena una adreça que només existeix a la LAN del mateix servidor, el client es bloqueja després d'haver semblat tenir èxit.

El mite: un port obert és una connexió

JMX remot sobre RMI implica almenys dos extrems, i els trien parts diferents del sistema. El port del registre és el que escrius al client, i existeix per lliurar l'stub que descriu el connector real. Agafar el primer socket amb èxit com a prova que la ruta de gestió és oberta és el que converteix un diagnòstic de dos minuts en una tarda de tiquets de tallafocs.

Fixa't en l'error del mateix client en lloc de la llista d'escoltes del servidor. Una fallada després que comenci l'apretada de mans et diu que la segona connexió, no la primera, no es va completar.

Què retorna el registre

L'stub conté una adreça i un port, serialitzats en el moment en què es va crear el connector. En un servidor amb diverses interfícies, la pila pot haver triat una adreça abastable des de la xarxa local i no des de la teva. El client no coneix la diferència; simplement marca el valor que se li va donar, i el paquet segueix la ruta que existeixi per a aquesta adreça, que en un client VPN sovint no és cap. Aquest és el moment en què s'intenta la segona connexió.

És també la raó que la fallada sigui intermitent entre entorns: el mateix servidor es pot comportar de manera diferent per a un usuari a la LAN i un altre al túnel, sense cap canvi a la configuració de JMX.

Dos ports i dues propietats que els fixen

El port del registre ve de com.sun.management.jmxremote.port, i el connector es pot fixar amb com.sun.management.jmxremote.rmi.port en lloc de deixar-lo al que assigni la pila. Defineix tots dos explícitament quan hi hagi un tallafocs o un grup de seguretat entre el client i el servidor, perquè un segon port impredictible no es pot permetre per endavant, i un rang ampli obert per acomodar-lo és pitjor que fixar un sol valor.

Confirma després amb ss -ltn o netstat -an al servidor que tots dos ports estan escoltant i en quines adreces. Un listener lligat a loopback és correcte per a un desplegament només local i inútil per a aquest.

Quan el nom anunciat és incorrecte

El nom d'amfitrió que apareix a la referència remota el fixa java.rmi.server.hostname. Afecta el que anuncia l'stub; no és en si mateix una instrucció de lligar tots els listeners a una interfície, i per això fixar-lo no sempre produeix el comportament d'un sol port que la gent espera. Fixa'l, reinicia el procés i verifica després què conté realment l'stub. Tria un nom o adreça que el client pugui resoldre i abastar a través del túnel, i reinicia el procés perquè l'stub es reconstrueixi.

Les xarxes de contenidors ho empitjoren, perquè l'adreça que veu el procés pot ser una d'interna a la qual res fora del contenidor pot encaminar. Publica el nom d'amfitrió previst explícitament en lloc de deixar que la plataforma triï.

Si fas el túnel amb SSH en lloc d'una VPN, el mateix problema apareix amb una altra disfressa: reenviar només el port del registre deixa el segon extrem apuntant a una adreça que el teu client no pot abastar. Reenvia tots dos ports i fes que el nom anunciat resolgui a una cosa que el client pugui abastar localment.

No desactivis la seguretat de gestió per simplificar-ho

Els fragments que desactiven l'autenticació i TLS són fàcils de trobar i fan que la connexió funcioni d'una manera que hauràs de desfer més tard. JMX remot és una interfície de gestió amb els mateixos privilegis que el procés que inspecciona; mantén els seus controls d'accés i, si el client no pot presentar credencials, arregla-ho en canvi.

Quan els extrems siguin correctes, conserva el següent error que vegis. Un rebuig del truststore o del compte és una etapa posterior a un connector inabastable i significa que la feina de xarxa ha acabat.