JConsole はレジストリに接続したのに、RMI が別の場所へ送ってしまう

トンネル経由でレジストリのポートに接続し、ハンドシェイクが始まるのを眺め、それでも JConsole がタイムアウトするのを見てください。こうなるのは、最初の TCP接続が管理用の接続ではなく検索だからです。RMI レジストリはホストと二つ目のポートを名指す参照を返し、JConsole はその指示された場所へ向かいます。トンネルがサーバーの一つ目のポートにしか届かない場合、あるいは参照がサーバー自身の LAN にしか存在しないアドレスを指す場合、クライアントは成功したように見えた後に止まります。

神話：開いているポート一つで接続一つ

RMI経由のリモート JMX には少なくとも二つのエンドポイントが関わり、それらはシステムの別々の部分が選びます。レジストリのポートはクライアントに入力するもので、実際のコネクタを記述したスタブを渡すために存在します。最初に成功したソケットを管理経路が開いた証拠とみなすことが、二分で終わる診断をファイアウォール申請で埋まった半日に変えます。

サーバーのリスナー一覧ではなく、クライアント自身のエラーを見てください。ハンドシェイクが始まった後の失敗は、一つ目ではなく二つ目の接続が完了しなかったことを告げています。

レジストリが返すもの

スタブにはアドレスとポートが含まれ、コネクタが作られた瞬間にシリアライズされています。複数のインターフェースを持つサーバーでは、スタックがローカルネットワークからは届き、あなたの側からは届かないアドレスを選んでいることがあります。クライアントは違いを知らず、与えられた値をそのままダイヤルし、パケットはそのアドレスに存在する経路をたどりますが、VPN クライアントでは経路がまったくないこともよくあります。二つ目の接続が試されるのはその瞬間です。

同じサーバーが、JMX の設定を一切変えていないのに、LAN上のユーザーとトンネル上のユーザーで違う振る舞いをすることがあるのも、これが理由です。

二つのポートと、それを固定する二つのプロパティ

レジストリのポートは com.sun.management.jmxremote.port から来て、コネクタはスタックの割り当てに任せず com.sun.management.jmxremote.rmi.port で固定できます。クライアントとサーバーの間にファイアウォールやセキュリティグループがある場合は両方を明示的に設定してください、予測できない二つ目のポートは事前に許可できず、それを収めるために広い範囲を開けるのは一つの値を固定するより悪いからです。

次にサーバー上で ss -ltn か netstat -an を使い、両方のポートが待ち受けていることと、どのアドレスで待ち受けているかを確認します。loopback に束縛されたリスナーはローカル専用の配備には正しく、この用途では役に立ちません。

通知された名前が間違っているとき

リモート参照に現れるホスト名は java.rmi.server.hostname で設定します。これはスタブが何を通知するかに影響しますが、それ自体がすべてのリスナーを一つのインターフェースに束縛する指示ではないため、設定しても期待した単一ポートの動作になるとは限りません。設定したらプロセスを再起動し、スタブに実際に何が入っているかを確認します。クライアントが解決でき、トンネル経由で到達できる名前かアドレスを選び、スタブが作り直されるようプロセスを再起動します。

コンテナのネットワークは、プロセスが見るアドレスが内部向けで、コンテナの外からは誰もルーティングできないことがあるため、これを悪化させます。プラットフォームに任せず、意図したホスト名を明示的に公開してください。

VPN ではなく SSH でトンネルを張る場合も、レジストリのポートだけを転送すると二つ目のエンドポイントがクライアントの到達できないアドレスを指したままになるという同じ問題が別の姿で現れます。両方のポートを転送し、通知された名前がクライアントからローカルに到達できるものに解決されるようにしてください。

簡単にするために管理用のセキュリティを無効にしない

認証と TLS を切るスニペットはすぐ見つかり、後で元に戻さなければならない形で接続を通してしまい、リモート JMX はそれが検査するプロセスと同じ権限を持つ管理インターフェースです。アクセス制御は維持し、クライアントが資格情報を提示できないなら、そちらを直してください。

エンドポイントが正しくなったら、次に目にするエラーを保存しておいてください。トラストストアやアカウントによる拒否は、到達できないコネクタより後の段階であり、ネットワークの作業は終わったという意味です。