JConsole เชื่อมต่อรีจิสทรี แล้ว RMI ก็ส่งต่อไปที่อื่น
การที่พอร์ตรีจิสทรีตอบกลับเป็นเพียงก้าวแรกเท่านั้น เซิร์ฟเวอร์ JMX ระยะไกลอาจประกาศโฮสต์อื่นและพอร์ตคอนเนกเตอร์อื่น และอุโมงค์ต้องเข้าถึงทั้งสอง
เชื่อมต่อพอร์ตรีจิสทรีผ่านอุโมงค์ ดูแฮนด์เชคเริ่มต้น แล้วดูว่า JConsole หมดเวลาไปทั้งอย่างนั้น สิ่งนี้เกิดขึ้นเพราะการเชื่อมต่อ TCP ครั้งแรกไม่ใช่การเชื่อมต่อสำหรับการจัดการ แต่เป็นการค้นหา รีจิสทรี RMI ตอบกลับด้วยเรฟเฟอเรนซ์ที่ระบุโฮสต์และพอร์ตที่สอง แล้ว JConsole ก็ไปยังที่ที่ถูกบอก ถ้าอุโมงค์ไปถึงเพียงพอร์ตแรกของเซิร์ฟเวอร์ หรือเรฟเฟอเรนซ์ระบุที่อยู่ที่มีอยู่เฉพาะใน LAN ของเซิร์ฟเวอร์เอง ไคลเอนต์จะค้างหลังจากดูเหมือนสำเร็จ
ความเชื่อผิด ๆ: พอร์ตเปิดหนึ่งพอร์ตคือการเชื่อมต่อหนึ่งครั้ง
JMX ระยะไกลผ่าน RMI เกี่ยวข้องกับปลายทางอย่างน้อยสองจุด และถูกเลือกโดยส่วนต่าง ๆ ของระบบ การใช้พอร์ตรีจิสทรีคือสิ่งที่คุณพิมพ์ในไคลเอนต์ และมันมีอยู่เพื่อแจก stub ที่อธิบายคอนเนกเตอร์จริง การถือว่าโซเก็ตแรกที่สำเร็จเป็นหลักฐานว่าเส้นทางจัดการเปิดอยู่คือสิ่งที่เปลี่ยนการวินิจฉัยสองนาทีให้เป็นบ่ายทั้งบ่ายที่เต็มไปด้วยตั๋วไฟร์วอลล์
ดูข้อผิดพลาดของไคลเอนต์เองแทนรายชื่อผู้ฟังของเซิร์ฟเวอร์ ความล้มเหลวหลังแฮนด์เชคเริ่มต้นบอกคุณว่าการเชื่อมต่อที่สองไม่ได้เสร็จ ไม่ใช่ครั้งแรก
รีจิสทรีส่งอะไรกลับมา
stub มีที่อยู่และพอร์ตที่ถูกทำให้เป็นอนุกรม ณ ขณะที่สร้างคอนเนกเตอร์ บนเซิร์ฟเวอร์ที่มีหลายอินเทอร์เฟซ สแต็กอาจเลือกที่อยู่ที่เข้าถึงได้จากเครือข่ายท้องถิ่นและเข้าถึงไม่ได้จากเครือข่ายของคุณ ไคลเอนต์ไม่รู้ความแตกต่าง มันเพียงเรียกค่าที่ได้รับ และแพ็กเก็ตก็ไปตามเส้นทางที่มีอยู่สำหรับที่อยู่นั้น ซึ่งบนไคลเอนต์ VPN มักไม่มีเลย นั่นคือช่วงเวลาที่มีการพยายามเชื่อมต่อครั้งที่สอง
นี่คือเหตุผลที่ความล้มเหลวเกิดขึ้นเป็นครั้งคราวต่างกันไปตามสภาพแวดล้อม เซิร์ฟเวอร์เดียวกันอาจทำงานต่างกันสำหรับผู้ใช้ใน LAN และผู้ใช้ในอุโมงค์ โดยไม่มีการเปลี่ยนแปลงการตั้งค่า 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 ระยะไกลเป็นอินเทอร์เฟซการจัดการที่มีสิทธิ์เท่ากับโปรเซสที่มันตรวจสอบ รักษาการควบคุมการเข้าถึงไว้ และถ้าไคลเอนต์ไม่สามารถแสดงข้อมูลรับรองได้ ให้แก้ตรงนั้นแทน
เมื่อปลายทางถูกต้องแล้ว ให้เก็บข้อผิดพลาดถัดไปที่คุณเห็น การถูกปฏิเสธจากทรัสต์สโตร์หรือบัญชีเป็นขั้นตอนหลังจากคอนเนกเตอร์ที่เข้าถึงไม่ได้ และหมายความว่างานเครือข่ายเสร็จแล้ว