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 हे मॅनेजमेंट इंटरफेस आहे ज्याला ते तपासत असलेल्या प्रोसेसइतकेच अधिकार आहेत; त्याचे प्रवेश नियंत्रण ठेवा, आणि क्लायंट क्रेडेन्शियल्स देऊ शकत नसेल तर ते दुरुस्त करा।

एंडपॉइंट बरोबर झाल्यावर पुढील जी त्रुटी दिसेल ती जपून ठेवा। ट्रस्ट स्टोअर किंवा खात्याकडून नकार हा पोहोच न होणाऱ्या कनेक्टरपेक्षा नंतरचा टप्पा आहे आणि त्याचा अर्थ नेटवर्कचे काम संपले आहे।