JConsole se connecte au registre, puis RMI l'envoie ailleurs

Connectez-vous au port du registre à travers le tunnel, regardez la poignée de main commencer, puis regardez JConsole expirer quand même. Cela se produit parce que la première connexion TCP n'est pas la connexion de gestion : c'est une recherche. Le registre RMI répond par une référence qui nomme un hôte et un second port, et JConsole se rend ensuite là où on lui a dit d'aller. Si le tunnel n'atteint que le premier port du serveur, ou si la référence nomme une adresse qui n'existe que sur le LAN du serveur lui-même, le client se bloque après avoir apparemment réussi.

Le mythe : un port ouvert, c'est une connexion

JMX distant sur RMI implique au moins deux points de terminaison, et ils sont choisis par des parties différentes du système. Le port du registre est celui que vous saisissez dans le client, et il existe pour distribuer le stub qui décrit le connecteur réel. Prendre la première socket réussie comme preuve que le chemin de gestion est ouvert, c'est ce qui transforme un diagnostic de deux minutes en un après-midi de tickets pare-feu.

Regardez l'erreur du client lui-même plutôt que la liste d'écoute du serveur. Une défaillance après le début de la poignée de main vous dit que la seconde connexion, pas la première, ne s'est pas terminée.

Ce que le registre renvoie

Le stub contient une adresse et un port, sérialisés au moment où le connecteur a été créé. Sur un serveur à plusieurs interfaces, la pile a peut-être choisi une adresse joignable depuis le réseau local et injoignable depuis le vôtre. Le client ne connaît pas la différence ; il compose simplement la valeur qu'on lui a donnée, et le paquet suit la route qui existe pour cette adresse, souvent aucune sur un client VPN. C'est le moment où la seconde connexion est tentée.

C'est aussi pourquoi la défaillance est intermittente selon l'environnement : le même serveur peut se comporter différemment pour un utilisateur sur le LAN et pour un utilisateur sur le tunnel, sans aucun changement de la configuration JMX.

Deux ports et deux propriétés qui les fixent

Le port du registre vient de com.sun.management.jmxremote.port, et le connecteur peut être fixé avec com.sun.management.jmxremote.rmi.port au lieu d'être laissé à ce que la pile alloue. Définissez les deux explicitement quand un pare-feu ou un groupe de sécurité se trouve entre le client et le serveur, car un second port imprévisible ne peut pas être autorisé à l'avance, et une plage large ouverte pour l'accueillir est pire que de fixer une seule valeur.

Confirmez ensuite avec ss -ltn ou netstat -an sur le serveur que les deux ports écoutent et sur quelles adresses. Un écouteur lié à loopback est correct pour un déploiement purement local et inutile pour celui-ci.

Quand le nom annoncé est faux

Le nom d'hôte qui apparaît dans la référence distante est défini par java.rmi.server.hostname. Il influence ce que le stub annonce ; ce n'est pas en soi une instruction de lier chaque écouteur à une seule interface, et c'est pourquoi le définir ne produit pas toujours le comportement à un seul port attendu. Définissez-le, redémarrez le processus, puis vérifiez ce que contient réellement le stub. Choisissez un nom ou une adresse que le client peut résoudre et atteindre à travers le tunnel, et redémarrez le processus pour que le stub soit reconstruit.

Les réseaux de conteneurs aggravent cela, car l'adresse que voit le processus peut être interne et non routable depuis l'extérieur du conteneur. Publiez explicitement le nom d'hôte voulu au lieu de laisser la plateforme choisir.

Si vous faites le tunnel avec SSH plutôt qu'avec un VPN, le même problème apparaît sous un autre déguisement : ne transférer que le port du registre laisse le second point de terminaison pointer vers une adresse que votre client ne peut pas atteindre. Transférez les deux ports et faites en sorte que le nom annoncé se résolve vers quelque chose que le client peut atteindre localement.

Ne désactivez pas la sécurité de gestion pour simplifier

Les extraits qui désactivent l'authentification et TLS sont faciles à trouver et font fonctionner la connexion d'une manière que vous devrez annuler plus tard. JMX distant est une interface de gestion dotée des mêmes privilèges que le processus qu'elle inspecte ; conservez ses contrôles d'accès, et si le client ne peut pas présenter d'identifiants, corrigez cela à la place.

Une fois les points de terminaison corrects, conservez la prochaine erreur que vous voyez. Un rejet du truststore ou du compte est une étape ultérieure à un connecteur injoignable et signifie que le travail réseau est terminé.