JConsole ansluter till registret och sedan skickar RMI den någon annanstans

Anslut till registry-porten genom tunneln, se handskakningen börja och se sedan JConsole få timeout ändå. Det händer för att den första TCP-anslutningen inte är hanteringsanslutningen: det är en uppslagning. RMI-registret svarar med en referens som anger en värd och en andra port, och JConsole går sedan dit den blir skickad. Om tunneln bara når serverns första port, eller om referensen anger en adress som bara finns i serverns eget LAN, hänger klienten efter att den till synes lyckats.

Myten: en öppen port är en anslutning

Fjärr-JMX över RMI omfattar minst två ändpunkter, och de väljs av olika delar av systemet. Registry-porten är den du skriver in i klienten, och den finns för att lämna ut den stub som beskriver den faktiska connectorn. Att ta den första lyckade socketen som bevis på att hanteringsvägen är öppen förvandlar en tvåminutersdiagnos till en eftermiddag av brandväggsärenden.

Titta på klientens eget fel i stället för serverns lyssnarlista. Ett fel efter att handskakningen börjat säger att den andra anslutningen, inte den första, inte slutfördes.

Vad registret lämnar tillbaka

Stubben innehåller en adress och en port, serialiserade när connectorn skapades. På en server med flera gränssnitt kan stacken ha valt en adress som går att nå från det lokala nätet och inte från ditt. Klienten vet inte skillnaden; den ringer helt enkelt det värde den fick, och paketet följer den väg som finns för adressen, vilket på en VPN-klient ofta är ingen alls. Det är i det ögonblicket den andra anslutningen försöks.

Det är också därför felet är intermittent mellan miljöer: samma server kan bete sig olika för en användare i LAN och en användare i tunneln, utan att JMX-konfigurationen ändras alls.

Två portar och två egenskaper som låser dem

Registry-porten kommer från com.sun.management.jmxremote.port, och connectorn kan låsas med com.sun.management.jmxremote.rmi.port i stället för att lämnas till vad stacken tilldelar. Ange båda uttryckligen när det finns en brandvägg eller säkerhetsgrupp mellan klienten och servern, för en oförutsägbar andra port kan inte tillåtas i förväg, och ett brett intervall som öppnas för att rymma den är värre än att låsa ett värde.

Bekräfta sedan med ss -ltn eller netstat -an på servern att båda portarna lyssnar och på vilka adresser. En lyssnare bunden till loopback är rätt för en helt lokal driftsättning och värdelös för den här.

När det annonserade namnet är fel

Värdnamnet som visas i fjärrreferensen sätts av java.rmi.server.hostname. Det påverkar vad stubben annonserar; det är i sig ingen instruktion att binda varje lyssnare till ett gränssnitt, vilket är varför det inte alltid ger det förväntade beteendet med en enda port. Sätt det, starta om processen och verifiera sedan vad stubben faktiskt innehåller. Välj ett namn eller en adress som klienten kan slå upp och nå genom tunneln, och starta om processen så att stubben byggs om.

Container-nätverk gör det värre, eftersom adressen som processen ser kan vara en intern sådan som ingenting utanför containern kan routa. Publicera det avsedda värdnamnet uttryckligen i stället för att låta plattformen välja.

Om du tunnlar med SSH i stället för ett VPN dyker samma problem upp i en annan skepnad: att bara vidarebefordra registry-porten lämnar den andra ändpunkten pekande mot en adress som din klient inte kan nå. Vidarebefordra båda portarna och se till att det annonserade namnet löser upp till något klienten kan nå lokalt.

Stäng inte av hanteringssäkerheten för att förenkla

Snippets som stänger av autentisering och TLS är lätta att hitta och får anslutningen att fungera på ett sätt som du måste ångra senare. Fjärr-JMX är ett hanteringsgränssnitt med samma privilegier som processen det inspekterar; behåll dess åtkomstkontroller, och om klienten inte kan visa upp autentiseringsuppgifter, åtgärda det i stället.

När ändpunkterna är korrekta, spara nästa fel du ser. En avvisning från ett truststore eller konto är ett senare steg än en onåbar connector och betyder att nätverksarbetet är klart.