JConsole se připojí k registru a pak ji RMI pošle jinam

Připojte se tunelem k portu registru, sledujte, jak začíná handshake, a pak sledujte, jak JConsole přesto vyprší časový limit. Děje se to proto, že první TCP spojení není řídicí spojení: je to vyhledání. Registr RMI odpoví referencí, která uvádí hostitele a druhý port, a JConsole pak jde tam, kam jí bylo řečeno. Pokud tunel dosáhne jen prvního portu serveru nebo reference uvádí adresu, která existuje jen v místní síti samotného serveru, klient se zasekne poté, co to vypadalo na úspěch.

Mýtus: jeden otevřený port je jedno spojení

Vzdálený JMX přes RMI zahrnuje nejméně dva koncové body a vybírají je různé části systému. Port registru je ten, který zadáváte do klienta, a existuje proto, aby vydal stub, jenž popisuje skutečný konektor. Pokud první úspěšný socket považujete za důkaz, že cesta správy je otevřená, dvouminutová diagnóza se změní v celé odpoledne firewallových tiketů.

Sledujte chybu samotného klienta, ne seznam naslouchajících na serveru. Selhání po začátku handshaku vám říká, že se nedokončilo druhé spojení, ne první.

Co registr vrací

Stub obsahuje adresu a port serializované v okamžiku, kdy byl konektor vytvořen. Na serveru s několika rozhraními mohl stack zvolit adresu dostupnou z místní sítě a nedostupnou z vaší. Klient rozdíl nezná; prostě volá hodnotu, kterou dostal, a paket sleduje trasu, která pro danou adresu existuje, na VPN klientovi často žádnou. To je okamžik, kdy se pokouší druhé spojení.

To je také důvod, proč je selhání mezi prostředími občasné: stejný server se může chovat jinak pro uživatele v místní síti a pro uživatele v tunelu, aniž by se jakkoli změnila konfigurace JMX.

Dva porty a dvě vlastnosti, které je fixují

Port registru pochází z com.sun.management.jmxremote.port a konektor lze zafixovat pomocí com.sun.management.jmxremote.rmi.port místo toho, aby se nechal na tom, co přidělí stack. Nastavte oba explicitně, když je mezi klientem a serverem firewall nebo bezpečnostní skupina, protože nepředvídatelný druhý port nelze povolit předem a široký rozsah otevřený kvůli němu je horší než jeden pevný port.

Potom pomocí ss -ltn nebo netstat -an na serveru ověřte, že oba porty naslouchají a na kterých adresách. Naslouchající proces vázaný na loopback je správný pro čistě lokální nasazení a pro toto je k ničemu.

Když je ohlášené jméno špatné

Jméno hostitele ve vzdálené referenci nastavuje java.rmi.server.hostname. Ovlivňuje, co stub ohlašuje; samo o sobě není pokynem připoutat každý naslouchající proces k jednomu rozhraní, a proto jeho nastavení ne vždy přinese očekávané chování s jedním portem. Nastavte ho, restartujte proces a potom ověřte, co stub skutečně obsahuje. Zvolte jméno nebo adresu, kterou klient dokáže přeložit a dosáhnout tunelem, a restartujte proces, aby se stub znovu sestavil.

Sítě kontejnerů to zhoršují, protože adresa, kterou proces vidí, může být interní a zvenčí kontejneru nesměrovatelná. Zveřejněte zamýšlené jméno hostitele explicitně místo toho, abyste volbu nechali na platformě.

Pokud tunelujete přes SSH místo VPN, stejný problém se objeví v jiném kabátě: přesměrování pouze portu registru nechá druhý koncový bod ukazovat na adresu, kterou váš klient nedosáhne. Přesměrujte oba porty a zařiďte, aby se ohlášené jméno přeložilo na něco, co klient dosáhne lokálně.

Nevypínejte bezpečnost správy, abyste si to zjednodušili

Úryvky, které vypínají autentizaci a TLS, se snadno najdou a přivedou spojení k fungování způsobem, který budete muset později vrátit. Vzdálený JMX je rozhraní pro správu se stejnými oprávněními jako proces, který kontroluje; zachovejte jeho řízení přístupu, a pokud klient nemůže předložit přihlašovací údaje, opravte to.

Když jsou koncové body správné, uchovejte další chybu, kterou uvidíte. Odmítnutí úložiště důvěry nebo účtu je pozdější fází než nedostupný konektor a znamená, že síťová práce je hotová.