ಮರುಬೂಟ್ ನಂತರ SSH ಆಲಿಸುತ್ತಿಲ್ಲ: VPN ವಿಳಾಸ ತಡವಾಗಿ ಬರುತ್ತದೆ

ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ನೀವು SSH ಅನ್ನು ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸುತ್ತೀರಿ, ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಮರುಬೂಟ್ ನಂತರ ಯಾರಾದರೂ ಸೇವೆಯನ್ನು ಕೈಯಿಂದ ಮರುಪ್ರಾರಂಭಿಸುವವರೆಗೆ ಯಾರೂ ಲಾಗಿನ್ ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ರುಜುವಾತುಗಳು ಸಮಸ್ಯೆಯಲ್ಲ. ಡೀಮನ್ ಇನ್ನೂ ಇಲ್ಲದ ವಿಳಾಸವನ್ನು ಕರ್ನೆಲ್‌ನಿಂದ ಕೇಳಿತು, ಬೈಂಡ್ ವಿಫಲವಾಯಿತು, ಮತ್ತು ಸಂದೇಶವು ಬೂಟ್ ಲಾಗ್‌ನಲ್ಲಿ ಜಾರಿಹೋಯಿತು. ದೃಢೀಕರಣ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವುದು ವಾಸ್ತವವಾಗಿ ಪ್ರಾರಂಭ ಕ್ರಮದ ಸಮಸ್ಯೆ.

ಬೈಂಡ್ ದೋಷ ವಾಸ್ತವವಾಗಿ ಏನು ಹೇಳುತ್ತದೆ

ಆಲಿಸುವ ಸಾಕೆಟ್ ಅನ್ನು ಅದೇ ಕ್ಷಣದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಿಳಾಸದಲ್ಲಿ ರಚಿಸಬೇಕು. VPN ಇಂಟರ್ಫೇಸ್ ನಂತರ ಬಂದಾಗ, ಕೇವಲ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಲು ಸಂರಚಿಸಲಾದ ಡೀಮನ್‌ಗೆ ಅಂಟಿಕೊಳ್ಳಲು ಏನೂ ಇಲ್ಲ. ಸಂರಚನೆ ವಾಕ್ಯರಚನೆಯ ದೃಷ್ಟಿಯಿಂದ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ; ಪರಿಸರ ಸಿದ್ಧವಾಗಿರಲಿಲ್ಲ ಅಷ್ಟೆ. ಕೈಯಿಂದ ಪ್ರಾರಂಭದಿಂದ ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇವೆ ಎಂದಿಗೂ ಬೂಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಹೋಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ದೋಷ ಮುಂದಿನ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸುತ್ತದೆ. ವಿಫಲ ಬೈಂಡ್‌ನ ಸಮಯಮುದ್ರೆಯನ್ನು ವಿಳಾಸ ಹಂಚಿಕೆಯ ಸಮಯಮುದ್ರೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ಕ್ರಮ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಸಂರಚನೆಯ ಮಾನ್ಯತೆ ಮತ್ತು ರನ್‌ಟೈಮ್ ಸಿದ್ಧತೆ ಬೇರೆ ಬೇರೆ ಗುಣಲಕ್ಷಣಗಳು. ಎರಡನ್ನೂ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದು ಏನನ್ನೂ ಹೇಳದೆ ವಿಫಲವಾಗುತ್ತದೆ.

ಯಾವ ಪ್ರಕ್ರಿಯೆ ಪೋರ್ಟ್ ಹೊಂದಿದೆ

ಡೀಮನ್ ಯಾವಾಗಲೂ ಕೇಳುಗರನ್ನು ರಚಿಸುವ ಘಟಕವಲ್ಲ. ಸಾಕೆಟ್ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಆ ಜವಾಬ್ದಾರಿಯನ್ನು ಒಂದು ಘಟಕಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ, ಆಗ ಡೀಮನ್ ಮರುಪ್ರಾರಂಭಿಸುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

ಸಾಕೆಟ್ ಪಟ್ಟಿ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಪೋರ್ಟ್ ಅನ್ನು ಮತ್ತು ಯಾವ ವಿಳಾಸದಲ್ಲಿ ಹಿಡಿದಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಘಟಕದ ಡಂಪ್ ಸಾಕೆಟ್ ಘಟಕ ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಇದ್ದಾಗ, ವಿಳಾಸವು ಸಾಕೆಟ್ ಘಟಕಕ್ಕೆ ಸೇರಿದ್ದು ಮತ್ತು ಡೀಮನ್ ಫೈಲ್ ಪ್ರಾಮಾಣಿಕವಲ್ಲ. ರೋಗಲಕ್ಷಣದಿಂದ ಊಹಿಸುವ ಬದಲು ನಿಜವಾದ ಬೈಂಡ್ ದೋಷಕ್ಕಾಗಿ ಬೂಟ್ ಲಾಗ್ ಓದಿ. ಸಾಕೆಟ್ ಘಟಕ ಇಲ್ಲದಿರುವುದು ಸಾಂಪ್ರದಾಯಿಕ ವ್ಯವಸ್ಥೆ, ಅಂದರೆ ಡೀಮನ್ ನೇರವಾಗಿ ಬಂಧಿಸುತ್ತದೆ.

ಸಿದ್ಧತೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸಿ, ನಿದ್ರೆ ಅಲ್ಲ

ಸ್ಥಿರ ವಿಳಂಬವು ವೇಗದ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ನಿಧಾನ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಒಂದೇ ರೀತಿ ಪರಿಗಣಿಸುವ ಊಹೆ. ಬದಲಿಗೆ ಅವಲಂಬನೆಯನ್ನು ವ್ಯಕ್ತಪಡಿಸಿ: ವಿಳಾಸಕ್ಕಾಗಿ ಕಾಯಿರಿ, ನಂತರ ಪ್ರಾರಂಭಿಸಿ.

ip -4 addr show dev tun0
systemctl edit ssh.service

ವಿಳಾಸ ಕಾಣಿಸಿಕೊಳ್ಳುವವರೆಗೆ ಪುನರಾವರ್ತಿಸುವ ExecStartPre ಆಜ್ಞೆಯನ್ನು ಸೇರಿಸಿ, ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ನಿರ್ದಿಷ್ಟ ನೆಟ್‌ವರ್ಕ್ ಗುರಿಯ ನಂತರ ಘಟಕವನ್ನು ಜೋಡಿಸಿ. ಎರಡೂ ವಿಧಾನಗಳು ಅವಲಂಬನೆಯನ್ನು ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಓದಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸುತ್ತವೆ. ಲೂಪ್‌ಗೆ ಸಮಯ ಮಿತಿ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ವಿಫಲ VPN ದೋಷ ವರದಿ ಮಾಡುವ ಬದಲು ನೇತಾಡುವ ಘಟಕವನ್ನು ಬಿಡುತ್ತದೆ. ನಂತರ ಡೀಮನ್ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಇಂಟರ್ಫೇಸ್ ನಿಮ್ಮ ಫಿಲ್ಟರ್ ನಿಯಮಗಳ ಅಡಿಯಲ್ಲಿ ಉಳಿಯುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಸ್ವಚ್ಛ ಬೂಟ್ ಮತ್ತು ಮರುಸಂಪರ್ಕವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಎಲ್ಲವೂ ಆನ್‌ಲೈನ್ ಆದ ನಂತರ ಕೈಯಿಂದ ಮರುಪ್ರಾರಂಭಿಸುವುದು ಬೂಟ್ ಕ್ರಮದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಟನೆಲ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಏರಲು ಸಂರಚಿಸಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ಯಂತ್ರವನ್ನು ಮರುಬೂಟ್ ಮಾಡಿ ಮತ್ತು ಕೇಳುಗರು ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಾರೆಯೇ ಎಂದು ಗಮನಿಸಿ.

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

ಯಶಸ್ಸಿನ ಮಾನದಂಡವೆಂದರೆ ತನ್ನ ದಾಖಲಿತ ಅವಲಂಬನೆಯ ಅಡಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಕೇಳುಗ, ಯಾರೋ ಮರುಪ್ರಾರಂಭಿಸಲು ನೆನಪಿಸಿಕೊಂಡ ಕೇಳುಗ ಅಲ್ಲ.