เชื่อมต่อพอร์ตรีจิสทรีผ่านอุโมงค์ ดูแฮนด์เชคเริ่มต้น แล้วดูว่า 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 ระยะไกลเป็นอินเทอร์เฟซการจัดการที่มีสิทธิ์เท่ากับโปรเซสที่มันตรวจสอบ รักษาการควบคุมการเข้าถึงไว้ และถ้าไคลเอนต์ไม่สามารถแสดงข้อมูลรับรองได้ ให้แก้ตรงนั้นแทน

เมื่อปลายทางถูกต้องแล้ว ให้เก็บข้อผิดพลาดถัดไปที่คุณเห็น การถูกปฏิเสธจากทรัสต์สโตร์หรือบัญชีเป็นขั้นตอนหลังจากคอนเนกเตอร์ที่เข้าถึงไม่ได้ และหมายความว่างานเครือข่ายเสร็จแล้ว

บทความที่เกี่ยวข้อง