JConsole łączy się z rejestrem, a potem RMI wysyła ją gdzie indziej

Połącz się przez tunel z portem rejestru, popatrz, jak zaczyna się uzgadnianie, a potem popatrz, jak JConsole mimo to kończy się przekroczeniem czasu. Dzieje się tak, ponieważ pierwsze połączenie TCP nie jest połączeniem zarządzającym: to wyszukiwanie. Rejestr RMI odpowiada referencją, która wskazuje hosta i drugi port, a JConsole idzie potem tam, gdzie jej powiedziano. Jeśli tunel dociera tylko do pierwszego portu serwera albo referencja wskazuje adres, który istnieje wyłącznie w lokalnej sieci samego serwera, klient zawiesza się po pozornym sukcesie.

Mit: jeden otwarty port to jedno połączenie

Zdalny JMX przez RMI obejmuje co najmniej dwa punkty końcowe i wybierają je różne części systemu. Port rejestru to ten, który wpisujesz w kliencie, i istnieje po to, by wydać stub opisujący rzeczywisty konektor. Jeśli pierwszy udany socket uznasz za dowód, że ścieżka zarządzania jest otwarta, dwuminutowa diagnoza zamienia się w całe popołudnie zgłoszeń do firewalla.

Patrz na błąd samego klienta, a nie na listę nasłuchujących na serwerze. Błąd po rozpoczęciu uzgadniania mówi ci, że nie ukończono drugiego połączenia, a nie pierwszego.

Co zwraca rejestr

Stub zawiera adres i port zserializowane w momencie utworzenia konektora. Na serwerze z kilkoma interfejsami stos mógł wybrać adres osiągalny z sieci lokalnej i nieosiągalny z twojej. Klient nie zna różnicy; po prostu wybiera otrzymaną wartość, a pakiet podąża trasą, która istnieje dla tego adresu, a na kliencie VPN często nie istnieje żadna. To jest moment, w którym podejmowana jest druga próba połączenia.

To także powód, dla którego błąd występuje nieregularnie w różnych środowiskach: ten sam serwer może zachowywać się inaczej dla użytkownika w sieci lokalnej i dla użytkownika w tunelu, bez żadnej zmiany w konfiguracji JMX.

Dwa porty i dwie właściwości, które je przypinają

Port rejestru pochodzi z com.sun.management.jmxremote.port, a konektor można przypiąć za pomocą com.sun.management.jmxremote.rmi.port zamiast zostawiać go temu, co przydzieli stos. Ustaw oba jawnie, gdy między klientem a serwerem jest firewall lub grupa zabezpieczeń, ponieważ nieprzewidywalnego drugiego portu nie można zezwolić z góry, a szeroki zakres otwarty z jego powodu jest gorszy niż jeden stały port.

Następnie potwierdź za pomocą ss -ltn lub netstat -an na serwerze, że oba porty nasłuchują i na jakich adresach. Nasłuchujący związany z loopbackiem jest właściwy dla wdrożenia wyłącznie lokalnego i bezużyteczny dla tego.

Gdy ogłoszona nazwa jest błędna

Nazwę hosta w zdalnej referencji ustawia java.rmi.server.hostname. Wpływa na to, co ogłasza stub; sama w sobie nie jest poleceniem przypisania każdego nasłuchującego do jednego interfejsu, dlatego jej ustawienie nie zawsze daje oczekiwane zachowanie z jednym portem. Ustaw ją, uruchom proces ponownie i sprawdź, co stub faktycznie zawiera. Wybierz nazwę lub adres, który klient może rozwiązać i osiągnąć przez tunel, i uruchom proces ponownie, aby stub został zbudowany od nowa.

Sieci kontenerów pogarszają to, ponieważ adres widziany przez proces może być wewnętrzny i nieroutowalny z zewnątrz kontenera. Publikuj zamierzoną nazwę hosta jawnie, zamiast pozwalać platformie wybierać.

Jeśli tunelujesz przez SSH zamiast VPN, ten sam problem pojawia się w innym przebraniu: przekierowanie tylko portu rejestru zostawia drugi punkt końcowy wskazujący na adres, którego twój klient nie osiągnie. Przekieruj oba porty i spraw, aby ogłoszona nazwa rozwiązywała się na coś, co klient osiągnie lokalnie.

Nie wyłączaj zabezpieczeń zarządzania, żeby to uprościć

Fragmenty wyłączające uwierzytelnianie i TLS łatwo znaleźć i sprawiają, że połączenie działa w sposób, który będziesz musiał później cofnąć. Zdalny JMX to interfejs zarządzający o tych samych uprawnieniach co proces, który kontroluje; zachowaj jego mechanizmy kontroli dostępu, a jeśli klient nie może przedstawić poświadczeń, napraw właśnie to.

Gdy punkty końcowe są poprawne, zachowaj następny błąd, który zobaczysz. Odrzucenie przez magazyn zaufania lub konto to późniejszy etap niż nieosiągalny konektor i oznacza, że praca sieciowa jest skończona.