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 ಎಂಬುದು ಅದು ಪರಿಶೀಲಿಸುವ ಪ್ರಕ್ರಿಯೆಗೆ ಸಮಾನವಾದ ಸವಲತ್ತುಗಳಿರುವ ನಿರ್ವಹಣಾ ಇಂಟರ್ಫೇಸ್; ಅದರ ಪ್ರವೇಶ ನಿಯಂತ್ರಣಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ, ಕ್ಲೈಂಟ್ ರುಜುವಾತುಗಳನ್ನು ಒದಗಿಸಲಾಗದಿದ್ದರೆ ಅದನ್ನೇ ಸರಿಪಡಿಸಿ.

ತುದಿ ಬಿಂದುಗಳು ಸರಿಯಾದ ನಂತರ, ಮುಂದೆ ನೀವು ನೋಡುವ ದೋಷವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಟ್ರಸ್ಟ್ ಸ್ಟೋರ್ ಅಥವಾ ಖಾತೆಯಿಂದ ನಿರಾಕರಣೆ ತಲುಪಲಾಗದ ಸಂಪರ್ಕಕಕ್ಕಿಂತ ನಂತರದ ಹಂತ, ಅಂದರೆ ಜಾಲದ ಕೆಲಸ ಮುಗಿದಿದೆ.