JConsole रजिस्ट्री से जुड़ता है, फिर RMI उसे कहीं और भेज देता है

टनल के ज़रिए रजिस्ट्री पोर्ट से जुड़ें, हैंडशेक शुरू होते देखें और फिर देखें कि JConsole फिर भी टाइम आउट हो जाता है। ऐसा इसलिए होता है क्योंकि पहला TCP कनेक्शन मैनेजमेंट कनेक्शन नहीं है: वह एक लुकअप है। RMI रजिस्ट्री एक रेफ़रेंस के साथ जवाब देती है जिसमें एक होस्ट और दूसरा पोर्ट होता है, और JConsole फिर वहीं जाता है जहाँ उसे भेजा गया था। अगर टनल सिर्फ़ सर्वर के पहले पोर्ट तक पहुँचता है, या रेफ़रेंस ऐसा पता बताता है जो सिर्फ़ सर्वर के अपने लोकल नेटवर्क में मौजूद है, तो क्लाइंट कामयाबी के आभास के बाद अटक जाता है।

मिथक: एक खुला पोर्ट एक कनेक्शन है

RMI के ज़रिए रिमोट JMX में कम से कम दो एंडपॉइंट होते हैं, और उन्हें सिस्टम के अलग-अलग हिस्से चुनते हैं। रजिस्ट्री पोर्ट वही है जो आप क्लाइंट में लिखते हैं, और वह उस stub को देने के लिए मौजूद है जो असली कनेक्टर का ब्यौरा देता है। पहले कामयाब सॉकेट को इस बात का सबूत मानना कि मैनेजमेंट का रास्ता खुला है, दो मिनट के निदान को फ़ायरवॉल टिकटों से भरी पूरी दोपहर में बदल देता है।

सर्वर की सुनने वालों की सूची के बजाय खुद क्लाइंट की गलती देखें। हैंडशेक शुरू होने के बाद की विफलता बताती है कि दूसरा कनेक्शन पूरा नहीं हुआ, पहला नहीं।

रजिस्ट्री क्या लौटाती है

stub में एक पता और पोर्ट होता है, जो उस पल क्रमबद्ध किए गए जब कनेक्टर बनाया गया था। कई इंटरफ़ेस वाले सर्वर पर स्टैक ने ऐसा पता चुना हो सकता है जो लोकल नेटवर्क से पहुँच में हो और आपके नेटवर्क से न हो। क्लाइंट अंतर नहीं जानता; वह बस मिली हुई वैल्यू डायल करता है, और पैकेट उस पते के लिए मौजूद रास्ते पर चलता है, जो VPN क्लाइंट पर अक्सर कोई नहीं होता। यही वह पल है जब दूसरा कनेक्शन आज़माया जाता है।

यही वजह है कि विफलता अलग-अलग माहौल में रुक-रुक कर होती है: वही सर्वर JMX कॉन्फ़िगरेशन में बिना कोई बदलाव किए लोकल नेटवर्क के उपयोगकर्ता और टनल के उपयोगकर्ता के लिए अलग बर्ताव कर सकता है।

दो पोर्ट और दो प्रॉपर्टी जो उन्हें तय करती हैं

रजिस्ट्री पोर्ट com.sun.management.jmxremote.port से आता है, और कनेक्टर को स्टैक के तय किए हुए पर छोड़ने के बजाय com.sun.management.jmxremote.rmi.port से तय किया जा सकता है। जब क्लाइंट और सर्वर के बीच फ़ायरवॉल या सिक्योरिटी ग्रुप हो तो दोनों स्पष्ट रूप से सेट करें, क्योंकि अनिश्चित दूसरे पोर्ट को पहले से अनुमति नहीं दी जा सकती, और उसे समेटने के लिए खोली गई चौड़ी रेंज एक ही मान तय करने से बदतर है।

फिर सर्वर पर ss -ltn या netstat -an से पुष्टि करें कि दोनों पोर्ट सुन रहे हैं और किन पतों पर। loopback से बंधा सुनने वाला सिर्फ़ लोकल डिप्लॉयमेंट के लिए सही है और इसके लिए बेकार है।

जब घोषित नाम गलत हो

रिमोट रेफ़रेंस में दिखने वाला होस्ट नाम java.rmi.server.hostname तय करता है। यह उस बात पर असर डालता है जो stub घोषित करता है; अपने आप में यह हर सुनने वाले को एक इंटरफ़ेस से बाँधने का निर्देश नहीं है, इसलिए इसे सेट करना हमेशा अपेक्षित एक-पोर्ट बर्ताव नहीं देता। इसे सेट करें, प्रोसेस फिर से चलाएँ और फिर जाँचें कि stub में असल में क्या है। ऐसा नाम या पता चुनें जिसे क्लाइंट हल कर सके और टनल के ज़रिए पहुँच सके, और प्रोसेस फिर से चलाएँ ताकि stub फिर से बने।

कंटेनर नेटवर्क इसे और बिगाड़ते हैं, क्योंकि प्रोसेस को दिखने वाला पता अंदरूनी हो सकता है जिसे कंटेनर के बाहर से कोई रूट नहीं कर सकता। प्लेटफ़ॉर्म को चुनने देने के बजाय इच्छित होस्ट नाम स्पष्ट रूप से प्रकाशित करें।

अगर आप VPN के बजाय SSH से टनल बना रहे हैं तो वही समस्या दूसरे रूप में दिखती है: सिर्फ़ रजिस्ट्री पोर्ट आगे भेजने से दूसरा एंडपॉइंट ऐसे पते की ओर इशारा करता रह जाता है जहाँ आपका क्लाइंट नहीं पहुँच सकता। दोनों पोर्ट आगे भेजें और सुनिश्चित करें कि घोषित नाम ऐसी चीज़ में हल हो जहाँ क्लाइंट लोकल रूप से पहुँच सके।

आसान बनाने के लिए मैनेजमेंट सिक्योरिटी बंद न करें

प्रमाणीकरण और TLS बंद करने वाले स्निपेट आसानी से मिल जाते हैं और कनेक्शन को ऐसे चलाते हैं जिसे बाद में वापस करना पड़ेगा। रिमोट JMX एक मैनेजमेंट इंटरफ़ेस है जिसके वही अधिकार हैं जो उस प्रोसेस के हैं जिसकी वह जाँच करता है; उसके एक्सेस कंट्रोल बनाए रखें, और अगर क्लाइंट क्रेडेंशियल नहीं दे सकता तो उसे ठीक करें।

एंडपॉइंट सही होने के बाद, अगली गलती जो आप देखें उसे सहेज लें। ट्रस्ट स्टोर या अकाउंट का इनकार न पहुँचने वाले कनेक्टर से बाद का चरण है और इसका मतलब है कि नेटवर्क का काम पूरा हो गया।