VPN ಘಟಕ ನೆಟ್ವರ್ಕ್ಗಿಂತ ಮೊದಲು ಏಕೆ ಪ್ರಾರಂಭವಾಗಿ ನಂತರ ಸಾಯುತ್ತದೆ
ಲಿಂಕ್ಗೆ ವಿಳಾಸ ಬರುವ ಮೊದಲು ಪ್ರಾರಂಭವಾಗುವ ಘಟಕವು ಯದೃಚ್ಛಿಕವೆಂದು ತೋರುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಜರ್ನಲ್ನಿಂದ ಕ್ರಮವನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ ಕಾಯುವಿಕೆ ಮತ್ತು ಮರುಪ್ರಯತ್ನ ಸೇರಿಸಿ.
ಯಂತ್ರವನ್ನು ಬೂಟ್ ಮಾಡಿ, ಲಾಗ್ ಇನ್ ಮಾಡಿ, ಮತ್ತು ಸುರಂಗ ಮೇಲೆ ಬಂದು ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಸತ್ತದ್ದನ್ನು ತಿಳಿಯಿರಿ. ಪ್ರೊಫೈಲ್ ಸರಿಯಾಗಿತ್ತು, ಪ್ರಮಾಣಪತ್ರ ಸರಿಯಾಗಿತ್ತು, ಮತ್ತು ಉಳಿದಿರುವ ಏಕೈಕ ಜಾಡು ಆ ಬೂಟ್ನ ಜರ್ನಲ್. ಸಾಮಾನ್ಯವಾಗಿ ಸಂಭವಿಸಿದ್ದು ಒಂದು ರೇಸ್: ಯಂತ್ರಕ್ಕೆ ವಿಳಾಸ ಬರುವ ಮೊದಲೇ ಘಟಕ ಪ್ರಾರಂಭವಾಯಿತು, ಮತ್ತು ಅದು ಘೋಷಿಸಿದ ಕ್ರಮವು ಕಾಣುವಂತಹ ಅರ್ಥವನ್ನು ನೀಡಲಿಲ್ಲ. ಕೆಳಗಿನ ಎಲ್ಲವೂ ಆ ರೇಸ್ ಅನ್ನು ಸಾಕ್ಷ್ಯದಿಂದ ಸಾಬೀತುಪಡಿಸುವ ಮತ್ತು ಅದನ್ನು ಸರಿಯಾಗಿ ಮುಚ್ಚುವ ಬಗ್ಗೆ.
ಗುರಿ ಒಂದು ಸಭಾ ಸ್ಥಳ, ನಿರ್ವಾಹಕ ಅಲ್ಲ
network-online.target ಗೆ ನೆಟ್ವರ್ಕ್ ಎಂದರೇನೆಂದು ತಿಳಿದಿಲ್ಲ. ಇದು ಒಂದು ಸಮನ್ವಯ ಬಿಂದುವಾಗಿದ್ದು, ಲಿಂಕ್ ಬಳಸಲು ಯೋಗ್ಯವಾಗುವವರೆಗೆ ಪ್ರಾರಂಭವನ್ನು ವಿಳಂಬಗೊಳಿಸಬೇಕಾದ ಸೇವೆಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ವ್ಯಾಖ್ಯಾನವನ್ನು ಯಂತ್ರದ ಮಾಲೀಕರಾದ ನೆಟ್ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ಗೆ ನಿಯೋಜಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಡೆಸ್ಕ್ಟಾಪ್ಗಳು ಮತ್ತು ಸರ್ವರ್ಗಳಲ್ಲಿ ಇದರರ್ಥ NetworkManager ಅಥವಾ systemd-networkd ಒದಗಿಸುವ ಕಾಯುವಿಕೆ ಸೇವೆ. ಎರಡನ್ನೂ ಸಕ್ರಿಯಗೊಳಿಸದಿದ್ದರೆ ಗುರಿಗೆ ಕಾಯಲು ಏನೂ ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೋ ಅದನ್ನು ಎಳೆದುಕೊಳ್ಳುವ ಕ್ಷಣದಲ್ಲೇ ಅದು ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದು DHCP ಉತ್ತರಿಸುವ ಮೊದಲೇ ಬಹಳ ಮುಂಚೆ ಆಗಿರಬಹುದು. ನಿಮ್ಮ ಘಟಕದ ಕ್ರಮ ಸಾಲು ಪ್ರಾಮಾಣಿಕವಾಗಿತ್ತು ಮತ್ತು ಆದರೂ ನಿಷ್ಪ್ರಯೋಜಕ.
ಆದ್ದರಿಂದ ಮೊದಲ ಪ್ರಶ್ನೆ ನಿಮ್ಮ ಘಟಕ ಏನನ್ನು ಘೋಷಿಸುತ್ತದೆ ಎಂಬುದಲ್ಲ. ಈ ಯಂತ್ರದಲ್ಲಿ ಏನಾದರೂ ನಿಜವಾಗಿ ಕಾಯುವಿಕೆಯನ್ನು ಮಾಡುತ್ತಿದೆಯೇ ಎಂಬುದು.
ಘಟಕ ಫೈಲ್ ಬದಲು ಕೊನೆಯ ಬೂಟ್ ಓದಿ
ಘಟಕ ಫೈಲ್ಗಳು ಉದ್ದೇಶವನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಜರ್ನಲ್ ಏನಾಯಿತು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆ ಬೂಟ್ಗೆ ಮಾತ್ರ ಕೇಳಿ, ಮೊನೊಟೋನಿಕ್ ಸಮಯಮುದ್ರೆಗಳೊಂದಿಗೆ, ಪ್ರತಿ ಸಂದೇಶವೂ ಒಂದೇ ಗಡಿಯಾರದಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುವಂತೆ. ನಂತರ ಎರಡು ಸಾಲುಗಳನ್ನು ಹುಡುಕಿ: ಸುರಂಗ ಘಟಕ ಪ್ರಾರಂಭವಾಗಲು ಶುರುವಾದ ಕ್ಷಣ, ಮತ್ತು ವಿಳಾಸ ಕಾಣಿಸಿಕೊಂಡ ಅಥವಾ ಕಾಯುವಿಕೆ ಸೇವೆ ಮುಗಿದ ಕ್ಷಣ. ಆ ಎರಡು ಸಂಖ್ಯೆಗಳನ್ನು ಕ್ರಮಗೊಳಿಸಿ ಮತ್ತು ರೇಸ್ ಎರಡೂ ಆಗಿ ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತದೆ ಅಥವಾ ಹೊರಗಿಡಲ್ಪಡುತ್ತದೆ.
ಅವಲಂಬನೆಯ ನೋಟ ಇದನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಸುರಂಗ ಘಟಕದ ನಿರ್ಣಾಯಕ ಸರಪಳಿಯಲ್ಲಿ ಕಾಯುವಿಕೆ ಸೇವೆ ಇಲ್ಲದಿದ್ದರೆ, ಆ ಮಾರ್ಗದಲ್ಲಿ ಯಾವುದೂ ಪ್ರಾರಂಭವನ್ನು ವಿಳಂಬಗೊಳಿಸಿಲ್ಲ, ಮತ್ತು ಗುರಿ ನೀವು ಊಹಿಸಿದ ಕೆಲಸವನ್ನು ಮಾಡಿಲ್ಲ. ಎರಡು ನೋಟಗಳು, ಒಂದು ತೀರ್ಮಾನ.
systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office
ಕಾಯುವಿಕೆ ಸೇರಿಸಿ, ನಂತರ ಮರುಪ್ರಯತ್ನ
ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಘಟಕವನ್ನು ಸಂಪಾದಿಸುವ ಬದಲು drop-in ಬಳಸಿ, ಪ್ಯಾಕೇಜ್ ನವೀಕರಣವು ಬದಲಾವಣೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡದಂತೆ. ಎರಡು ನಿರ್ದೇಶನಗಳು ಮುಖ್ಯ: ಘಟಕವು ಗುರಿಯ ನಂತರ ಕ್ರಮಗೊಳಿಸಬೇಕು, ಮತ್ತು ಅದು ಗುರಿಯನ್ನು ಅದೇ ವಹಿವಾಟಿಗೆ ಎಳೆಯಬೇಕು. ಕೇವಲ ಕ್ರಮವು ಗುರಿಯನ್ನು ಕರೆಯುವುದಿಲ್ಲ; ಬಯಕೆಯೇ ಅದನ್ನು ಮಾಡುತ್ತದೆ.
OpenVPN ಕ್ಲೈಂಟ್ನ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಘಟಕವು ಈಗಾಗಲೇ ಎರಡನ್ನೂ ಹೊಂದಿದೆ. ಕೈಬರಹದ ಘಟಕಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದನ್ನು ಅಥವಾ ಯಾವುದನ್ನೂ ಹೊಂದಿರುವುದಿಲ್ಲ, ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯ.
[Service]
Restart=on-failure
RestartSec=15
ನಿಗದಿತ ನಿದ್ರೆ ಏಕೆ ಬಲೆ
ExecStartPre ನಲ್ಲಿ ನಿದ್ರೆ ಕ್ರಮ ಸುಧಾರಣೆಯಂತೆ ಅನಿಸುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಹಂತಗಳಿರುವ ವಿಳಂಬದಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಅದು ಪ್ರತಿ ಬೂಟ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ, ಆರೋಗ್ಯಕರವಾಗಿದ್ದವು ಸೇರಿದಂತೆ, ಮತ್ತು ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಸಂಖ್ಯೆಗಿಂತ ಲಿಂಕ್ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಾಗಲೂ ಸೋಲುತ್ತದೆ.
ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದ್ದೆಂದರೆ, ಕಾಯುವಿಕೆ ಸೇವೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆಯೇ ಎಂಬುದನ್ನು ಅದು ಮುಚ್ಚಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಂದಿನ ವೈಫಲ್ಯವು ಅದೇ ಸಮಸ್ಯೆಯ ಬೇರೆ ಸಮಯದ ರೂಪವಲ್ಲ, ಸಂಪೂರ್ಣ ಹೊಸ ಸಮಸ್ಯೆಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ. ಸಣ್ಣ ಮರುಪ್ರಾರಂಭ ವಿಳಂಬವು ಉತ್ತಮ ಸಾಧನ: ಆರೋಗ್ಯಕರ ಬೂಟ್ನಲ್ಲಿ ಅದಕ್ಕೆ ಏನೂ ಖರ್ಚಿಲ್ಲ ಮತ್ತು ಸೋತ ರೇಸ್ ಅನ್ನು ಇನ್ನೊಂದು ಪ್ರಯತ್ನವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಮಧ್ಯಂತರವನ್ನು ಸಂಯಮದಿಂದ ಇರಿಸಿ ಮತ್ತು ಘಟಕವು ಯಶಸ್ವಿಯಾಗಲು ಬಿಡಿ. ಅದು ಶಾಶ್ವತವಾಗಿ ಮರುಪ್ರಾರಂಭವಾದರೆ, ಪ್ರೊಫೈಲ್ ಮುರಿದಿದೆ ಮತ್ತು ಎಷ್ಟೇ ಮರುಪ್ರಯತ್ನ ಮಾಡಿದರೂ ಅದು ಬದಲಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮಧ್ಯಂತರವನ್ನು ಹೆಚ್ಚಿಸುವ ಬದಲು ಲಾಗ್ ಓದಿ.
ಕ್ರಮ ಸರಿಯಾಗಿದ್ದು ಹೆಸರುಗಳು ಇನ್ನೂ ವಿಫಲವಾದಾಗ
ಸುರಂಗ ಮಾರ್ಗವಿರುವ ಸಕ್ರಿಯ ಘಟಕ ಎಂದರೆ ಕ್ರಮವು ತನ್ನ ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಉಳಿದ ದೋಷವು ಒಂದು ಪದರ ಮೇಲಿದೆ. ಸಾಮಾನ್ಯ ರೂಪವೆಂದರೆ ಸುರಂಗದ up ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ವಯಿಸುವ ರಿಜಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್, ಲಿಂಕ್ ಅಥವಾ ರಿಜಾಲ್ವರ್ ಅದನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲು ಸಿದ್ಧವಾಗುವ ಮೊದಲೇ. ವೈಫಲ್ಯದ ಸಮಯದಲ್ಲಿ ರಿಜಾಲ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಸುರಂಗ ಘಟಕ ಮರುಪ್ರಾರಂಭವಾದ ನಂತರದ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಮರುಪ್ರಾರಂಭವು ಹುಡುಕಾಟಗಳನ್ನು ಸರಿಪಡಿಸಿದರೆ, ನಿಮಗೆ ತಪ್ಪು DNS ಸರ್ವರ್ ಅಲ್ಲ, ಪ್ರಾರಂಭದ ಕ್ರಮದ ದೋಷವಿದೆ, ಮತ್ತು ಆ ಎರಡಕ್ಕೂ ಬೇರೆ ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆ ಬೇಕು. ನಂತರ ಸೇವಾ ಮರುಪ್ರಾರಂಭದ ಬದಲು ಶೀತಲ ಬೂಟ್ನಿಂದ ಇಡೀ ವಿಷಯವನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ಏಕೆಂದರೆ ಮರುಪ್ರಾರಂಭವು ಈಗಾಗಲೇ ಮೇಲಿರುವ ನೆಟ್ವರ್ಕ್ ವಿರುದ್ಧ ಓಡುತ್ತದೆ ಮತ್ತು ನೀವು ಬೆನ್ನಟ್ಟುತ್ತಿರುವ ದೋಷವನ್ನೇ ಮುಚ್ಚಿಡುತ್ತದೆ. ಲಿಂಕ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಧಾನಗೊಳಿಸಿ ಅದನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಮತ್ತು ನೆಟ್ವರ್ಕ್ ವೇಗವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಘಟಕವನ್ನು ಇನ್ನೂ ಮುರಿದಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ.