A JConsole csatlakozik a registryhez, aztán az RMI máshová küldi

Csatlakozz a registry portjához a tunnelen keresztül, figyeld, ahogy elkezdődik a kézfogás, majd figyeld, ahogy a JConsole mégis időtúllépéssel leáll. Ez azért történik, mert az első TCP-kapcsolat nem a felügyeleti kapcsolat: hanem egy keresés. Az RMI registry egy hivatkozással válaszol, amely egy gazdagépet és egy második portot nevez meg, és a JConsole ezután oda megy, ahová küldték. Ha a tunnel csak a szerver első portját éri el, vagy a hivatkozás olyan címet nevez meg, amely csak a szerver saját LAN-ján létezik, a kliens a látszólagos siker után elakad.

A mítosz: egy nyitott port egy kapcsolat

A távoli JMX az RMI felett legalább két végpontot érint, és ezeket a rendszer különböző részei választják ki. A registry portja az, amit a kliensbe beírsz, és azért létezik, hogy kiadja azt a stubbot, amely a tényleges connectort írja le. Ha az első sikeres socketet bizonyítéknak tekinted arra, hogy a felügyeleti útvonal nyitva van, a kétperces diagnózis egy délutáni tűzfalkéréssé válik.

A kliens saját hibáját figyeld, ne a szerver hallgatóinak listáját. A kézfogás kezdete utáni hiba azt mondja, hogy a második kapcsolat nem fejeződött be, nem az első.

Mit ad vissza a registry

A stub egy címet és egy portot tartalmaz, abban a pillanatban szerializálva, amikor a connector létrejött. Egy több interfésszel rendelkező szerveren a stack olyan címet választhatott, amely a helyi hálózatról elérhető, a tiédről nem. A kliens nem ismeri a különbséget; egyszerűen a kapott értéket tárcsázza, és a csomag azt az útvonalat követi, amely az adott címhez létezik, VPN-kliensen pedig gyakran semmilyet. Ebben a pillanatban próbálkozik a második kapcsolat.

Ez az oka annak is, hogy a hiba környezetenként szórványosan jelentkezik: ugyanaz a szerver másképp viselkedhet a LAN-on lévő felhasználó és a tunnelben lévő felhasználó számára, anélkül hogy a JMX konfiguráció bármit is változna.

Két port és két tulajdonság, amely rögzíti őket

A registry portja a com.sun.management.jmxremote.port-ból származik, a connector pedig a com.sun.management.jmxremote.rmi.port-gyel rögzíthető, ahelyett hogy a stackre bíznád. Mindkettőt állítsd be kifejezetten, ha tűzfal vagy biztonsági csoport van a kliens és a szerver között, mert egy kiszámíthatatlan második portot nem lehet előre engedélyezni, és az érte megnyitott széles tartomány rosszabb, mint egyetlen rögzített érték.

Ezután a szerveren a ss -ltn vagy a netstat -an segítségével igazold, hogy mindkét port figyel, és mely címeken. A loopbackhez kötött hallgató helyes a tisztán helyi telepítéshez, és hasznavehetetlen ehhez.

Amikor a hirdetett név rossz

A távoli hivatkozásban megjelenő gazdagépnevet a java.rmi.server.hostname állítja be. Ez befolyásolja, hogy a stub mit hirdet; önmagában nem utasítás arra, hogy minden hallgatót egy interfészhez kössön, ezért beállítása nem mindig hozza a várt egyportos viselkedést. Állítsd be, indítsd újra a folyamatot, majd ellenőrizd, mit tartalmaz valójában a stub. Válassz olyan nevet vagy címet, amelyet a kliens fel tud oldani és a tunnelen keresztül el tud érni, és indítsd újra a folyamatot, hogy a stub újra felépüljön.

A konténerhálózatok ezt rontják, mert a folyamat által látott cím belső lehet, amelyhez a konténeren kívülről semmi nem tud útvonalat adni. Tegyél közzé kifejezetten egy szándékolt gazdagépnevet, ahelyett hogy a platformra bíznád a választást.

Ha SSH-val tunnelözöl VPN helyett, ugyanaz a probléma más köntösben jelenik meg: csak a registry portjának továbbítása esetén a második végpont olyan címre mutat, amelyet a kliensed nem ér el. Továbbítsd mindkét portot, és érd el, hogy a hirdetett név olyasmire oldódjon fel, amit a kliens helyben elér.

Ne kapcsold ki a felügyeleti biztonságot az egyszerűsítés kedvéért

A hitelesítést és a TLS-t kikapcsoló részletek könnyen megtalálhatók, és olyan módon működtetik a kapcsolatot, amelyet később vissza kell vonnod. A távoli JMX olyan felügyeleti felület, amelynek ugyanazok a jogosultságai, mint az általa vizsgált folyamatnak; tartsd meg a hozzáférés-vezérlését, és ha a kliens nem tud hitelesítő adatokat bemutatni, azt javítsd inkább.

Ha a végpontok rendben vannak, őrizd meg a következő hibát, amelyet látsz. A truststore vagy a fiók elutasítása későbbi szakasz, mint egy elérhetetlen connector, és azt jelenti, hogy a hálózati munka elkészült.