JConsole به رجیستری وصل می‌شود، بعد RMI آن را جای دیگری می‌فرستد

از طریق تونل به پورت رجیستری متصل شوید، شروع دست‌دادن را تماشا کنید و بعد ببینید که JConsole باز هم به پایان مهلت می‌رسد. این اتفاق می‌افتد چون اولین اتصال TCP اتصال مدیریت نیست: یک جست‌وجو است. رجیستری RMI با ارجاعی پاسخ می‌دهد که یک میزبان و یک پورت دوم را نام می‌برد، و JConsole سپس به هر جا که به آن گفته شده برود می‌رود. اگر تونل فقط به اولین پورت سرور برسد، یا ارجاع آدرسی را نام ببرد که فقط در شبکه محلی خود سرور وجود دارد، کلاینت پس از موفقیت ظاهری متوقف می‌شود.

افسانه: یک پورت باز یک اتصال است

JMX از راه دور روی RMI حداقل دو نقطه پایانی را درگیر می‌کند و بخش‌های مختلف سیستم آن‌ها را انتخاب می‌کنند. پورت رجیستری همان چیزی است که در کلاینت تایپ می‌کنید و برای تحویل 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 بازسازی شود.

شبکه‌های کانتینری این را بدتر می‌کنند، چون آدرسی که فرایند می‌بیند می‌تواند داخلی و از بیرون کانتینر غیرقابل مسیریابی باشد. نام میزبان موردنظر را صریحاً منتشر کنید به‌جای اینکه انتخاب را به پلتفرم بسپارید.

اگر تونل را با SSH به‌جای VPN می‌سازید، همان مشکل با لباس دیگری ظاهر می‌شود: ارسال فقط پورت رجیستری نقطه پایانی دوم را به آدرسی اشاره‌گر می‌گذارد که کلاینت شما نمی‌تواند به آن برسد. هر دو پورت را ارسال کنید و کاری کنید که نام اعلام‌شده به چیزی حل شود که کلاینت به‌صورت محلی به آن می‌رسد.

امنیت مدیریت را برای ساده‌سازی خاموش نکنید

قطعه‌هایی که احراز هویت و TLS را خاموش می‌کنند آسان پیدا می‌شوند و اتصال را به شکلی کار می‌اندازند که بعداً باید برگردانید. JMX از راه دور یک رابط مدیریت با همان اختیارات فرایندی است که بازرسی می‌کند؛ کنترل‌های دسترسی آن را حفظ کنید و اگر کلاینت نمی‌تواند اعتبارنامه ارائه کند، همان را درست کنید.

وقتی نقاط پایانی درست باشند، خطای بعدی را که می‌بینید نگه دارید. رد شدن از سوی truststore یا حساب مرحله‌ای دیرتر از اتصال‌دهنده غیرقابل دسترس است و یعنی کار شبکه تمام شده است.