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 ایک مینجمنٹ انٹرفیس ہے جس کے وہی اختیارات ہیں جو اس عمل کے ہیں جس کا وہ معائنہ کرتا ہے؛ اس کے رسائی کنٹرول برقرار رکھیں، اور اگر کلائنٹ اسناد پیش نہیں کر سکتا تو اسے ٹھیک کریں۔

جب اینڈ پوائنٹس درست ہو جائیں تو اگلی غلطی محفوظ رکھیں جو آپ دیکھیں۔ ٹرسٹ اسٹور یا اکاؤنٹ کا انکار ناقابل رسائی کنیکٹر سے بعد کا مرحلہ ہے اور اس کا مطلب ہے کہ نیٹ ورک کا کام مکمل ہو گیا۔