OpenVPN: ಬೂಟ್ನಲ್ಲಿ ಸ್ಥಳೀಯ ಬೈಂಡ್ ವಿಫಲವಾಗುತ್ತದೆ — ಕಾಯುವುದು ಅಥವಾ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು
ಸ್ಥಳೀಯ ವಿಳಾಸವು ಇನ್ನೂ ಮೇಲಿಲ್ಲದಿದ್ದಾಗ, OpenVPN ಬೈಂಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸೀಮಿತ ಕಾಯುವಿಕೆಯನ್ನು ಮರುಪ್ರಾರಂಭ ನೀತಿಯೊಂದಿಗೆ ಹೋಲಿಸಿ ಮತ್ತು network-online.target ಏಕೆ ಖಾತರಿ ಅಲ್ಲ ಎಂದು ನೋಡಿ.
ಬೂಟ್ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗದ OpenVPN ಸರ್ವರ್ಗೆ ಎರಡು ಪರಿಹಾರಗಳನ್ನು ಸೂಚಿಸಲಾಗುತ್ತದೆ: ವಿಳಾಸಕ್ಕಾಗಿ ಕಾಯುವುದು, ಅಥವಾ ಬೈಂಡ್ ಯಶಸ್ವಿಯಾಗುವವರೆಗೆ ಸೇವೆಯು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲು ಬಿಡುವುದು. ಎರಡೂ ಒಂದೇ ಲಕ್ಷಣವನ್ನು ವಿಭಿನ್ನ ವೈಫಲ್ಯ ವರ್ತನೆಯೊಂದಿಗೆ ನಿಭಾಯಿಸುತ್ತವೆ. ಕಾಯುವಿಕೆಯು ನಿರ್ದಿಷ್ಟ ಪೂರ್ವಷರತ್ತನ್ನು ಎನ್ಕೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಇಲ್ಲದಿದ್ದಾಗ ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ; ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಪೂರ್ವಷರತ್ತನ್ನು ಮರೆಮಾಡಿ ಪ್ರಯತ್ನಿಸುತ್ತಲೇ ಇರುತ್ತದೆ. ನಿಮ್ಮ ಯುನಿಟ್ಗೆ ಯಾವುದು ಸೇರಬೇಕು ಎಂಬುದು ಆ ವಿಳಾಸವು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಅವಲಂಬನೆಯೇ ಅಥವಾ ಸಮಯದ ಆಕಸ್ಮಿಕವೇ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಎರಡೂ ಸ್ಥಿರ ನಿದ್ರೆಗಿಂತ ಉತ್ತಮ, ಏಕೆಂದರೆ ಅದು ಯಾವುದಕ್ಕೂ ಕಾಯುವುದಿಲ್ಲ ಮತ್ತು ಏನನ್ನು ಕಾಯುತ್ತಿತ್ತು ಎಂದು ವರದಿ ಮಾಡುವುದಿಲ್ಲ.
local ಆಯ್ಕೆ ನಿಜವಾಗಿ ಏನನ್ನು ಬೇಡುತ್ತದೆ
local ಡೀಮನ್ ತನ್ನ ಸಾಕೆಟ್ ಅನ್ನು ಬೈಂಡ್ ಮಾಡುವ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ವಿಳಾಸಕ್ಕೆ ಬೈಂಡ್ ಮಾಡುವುದು ವಿನಂತಿಸಿದ ವಿಳಾಸದ ಬಗ್ಗೆ ದೋಷದೊಂದಿಗೆ ತಕ್ಷಣ ವಿಫಲವಾಗುತ್ತದೆ. ಆಯ್ಕೆ ಇಲ್ಲದಿದ್ದಾಗ, ಡೀಮನ್ ಎಲ್ಲಾ ವಿಳಾಸಗಳಲ್ಲಿ ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದಲೇ ಅದೇ ಪ್ರೊಫೈಲ್ ಇಂಟರ್ಫೇಸ್ ಇನ್ನೂ ಮೇಲಕ್ಕೆ ಬಾರದ ಯಂತ್ರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಅದು ನೀವು ಹೆಸರಿಸಿದ ಒಂದು ವಿಳಾಸದ ಬದಲು ಎಲ್ಲೆಡೆ ಕೇಳುತ್ತಿದೆ. ಆ ವ್ಯತ್ಯಾಸವೇ ಸಂಪೂರ್ಣ ವೈಫಲ್ಯ, ಮತ್ತು ಮರುಬೂಟ್ ಆಗುವವರೆಗೆ ಅದು ಕಾಣುವುದಿಲ್ಲ.
ಅವಶ್ಯಕತೆ ಎಂದರೆ ಇಂಟರ್ಫೇಸ್ ಸಾಮಾನ್ಯ ಅರ್ಥದಲ್ಲಿ ಮೇಲಿರಬೇಕು ಎಂದಲ್ಲ. ಬೈಂಡ್ನ ಕ್ಷಣದಲ್ಲಿ ವಿಳಾಸವು ಸರಿಯಾದ ಇಂಟರ್ಫೇಸ್ಗೆ ನಿಗದಿಯಾಗಿರಬೇಕು, ಮತ್ತು ಅದು ಅದೇ ಡೀಮನ್ ನಂತರ ರಚಿಸುವ ಸುರಂಗವಲ್ಲ, ಮೂಲ ಇಂಟರ್ಫೇಸ್ ಆಗಿರಬೇಕು. ಲಾಗಿನ್ ಆದ ಕೆಲವು ನಿಮಿಷಗಳ ನಂತರ ಮಾಡಿದ ಪರಿಶೀಲನೆ ಬೂಟ್ ಕ್ರಮದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ವಿಳಾಸಕ್ಕಾಗಿ ಕಾಯುವುದು ಅಥವಾ ಬೈಂಡ್ ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು
ಕಾಯುವಿಕೆ ಎಂದರೆ ವಿಳಾಸ ಕಾಣಿಸಿಕೊಳ್ಳುವವರೆಗೆ ಪ್ರಶ್ನಿಸುವ ExecStartPre, ಸೀಮಿತ ಸಂಖ್ಯೆಯ ಪ್ರಯತ್ನಗಳು ಮತ್ತು ಸಮಯ ಮುಗಿದಾಗ ಶೂನ್ಯವಲ್ಲದ ನಿರ್ಗಮನದೊಂದಿಗೆ. ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಎಂದರೆ ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಯು ವಿಫಲವಾಗಲು ಬಿಟ್ಟು ಸೇವಾ ನಿರ್ವಾಹಕರನ್ನು ಅದನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಲು ಕೇಳುವುದು, ಉದಾಹರಣೆಗೆ Restart=on-failure ಜೊತೆಗೆ RestartSec=5. ಮೊದಲನೆಯದು ಕಾಣೆಯಾದ ಪೂರ್ವಷರತ್ತನ್ನು ವಿಫಲ ಯುನಿಟ್ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಎರಡನೆಯದು ಅದನ್ನು ಕೊನೆಗೆ ನಿಲ್ಲುವ ಮರುಪ್ರಾರಂಭಗಳ ಸರಣಿ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ; ಇದು ಜರ್ನಲ್ನಲ್ಲಿ ಹೆಚ್ಚು ಗದ್ದಲದ್ದಾಗಿದೆ ಆದರೆ ನೀವು ಊಹಿಸಲಾಗದ ಕಾರಣಗಳಿಗಾಗಿ ತಡವಾಗಿ ಬರುವ ವಿಳಾಸವನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ.
ವಿಳಾಸವು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಅವಲಂಬನೆಯಾದಾಗ ಕಾಯುವಿಕೆಗೆ ಆದ್ಯತೆ ನೀಡಿ, ಮತ್ತು ವಿಳಾಸವು ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣಿಸಿಕೊಂಡರೂ ಅದರ ಸಮಯ ಬದಲಾಗುವಾಗ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದಕ್ಕೆ. ಎರಡನ್ನೂ ಸೇರಿಸುವುದು ಸಮಂಜಸ: ಸೀಮಿತ ಕಾಯುವಿಕೆ ಸಾಮಾನ್ಯ ಪ್ರಕರಣವನ್ನು ಮತ್ತು ಮರುಪ್ರಾರಂಭ ನೀತಿ ಅಪವಾದವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಎರಡೂ ಮಾಡಬಾರದ್ದು ಎಂದರೆ ಶಾಶ್ವತವಾಗಿ ಓಡುವುದು, ಏಕೆಂದರೆ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಯುನಿಟ್ ತಪ್ಪು ಸಂರಚನೆಯನ್ನು ವರದಿ ಮಾಡುವ ಬದಲು ಮರೆಮಾಡುತ್ತದೆ.
network-online.target ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ
network-online.target ಸಕ್ರಿಯ ನೆಟ್ವರ್ಕ್ ಅನುಷ್ಠಾನವು online ಎಂದು ಅರ್ಥೈಸುವುದನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಲ್ಲ. systemd-networkd ಜೊತೆಗೆ, systemd-networkd-wait-online ಆ ಗುರಿಯನ್ನು ಯಾವಾಗ ತಲುಪಲಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಡೀಫಾಲ್ಟ್ online ಕಲ್ಪನೆಯು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ವಿಳಾಸ ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುವ ಮೊದಲೇ ಪೂರೈಸಬಹುದು. NetworkManager ಅಡಿಯಲ್ಲಿ, wait-online ಸೇವೆ ತನ್ನದೇ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ಗುರಿಯ ನಂತರ ಕ್ರಮಗೊಳಿಸುವುದು ಆರೋಗ್ಯಕರ ಮೂಲರೇಖೆ, ಒಂದು ವಿಳಾಸ, DNS ಉತ್ತರ ಅಥವಾ ದೂರದ ಸಹಯೋಗಿ ಸಿದ್ಧವಿದೆ ಎಂಬ ಖಾತರಿಯಲ್ಲ.
ಅದೇ ತರ್ಕ ಸಾಮಾನ್ಯ ಪರ್ಯಾಯಗಳನ್ನು ತಳ್ಳಿಹಾಕುತ್ತದೆ. ಡೆಸ್ಕ್ಟಾಪ್ ಸ್ವಯಂಪ್ರಾರಂಭ ನಮೂದು ಸರ್ವರ್ನಲ್ಲಿ ಎಂದಿಗೂ ತೆರೆಯದಿರಬಹುದಾದ ಬಳಕೆದಾರ ಸೆಷನ್ಗಾಗಿ ಕಾಯುತ್ತದೆ, ಮತ್ತು ವಿಳಂಬಿತ cron ಆಜ್ಞೆ ತಾನು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿದ ಸಂಪನ್ಮೂಲವನ್ನು ಹೆಸರಿಸದೆಯೇ ಕಳೆದ ಸಮಯವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಎರಡೂ ತಿಂಗಳುಗಳ ಕಾಲ ಯಶಸ್ವಿಯಾಗಿ ಕಾಣಬಹುದು ಮತ್ತು ನಂತರ ಮುಖ್ಯವಾದ ಒಂದೇ ಬೂಟ್ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು.
ಶೀತ ಬೂಟ್ ನಂತರ ಬೈಂಡಿಂಗ್ ಪರಿಶೀಲಿಸಿ
ಸೇವಾ ಮರುಪ್ರಾರಂಭದ ಬದಲು ನಿಜವಾದ ಶೀತ ಬೂಟ್ನಿಂದ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮರುಪ್ರಾರಂಭವು ಬೂಟ್ ಕ್ರಮವು ರಚಿಸಬೇಕಿದ್ದ ವಿಳಾಸವನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ. ಬೂಟ್ ನಂತರ ss -lntp ಅಥವಾ ss -lunp ಪ್ರತಿ ಆಲಿಸುವವನು ನಿಜವಾಗಿ ಯಾವ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಬೈಂಡ್ ಆಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು journalctl -b -u openvpn-server@server ಮೊದಲ ಪ್ರಯತ್ನ ವಿಫಲವಾಯಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಬೈಂಡ್ ಆದ ವಿಳಾಸವನ್ನು ಪ್ರೊಫೈಲ್ನಲ್ಲಿರುವುದಕ್ಕೆ ಹೋಲಿಸಿ, ನಂತರ ನೆಟ್ವರ್ಕ್ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ಹೋಲಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ.
ಪ್ರೊಫೈಲ್ಗೆ ಎಂದಿಗೂ ಸ್ಥಿರ ವಿಳಾಸ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, local ತೆಗೆದುಹಾಕುವುದು ಕಾನೂನುಬದ್ಧ ಸರಳೀಕರಣ, ಆದರೆ ಅದನ್ನು ಟ್ರಬಲ್ಶೂಟಿಂಗ್ ಅಭ್ಯಾಸವಲ್ಲ, ಭದ್ರತಾ ನಿರ್ಧಾರವನ್ನಾಗಿ ಮಾಡಿ.
ಆಲಿಸುವವನನ್ನು ವಿಸ್ತರಿಸುವುದು ಯಾರು ಅದನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಆ ಬದಲಾವಣೆಯನ್ನು ಅದನ್ನು ನಿರ್ಬಂಧಿಸಬೇಕಿದ್ದ ಫೈರ್ವಾಲ್ ನೀತಿಯೊಂದಿಗೆ ಜೋಡಿಸಿ. ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಪ್ರಾರಂಭವಾಗುವ ಸೇವೆ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿಲ್ಲ; ಅದು ಸಮಸ್ಯೆಯನ್ನು ನೆಟ್ವರ್ಕ್ನ ಅಂಚಿಗೆ ಸ್ಥಳಾಂತರಿಸಿದೆ.