SSH2_MSG_KEX_ECDH_REPLY ನಲ್ಲಿ SSH ನೇತಾಡುತ್ತದೆ: ಯಾವಾಗಲೂ MTU ಅಲ್ಲ

ಸುರಂಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಬ್ಯಾನರ್ ಬರುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೀ ವಿನಿಮಯದ ಉತ್ತರಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವ ಸಂದೇಶವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳು ನೇರವಾಗಿ MTU ಗೆ ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅದು ಸರಿ. ಹೆಚ್ಚಾಗಿ ಅಲ್ಲ: ಉತ್ತರವು ಎಂದಿಗೂ ಕಳುಹಿಸದೇ ಇರಬಹುದು, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಕೀ ಫೈಲ್ ಓದಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಅಥವಾ ಎರಡೂ ತುದಿಗಳು ಅಲ್ಗಾರಿದಮ್ ಬಗ್ಗೆ ಒಪ್ಪಿಕೊಳ್ಳಲಿಲ್ಲ. ಸಾಲು ಕ್ಲೈಂಟ್ ಏನನ್ನು ಕಾಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಕಾಯುವಿಕೆ ಏಕೆ ಪ್ರಾರಂಭವಾಯಿತು ಎಂಬುದನ್ನಲ್ಲ. ಅದನ್ನು ಲಕ್ಷಣವಾಗಿ ಪರಿಗಣಿಸಿ ಮತ್ತು ಯಾವುದೇ ಗಾತ್ರ ಬದಲಾಯಿಸುವ ಮೊದಲು ಮೂರು ಕಾರಣಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ.

ಉತ್ತರವನ್ನು ನಿಜವಾಗಿಯೂ ನಿರೀಕ್ಷಿಸಲಾಗಿತ್ತೇ ಎಂದು ನೋಡಲು ಜಾಡನ್ನು ಓದಿ

ವಿವರವಾದ ಔಟ್ಪುಟ್ ಮೌನಕ್ಕೆ ಮೊದಲು ಕೊನೆಯ ಯಶಸ್ವಿ ಹಂತವನ್ನು ತೋರಿಸುತ್ತದೆ. ಸರ್ವರ್ನ ಪ್ರೋಟೋಕಾಲ್ ಬ್ಯಾನರ್ ಬಂದಿದ್ದರೆ, TCP ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ದೂರದ ತುದಿ ಜೀವಂತವಾಗಿದೆ; ತೆರೆದ ಪ್ರಶ್ನೆ ಎಂದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ಯಾಕೆಟ್ಗೆ ಏನಾಯಿತು. ಬ್ಯಾನರ್ ನಂತರ ಒಂದು ನಿಮಿಷದ ಮೌನವು ಮಾರ್ಗದ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಹೊಂದಿಕೆಯಾಗುವ ಕೀ ವಿನಿಮಯ ವಿಧಾನವಿಲ್ಲ ಎಂಬ ಸಂದೇಶ ನೀತಿಯ ಸಮಸ್ಯೆ. ಸರ್ವರ್ ಸೆಷನ್ ಮುಚ್ಚುವುದರೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ ದೀರ್ಘ ಕಾಯುವಿಕೆ ಎಂದರೆ ಸರ್ವರ್ ಬಿಟ್ಟುಕೊಟ್ಟಿತು, ಮತ್ತು ಅದರ ಲಾಗ್ ಏಕೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ.

ಕೊನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಮುಟ್ಟುವ ಮೊದಲು ಸರ್ವರ್ನ ದೃಢೀಕರಣ ಲಾಗ್ ಓದಿ. ಸರ್ವರ್ ಎಂದಿಗೂ ಕಳುಹಿಸದ ನಿರ್ಧಾರವನ್ನು ಕ್ಲೈಂಟ್ ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಸಣ್ಣ ಉತ್ತರವೂ ಏಕೆ ತುಂಬಾ ದೊಡ್ಡದಾಗಿರಬಹುದು

ಕೀ ವಿನಿಮಯದ ಉತ್ತರಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತುಂಬಾ ಸಣ್ಣವಾಗಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಗಾತ್ರವನ್ನು ದೂಷಿಸುವುದು ತಪ್ಪಾಗಿ ಕೇಳಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ ಉತ್ತರ ಸಣ್ಣದಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಸರ್ವರ್ನ ಪ್ರಮಾಣಪತ್ರ ಸರಣಿಯನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ಇದು ಅದನ್ನು ಸೆಷನ್ನಲ್ಲಿ ಸುರಂಗದ ಬಳಸಬಹುದಾದ ಪೇಲೋಡ್ ಮೀರಬಹುದಾದ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಮಾಡುತ್ತದೆ. ಮಾರ್ಗ MTU ಅನ್ವೇಷಣೆಯ ಪ್ರತಿಕ್ರಿಯೆ ಮಾರ್ಗದಲ್ಲಿ ಎಲ್ಲೋ ಕಳೆದುಹೋದಾಗ, ಕಳುಹಿಸುವವರು ಹಿಡಿಸದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಕಳುಹಿಸುತ್ತಲೇ ಇರುತ್ತಾರೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅದೇ ಸಾಲಿನಲ್ಲಿ ಶಾಶ್ವತವಾಗಿ ಕಾಯುತ್ತದೆ.

ಗಾತ್ರವನ್ನು ಊಹಿಸುವ ಬದಲು ನಿರ್ಧರಿಸಿ. ip link show tun0 ನಿಂದ ಸುರಂಗದ MTU ಓದಿ, ನಂತರ ಒಡೆಯಬಾರದ ಪ್ರೋಬ್ಗಳನ್ನು ಕಳುಹಿಸಿ: ping -4 -M do -s 1352 host, ಸಣ್ಣ ಪೇಲೋಡ್ಗಳೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸಿ. ನಿರ್ದಿಷ್ಟ ಗಾತ್ರದಲ್ಲಿ ವೈಫಲ್ಯದಿಂದ ಯಶಸ್ಸಿಗೆ ಬದಲಾವಣೆ ಸಾಕ್ಷ್ಯ; ಏಕರೂಪದ ವೈಫಲ್ಯ ICMP ಫಿಲ್ಟರ್ ಆಗುತ್ತಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ತಾತ್ಕಾಲಿಕ ಕಡಿತ ಸಿದ್ಧಾಂತವನ್ನು ಬೇಗನೆ ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಶಾಶ್ವತ ಆವೃತ್ತಿ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಅಥವಾ ಸುರಂಗವನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವ ರೌಟರ್ನಲ್ಲಿ MSS ಕ್ಲ್ಯಾಂಪ್ ಆಗಿ ಇರುತ್ತದೆ:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ಗಾತ್ರದ ಸಮಸ್ಯೆಯನ್ನು ಅನುಕರಿಸುವ ಎರಡು ಕಾರಣಗಳು

ಕ್ಲೈಂಟ್ ಓದಲಾಗದ ಕೀ ಫೈಲ್ ಅದೇ ಕಾಯುವಿಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ವಿವರವಾದ ಔಟ್ಪುಟ್ನಲ್ಲೂ ಎಚ್ಚರಿಕೆ ಇಲ್ಲದೆ. known_hosts ನ ಒಂದು ಮಾದರಿ ಇದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ: CA ದ ಸಾರ್ವಜನಿಕ ಕೀಗೆ ತೋರಿಸುವ @cert-authority ನಮೂದು, ಅದನ್ನು ಒಂದೇ ಖಾತೆ ಓದಬಹುದು. ಫೈಲನ್ನು ಹೊಂದಿರುವ ಖಾತೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಉಳಿದ ಪ್ರತಿಯೊಂದು ಖಾತೆಯೂ ನೇತಾಡುತ್ತದೆ. ವೈಫಲ್ಯವು ಹೋಸ್ಟ್ ಬದಲು ಬಳಕೆದಾರರನ್ನು ಅನುಸರಿಸಿದರೆ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಗಳ ಮೊದಲು ಫೈಲ್ ಮೋಡ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ನವೀಕರಣವು ಎರಡೂ ತುದಿಗಳು ಹಿಂದೆ ಹಂಚಿಕೊಂಡ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಸಹ ತೆಗೆದುಹಾಕಬಹುದು. ಸರ್ವರ್ ಇನ್ನೂ ನೀಡುವ ಒಂದು ವಿಧಾನವನ್ನು ರೋಗನಿರ್ಣಯವಾಗಿ ಪಿನ್ ಮಾಡಿ: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. ತಕ್ಷಣ ಯಶಸ್ವಿಯಾಗುವ ಸಂಪರ್ಕ ಮಾರ್ಗ ಸರಿಯಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ ಎರಡೂ ಬದಿಗಳ ಮಾತುಕತೆ ನೀತಿಗೆ ಸೇರುತ್ತದೆ.

ಬರೆಯಲು ಯೋಗ್ಯವಾದ ಮೂರು ಸಂಗತಿಗಳು

ಯಾವುದೇ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಮತ್ತು ನಂತರ ಸುರಂಗದ MTU, ದೊಡ್ಡ ಫೈಲ್ನ ಪ್ರತಿಯನ್ನು ಪುನರಾವರ್ತಿತ ಗಾತ್ರದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆಯೇ, ಮತ್ತು ಅದೇ ಸುರಂಗದಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರವಿಲ್ಲದ ಹೋಸ್ಟ್ ಸಹ ಅದೇ ರೀತಿ ನೇತಾಡುತ್ತದೆಯೇ ಎಂದು ದಾಖಲಿಸಿ. ಆ ಮೂರು ಅವಲೋಕನಗಳು ಗಾತ್ರವನ್ನು ಅನುಮತಿಗಳಿಂದ ಮತ್ತು ಮಾತುಕತೆಯಿಂದ ಆಜ್ಞೆಗಳ ರಾಶಿಗಿಂತ ವೇಗವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತವೆ.

ಅವು ಮುಂದಿನ ವ್ಯಕ್ತಿಯು ಎಂದಿಗೂ ಗಾತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸದ ದೋಷಕ್ಕಾಗಿ MTU ಕಡಿಮೆ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತವೆ.

ಚಿತ್ರವು ಇನ್ನೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದಿದ್ದರೆ, ಅದೇ ಸುರಂಗದಲ್ಲಿ ಎರಡನೇ ಕ್ಲೈಂಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ. ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್ ದೋಷವನ್ನು ಮಾರ್ಗದಿಂದ ಮೊದಲ ಯಂತ್ರದ ಸಂರಚನೆಗೆ ಸ್ಥಳಾಂತರಿಸುತ್ತದೆ.