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 एउटा व्यवस्थापन इन्टरफेस हो जसको त्यही अधिकार छ जो यसले निरीक्षण गर्ने प्रक्रियाको छ; यसको पहुँच नियन्त्रण राख्नुहोस्, र ग्राहकले प्रमाणपत्र पेस गर्न सकेन भने त्यही ठीक गर्नुहोस्।

अन्त्यबिन्दु ठीक भएपछि अर्को देखिने त्रुटि सुरक्षित राख्नुहोस्। ट्रस्ट स्टोर वा खाताबाट अस्वीकृति नपुग्ने कनेक्टरभन्दा पछिको चरण हो र यसको अर्थ सञ्जालको काम सकिएको हो।