JConsole maakt verbinding met de registry, en dan stuurt RMI hem ergens anders heen

Maak via de tunnel verbinding met de registry-poort, kijk hoe de handshake begint en zie dan hoe JConsole alsnog in een time-out loopt. Dat komt doordat de eerste TCP-verbinding niet de beheer-verbinding is, maar een lookup. De RMI-registry antwoordt met een referentie die een host en een tweede poort noemt, en JConsole gaat daarna naar waar hij heen is gestuurd. Als de tunnel alleen de eerste poort van de server bereikt, of als de referentie een adres noemt dat alleen op het eigen LAN van de server bestaat, blijft de client hangen nadat hij schijnbaar geslaagd is.

De mythe: één open poort is één verbinding

Remote JMX via RMI kent minstens twee eindpunten, en die worden door verschillende delen van het systeem gekozen. De registry-poort is wat je in de client typt, en hij bestaat om de stub uit te geven die de eigenlijke connector beschrijft. De eerste geslaagde socket als bewijs zien dat het beheerpad open is, maakt van een diagnose van twee minuten een middag vol firewalltickets.

Kijk naar de fout van de client zelf in plaats van naar de listenerlijst van de server. Een fout nadat de handshake is begonnen, zegt je dat de tweede verbinding niet tot stand kwam, niet de eerste.

Wat de registry teruggeeft

De stub bevat een adres en een poort, geserialiseerd op het moment dat de connector werd aangemaakt. Op een server met meerdere interfaces heeft de stack misschien een adres gekozen dat vanaf het lokale netwerk bereikbaar is en vanaf het jouwe niet. De client kent het verschil niet; hij kiest simpelweg de waarde die hij heeft gekregen, en het pakket volgt de route die voor dat adres bestaat, die op een VPN-client vaak helemaal geen is. Dat is het moment waarop de tweede verbinding wordt geprobeerd.

Dat is ook de reden waarom de fout per omgeving wisselend optreedt: dezelfde server kan zich anders gedragen voor een gebruiker op het LAN en een gebruiker op de tunnel, zonder dat er iets aan de JMX-configuratie verandert.

Twee poorten en twee eigenschappen die ze vastzetten

De registry-poort komt van com.sun.management.jmxremote.port, en de connector kan met com.sun.management.jmxremote.rmi.port worden vastgezet in plaats van aan de stack te worden overgelaten. Zet beide expliciet wanneer er een firewall of security group tussen client en server zit, want een onvoorspelbare tweede poort kun je niet vooraf toestaan, en een breed bereik openzetten om hem te faciliteren is erger dan één vaste waarde.

Controleer daarna met ss -ltn of netstat -an op de server of beide poorten luisteren en op welke adressen. Een listener die aan loopback is gebonden, is correct voor een puur lokale inzet en nutteloos voor deze.

Wanneer de aangekondigde naam verkeerd is

De hostnaam in de externe referentie wordt bepaald door java.rmi.server.hostname. Hij beïnvloedt wat de stub aankondigt; het is op zichzelf geen opdracht om elke listener aan één interface te binden, en daarom levert het instellen ervan niet altijd het verwachte gedrag met één poort op. Stel hem in, herstart het proces en controleer dan wat de stub werkelijk bevat. Kies een naam of adres dat de client kan resolven en via de tunnel kan bereiken, en herstart het proces zodat de stub opnieuw wordt opgebouwd.

Containernetwerken maken dit erger, omdat het adres dat het proces ziet een intern adres kan zijn waar niets buiten de container naartoe kan routeren. Publiceer de bedoelde hostnaam expliciet in plaats van de keuze aan het platform te laten.

Als je in plaats van een VPN een SSH-tunnel gebruikt, verschijnt hetzelfde probleem in een ander jasje: alleen de registry-poort doorsturen laat het tweede eindpunt wijzen naar een adres dat je client niet kan bereiken. Stuur beide poorten door en zorg dat de aangekondigde naam resolvet naar iets wat de client lokaal kan bereiken.

Schakel de beveiliging van het beheer niet uit om het simpel te houden

Snippets die authenticatie en TLS uitzetten, zijn makkelijk te vinden en laten de verbinding werken op een manier die je later moet terugdraaien. Remote JMX is een beheerinterface met dezelfde rechten als het proces dat hij inspecteert; houd de toegangscontroles in stand, en als de client geen inloggegevens kan overleggen, los dat dan op.

Als de eindpunten kloppen, bewaar dan de volgende fout die je ziet. Een afwijzing door een truststore of account komt later dan een onbereikbare connector en betekent dat het netwerkwerk klaar is.