ಬಹು ಸ್ಕ್ರಿಪ್ಟ್ಗಳ ಎಚ್ಚರಿಕೆಯು ವೇಳಾಪಟ್ಟಿಯ ದೂರಿನಂತೆ ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಪಷ್ಟ ಪರಿಹಾರವೆಂದರೆ ಅದು ಮಾಯವಾಗುವವರೆಗೆ ಸಾಲುಗಳನ್ನು ಮರುಜೋಡಿಸುವುದು. ಇದು ವೇಳಾಪಟ್ಟಿಯ ದೂರು ಅಲ್ಲ. ನಂತರದ --up ವ್ಯಾಖ್ಯಾನವು ಆ ಹಂತಕ್ಕೆ ಈಗಾಗಲೇ ಸಂಗ್ರಹಿಸಿದ ಆದೇಶವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಪಾರ್ಸರ್ ಹಾಗೆ ಹೇಳುತ್ತದೆ, ಅಂದರೆ ನಿಮ್ಮ ಎರಡು ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲಿ ನಿಖರವಾಗಿ ಒಂದೇ ಎಂದಾದರೂ ಚಲಿಸಿದೆ. ಇನ್ನೊಂದು ಅದರ ಹಿಂದೆ ಸರತಿಯಲ್ಲಿ ಇಲ್ಲ; ಅದು ಹೋಗಿದೆ.

ಆದ್ದರಿಂದ ಎಚ್ಚರಿಕೆಯು ಮಾರಕವಲ್ಲದಿದ್ದರೂ ಗಮನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ: ಅದು ಮುನ್ಸೂಚಿಸುವುದು ಮೌನವಾಗಿ ನಿಂತುಹೋದ DNS ನವೀಕರಣ ಅಥವಾ ಮಾರ್ಗ ಬದಲಾವಣೆ.

ಎಚ್ಚರಿಕೆ ಕ್ರಮದ ಬಗ್ಗೆ ಅಲ್ಲ

OpenVPN up ಹಂತಕ್ಕೆ ಒಂದೇ ಬಳಕೆದಾರ ಸ್ಕ್ರಿಪ್ಟ್ ಆದೇಶವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಪಾರ್ಸರ್ ಇನ್ನೊಂದು ವ್ಯಾಖ್ಯಾನವನ್ನು ಎದುರಿಸಿದಾಗ, ಪ್ರೊಫೈಲ್ನಿಂದ, ಸೇರಿಸಿದ ಫೈಲ್ನಿಂದ ಅಥವಾ ಆದೇಶ ಸಾಲಿನಿಂದ, ಅದು ಈಗಾಗಲೇ ಇಟ್ಟುಕೊಂಡಿದ್ದನ್ನು ಬದಲಾಯಿಸಿ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತದೆ. ಏನೂ ಸೇರಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಏನೂ ಎರಡು ಬಾರಿ ಚಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕ್ರಮದ ಪ್ರಶ್ನೆಯೇ ಇಲ್ಲ. ಉಳಿಯುವ ಆದೇಶವು ಪಾರ್ಸರ್ ಕೊನೆಯದಾಗಿ ನೋಡಿದ್ದು, ಆದ್ದರಿಂದ ಸಾಲನ್ನು ಸರಿಸುವುದು ವಿಜೇತನನ್ನು ಬದಲಿಸಬಹುದು ಮತ್ತು ಇನ್ನೊಂದು ಸ್ಕ್ರಿಪ್ಟ್ ಸತ್ತೇ ಉಳಿಯುತ್ತದೆ.

ಅದೇ ಮಾದರಿ ಇತರ ಸ್ಕ್ರಿಪ್ಟ್ ಹಂತಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ: ಪ್ರತಿಯೊಂದಕ್ಕೂ ಒಂದು ಆದೇಶ. ಎರಡು ಕೆಲಸಗಳು ಎರಡೂ ನಡೆಯಬೇಕಿದ್ದರೆ, ಅವುಗಳಿಗೆ ಪಟ್ಟಿಯಂತೆ ಕಾಣುವ ಎರಡು ಸೂಚನೆಗಳಲ್ಲ, ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದು ಬೇಕು.

ನಿಜವಾದ ಪ್ರಯೋಗದಲ್ಲಿ ಎರಡೂ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಹುಡುಕಿ

ನೀವು ಸಂಪಾದಿಸಿದ ಪ್ರೊಫೈಲ್ನಿಂದ ಅಲ್ಲ, ಡೀಮನ್ ನಿಜವಾಗಿ ಪಡೆದದ್ದರಿಂದ ಪ್ರಾರಂಭಿಸಿ. ps -ef ಮತ್ತು ಘಟಕದ ExecStart ಆದೇಶ ಸಾಲನ್ನು ತೋರಿಸುತ್ತವೆ, ಅದಕ್ಕೆ ಕಂಟೇನರ್ ಪ್ರವೇಶ ಬಿಂದುವಿನಿಂದ ಅಥವಾ ರ್ಯಾಪರ್ನಿಂದ --up ಸೇರಬಹುದು; ವಿತರಣೆಯ init ಫೈಲ್ ಕೂಡ ಅದನ್ನೇ ಮಾಡಬಹುದು. systemctl cat openvpn-server@server ಸೇವೆಯೇ ಏನು ಸೇರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬಯಲು ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಂರಚನಾ ಕೋಶದ ಮೇಲೆ ಪುನರಾವರ್ತಿತ grep ಫೈಲ್ ಮಟ್ಟದ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ. ನಕಲುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಬೇರೆ ಪದರಗಳಿಂದ ಬರುತ್ತವೆ, ಮತ್ತು ಒಂದು ಫೈಲ್ ಸಂಪಾದಿಸಿದರೆ ಏನೂ ಬದಲಾಗದಿರಲು ಅದೇ ಕಾರಣ.

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

ಒಂದೇ hook ಕೆಲಸದ ಒಡೆಯನಾಗಲಿ

ಶಾಶ್ವತ ಪರಿಹಾರವೆಂದರೆ ಎರಡೂ ಕ್ರಿಯೆಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕ ಕ್ರಮದಲ್ಲಿ ನಡೆಸುವ ಒಂದೇ ಡಿಸ್ಪ್ಯಾಚರ್. set -eu ಹೊಂದಿರುವ ಸಣ್ಣ shell ಸ್ಕ್ರಿಪ್ಟ್ ಅಗತ್ಯ ಸಂಯೋಜನೆಯನ್ನು ಮತ್ತು ನಂತರ ಸ್ಥಳೀಯ ಕ್ರಿಯೆಯನ್ನು ಕರೆದು, ಆರ್ಗ್ಯುಮೆಂಟ್ ಗಡಿಗಳು ಉಳಿಯಲು "$@" ರವಾನಿಸುತ್ತದೆ; ಹೀಗೆ ವರ್ತನೆ ಒಂದೇ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಉಳಿಯುತ್ತದೆ. ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳನ್ನು ರವಾನಿಸುವುದು ಅವನ್ನು ಕೇವಲ ಸಂರಕ್ಷಿಸುತ್ತದೆ; ಎರಡೂ ಸಹಾಯಕರು ಒಂದೇ ಇಂಟರ್ಫೇಸ್ ನಿರೀಕ್ಷಿಸುತ್ತವೆ ಎಂದು ಅದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದರ ಒಪ್ಪಂದವನ್ನು ಓದಿ. ವೈಫಲ್ಯ ಏನು ಮಾಡಬೇಕು ಮತ್ತು ಭಾಗಶಃ ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ.

ಲಾಂಚರ್ ಬೆಂಬಲಿತ ವಿಸ್ತರಣಾ hook ನೀಡಿದರೆ, ಕೈಯಿಂದ ಮಾಡಿದ ಸರಪಳಿಗಿಂತ ಅದನ್ನೇ ಆರಿಸಿ. ಕಂಟೇನರ್ ಇಮೇಜ್ ಅಥವಾ ಮಾರಾಟಗಾರರ ಪ್ಯಾಕೇಜ್ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಕೆಲಸಕ್ಕೆ ದಾಖಲಿತ ಸ್ಥಳ ಇರುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಬಳಸುವುದು ನವೀಕರಣವು ನಿಮ್ಮ ಡಿಸ್ಪ್ಯಾಚರ್ ಮೇಲೆ ಬರೆಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಸಂಬಂಧಿತ down ಹಂತಕ್ಕೆ ಸೇರಿದೆ. DNS ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಅಥವಾ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸುವ up ಕ್ರಿಯೆಗೆ ದಾಖಲಿತ ಹಿಂತಿರುಗಿಸುವಿಕೆ ಬೇಕು, ಮತ್ತು ಕೇವಲ ಆರಂಭವನ್ನು ನಿರ್ವಹಿಸುವ ಡಿಸ್ಪ್ಯಾಚರ್ ಅರ್ಧ ವಿನ್ಯಾಸ.

ಮೌನವಲ್ಲ, ಸಂಯೋಜನೆಯನ್ನು ಖಚಿತಪಡಿಸಿ

ನಕಲಿ ಎಚ್ಚರಿಕೆಯನ್ನು ತೆಗೆಯುವುದು ಸುಲಭ ಭಾಗ; ಸಂಯೋಜನೆ ಇನ್ನೂ ಕೆಲಸ ಮಾಡಬೇಕು. ಸಂಪರ್ಕದ ನಂತರ resolvectl status ಮೂಲಕ ಅಥವಾ /etc/resolv.conf ಓದುವ ಮೂಲಕ ರಿಜಾಲ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ip route ಮೂಲಕ ಮಾರ್ಗಗಳನ್ನು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಏಕೆಂದರೆ ಆತುರದಿಂದ ಜೋಡಿಸಿದ hook ಹಿಂದಿನ ಅವಧಿಯಿಂದ ಏನನ್ನಾದರೂ ಬಿಡುತ್ತದೆ. journalctl -u openvpn-server@server -b ನಿಮ್ಮ ಡಿಸ್ಪ್ಯಾಚರ್ ಚಲಿಸಿತೇ ಮತ್ತು ಏನು ಮುದ್ರಿಸಿತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

hook ನ ಸವಲತ್ತುಗಳನ್ನು ಅವು ಇರಬೇಕಾದಲ್ಲೇ ಇರಿಸಿ. script-security ಹೆಚ್ಚಿಸುವುದು ಅಥವಾ ಡೀಮನ್ ಅನ್ನು ಹೆಚ್ಚು ಹಕ್ಕುಗಳೊಂದಿಗೆ ಚಲಾಯಿಸುವುದು ಬದಲಾದ hook ಗೆ ಪರಿಹಾರವಲ್ಲ; ಅದು ಪ್ರತಿ ಭವಿಷ್ಯದ ಸ್ಕ್ರಿಪ್ಟ್, ದಾಳಿಕೋರನು ಹೆಸರಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಸೇರಿದಂತೆ, ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ.

ಪರಿಹಾರ ನಿಜವೆಂಬ ಸೂಚನೆ ಲಾಗ್ನಲ್ಲಿ ಮೌನವಲ್ಲ. ಅದು DNS ಉತ್ತರ, ಮಾರ್ಗ ನಮೂದು ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ, ಎರಡು ಮರುಸಂಪರ್ಕಗಳ ನಂತರ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ನಡೆಯುತ್ತವೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು