JConsole kết nối tới registry, rồi RMI gửi nó đi nơi khác

Kết nối tới cổng registry qua đường hầm, xem bắt tay bắt đầu, rồi xem JConsole vẫn hết thời gian chờ. Điều đó xảy ra vì kết nối TCP đầu tiên không phải kết nối quản trị: nó là một lần tra cứu. Registry RMI trả lời bằng một tham chiếu nêu tên một máy chủ và một cổng thứ hai, và JConsole sau đó đi tới bất cứ đâu được bảo. Nếu đường hầm chỉ tới được cổng đầu tiên của máy chủ, hoặc tham chiếu nêu một địa chỉ chỉ tồn tại trên LAN của chính máy chủ, máy khách sẽ đứng sau khi có vẻ đã thành công.

Huyền thoại: một cổng mở là một kết nối

JMX từ xa qua RMI liên quan ít nhất hai điểm cuối, và chúng được chọn bởi những phần khác nhau của hệ thống. Cổng registry là thứ bạn gõ vào máy khách, và nó tồn tại để trao stub mô tả connector thật. Coi socket thành công đầu tiên là bằng chứng rằng đường quản trị đã mở chính là điều biến một chẩn đoán hai phút thành cả buổi chiều đầy phiếu firewall.

Hãy nhìn lỗi của chính máy khách thay vì danh sách trình lắng nghe của máy chủ. Thất bại sau khi bắt tay bắt đầu cho bạn biết kết nối thứ hai, không phải kết nối đầu tiên, chưa hoàn tất.

Registry trả lại gì

Stub chứa một địa chỉ và một cổng, được tuần tự hóa vào lúc connector được tạo. Trên máy chủ có nhiều giao diện, ngăn xếp có thể đã chọn một địa chỉ tiếp cận được từ mạng cục bộ và không tiếp cận được từ mạng của bạn. Máy khách không biết sự khác biệt; nó chỉ quay số tới giá trị mình nhận được, và gói tin đi theo tuyến đường tồn tại cho địa chỉ đó, mà trên máy khách VPN thường không có tuyến nào. Đó là lúc kết nối thứ hai được thử.

Đây cũng là lý do thất bại xuất hiện chập chờn giữa các môi trường: cùng một máy chủ có thể hành xử khác nhau với người dùng trong LAN và người dùng trên đường hầm, mà không có thay đổi nào trong cấu hình JMX.

Hai cổng và hai thuộc tính ghim chúng lại

Cổng registry đến từ com.sun.management.jmxremote.port, và connector có thể được ghim bằng com.sun.management.jmxremote.rmi.port thay vì để ngăn xếp cấp phát. Đặt cả hai một cách rõ ràng khi có tường lửa hoặc nhóm bảo mật giữa máy khách và máy chủ, vì một cổng thứ hai không đoán trước được thì không thể cho phép trước, và một dải rộng mở ra để chứa nó còn tệ hơn ghim một giá trị.

Sau đó xác nhận bằng ss -ltn hoặc netstat -an trên máy chủ rằng cả hai cổng đang lắng nghe và trên địa chỉ nào. Một trình lắng nghe gắn với loopback là đúng cho triển khai chỉ cục bộ và vô dụng cho trường hợp này.

Khi tên được quảng cáo là sai

Tên máy chủ xuất hiện trong tham chiếu từ xa do java.rmi.server.hostname đặt. Nó ảnh hưởng tới điều stub quảng cáo; bản thân nó không phải chỉ dẫn gắn mọi trình lắng nghe vào một giao diện, nên việc đặt nó không phải lúc nào cũng tạo ra hành vi một cổng như mong đợi. Hãy đặt nó, khởi động lại tiến trình, rồi kiểm tra xem stub thực sự chứa gì. Chọn một tên hoặc địa chỉ mà máy khách có thể phân giải và tiếp cận qua đường hầm, và khởi động lại tiến trình để stub được dựng lại.

Mạng container làm điều này tệ hơn, vì địa chỉ mà tiến trình nhìn thấy có thể là địa chỉ nội bộ mà không gì bên ngoài container định tuyến tới được. Hãy công bố tên máy chủ dự định một cách rõ ràng thay vì để nền tảng chọn.

Nếu bạn tạo đường hầm bằng SSH thay vì VPN, vấn đề tương tự hiện ra trong một lớp áo khác: chỉ chuyển tiếp cổng registry để điểm cuối thứ hai trỏ tới một địa chỉ mà máy khách của bạn không tiếp cận được. Hãy chuyển tiếp cả hai cổng và làm cho tên được quảng cáo phân giải tới thứ máy khách tiếp cận được cục bộ.

Đừng tắt bảo mật quản trị để đơn giản hóa

Các đoạn mã tắt xác thực và TLS rất dễ tìm và làm kết nối hoạt động theo cách bạn sẽ phải hoàn tác sau này. JMX từ xa là một giao diện quản trị có cùng đặc quyền như tiến trình mà nó kiểm tra; hãy giữ các kiểm soát truy cập của nó, và nếu máy khách không thể xuất trình thông tin đăng nhập, hãy sửa điều đó thay vì thế.

Khi các điểm cuối đã đúng, hãy giữ lại lỗi tiếp theo bạn thấy. Việc bị từ chối bởi truststore hoặc tài khoản là giai đoạn muộn hơn so với connector không tiếp cận được và nghĩa là công việc mạng đã xong.