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 מרחוק הוא ממשק ניהול עם אותן הרשאות כמו התהליך שהוא בודק; שמור על בקרות הגישה שלו, ואם הלקוח לא יכול להציג אישורים, תקן את זה במקום.

כשנקודות הקצה נכונות, שמור את השגיאה הבאה שתראה. דחייה מאחסון אמון או מחשבון היא שלב מאוחר יותר ממחבר בלתי נגיש ומשמעותה שעבודת הרשת הסתיימה.