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 হলো একটি ব্যবস্থাপনা ইন্টারফেস যার একই বিশেষাধিকার রয়েছে যে প্রক্রিয়াটি এটি পরিদর্শন করে তার; এর প্রবেশ নিয়ন্ত্রণ রাখুন, এবং ক্লায়েন্ট যদি প্রমাণপত্র উপস্থাপন করতে না পারে তবে সেটিই ঠিক করুন।

প্রান্তবিন্দুগুলো সঠিক হওয়ার পর, পরবর্তী যে ত্রুটি দেখবেন তা সংরক্ষণ করুন। ট্রাস্ট স্টোর বা অ্যাকাউন্ট থেকে প্রত্যাখ্যান অপ্রাপ্য সংযোগকারীর চেয়ে পরবর্তী ধাপ এবং এর অর্থ নেটওয়ার্কের কাজ শেষ।