OpenVPN active (exited) ಎಂದು ಹೇಳುತ್ತಿದೆಯೇ? ನೀವು ಪ್ರಾರಂಭಿಸಿದ ಇನ್ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಹುಡುಕಿ

ನೀವು ಟನಲ್ ಪರಿಶೀಲಿಸಿ, systemctl status openvpn ಚಲಾಯಿಸಿ, Main PID ಇಲ್ಲದೆ ಮತ್ತು ಖಾಲಿ ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿಯೊಂದಿಗೆ active (exited) ಪಡೆಯುತ್ತೀರಿ. ಸೇವೆ ಪ್ರಾರಂಭವಾಗಿ ಸತ್ತಿದೆ ಎಂಬುದು ಸಹಜ ಓದು, ಆದ್ದರಿಂದ ನೀವು unit ತೆರೆದು /bin/true ಕಂಡುಕೊಂಡು ಪ್ಯಾಕೇಜ್ ಮುರಿದಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತೀರಿ. Debian ಪ್ಯಾಕೇಜಿಂಗ್ನಲ್ಲಿ ಆ ಸ್ಥಿತಿ ವಿನ್ಯಾಸದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ wrapper, ಮತ್ತು ಟನಲ್ ಅದು ಪ್ರಾರಂಭಿಸುವ instance unit ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಜೀವಿಸುತ್ತದೆ. ಒಟ್ಟು unit ಯಾವ ಇನ್ಸ್ಟೆನ್ಸ್ ಅದನ್ನು ನಿರ್ಮಿಸಿತು ಎಂದು ಎಂದಿಗೂ ಹೇಳುವುದಿಲ್ಲ.

ಈ unit ನಲ್ಲಿ active (exited) ನಿಜವಾಗಿ ಏನು ಅರ್ಥ

ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ unit ಒಂದೇ-ಬಾರಿಯ ಕೆಲಸ: ಅದರ ExecStart /bin/true, ಮತ್ತು ಮುಗಿದ unit ಅನ್ನು active (exited) ಎಂದು ವರದಿ ಮಾಡುತ್ತಿರುವಂತೆ ಇಡುವುದು RemainAfterExit=yes. ಆ ನಿರ್ದೇಶವನ್ನು ತೆಗೆದರೆ ಅದೇ ಯಶಸ್ವಿ /bin/true ಕೆಲಸ inactive (dead) ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಅದು ಜನರು ನಿರೀಕ್ಷಿಸುವ ಮತ್ತು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ತಪ್ಪಾಗಿ ಓದುವ ಸ್ಥಿತಿ. ಆದೇಶ ಕೇವಲ ಜಾಗ ತುಂಬುವಿಕೆ, ಮತ್ತು unit ಬೇರೆ unit ಗಳು ಮಾಡುವ ಕೆಲಸದ ಬಗ್ಗೆ ವರದಿ ಮಾಡುತ್ತದೆ. ಆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಏನೂ ಮುರಿದಿಲ್ಲ, ಮತ್ತು /bin/true ಬದಲಿಸುವುದು ಟನಲ್ ಅಲ್ಲ, ಪ್ಯಾಕೇಜಿಂಗ್ ಒಪ್ಪಂದವನ್ನು ಬದಲಿಸುತ್ತದೆ.

wrapper ನಿಯೋಗ ಮಾಡುತ್ತದೆ. ಪ್ಯಾಕೇಜ್ ಸಂರಚನೆ ಅಥವಾ ಅದರ systemd ಜನರೇಟರ್ ಒದಗಿಸುವ instance unit ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಖಾಲಿ ಪ್ರಕ್ರಿಯೆ ಪಟ್ಟಿ ಟನಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಯಾವ ಇನ್ಸ್ಟೆನ್ಸ್ ಆಯ್ಕೆಯಾಗದಿದ್ದರೂ wrapper ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಸ್ಥಿತಿ wrapper ಓಡಿತೇ ಎಂದು ಉತ್ತರಿಸುತ್ತದೆ, ಟನಲ್ ಇದೆಯೇ ಎಂದಲ್ಲ.

ಬ್ರಾಕೆಟ್ನಲ್ಲಿರುವ ಪದವಲ್ಲ, status ಔಟ್ಪುಟ್ನ ಮೂರು ಸಾಲುಗಳನ್ನು ಓದಿ. Loaded systemd ಓದಿದ unit ಫೈಲ್ ಹೆಸರಿಸುತ್ತದೆ, Active ಕೊನೆಯ ಯಶಸ್ವಿ ಓಟದ ಸಮಯ ಮುದ್ರೆ ಹೊಂದಿದೆ, ಮತ್ತು Main PID ಇಲ್ಲದಿರುವುದು ಮುಗಿದ ಒಂದೇ-ಬಾರಿಯ ಕೆಲಸಕ್ಕೆ ಹೊಂದುತ್ತದೆ. ಆ ಮೂರು ಸಾಲುಗಳೇ ಈ wrapper ಅನ್ನು ಪ್ರಾರಂಭದ ಒಂದು ಸೆಕೆಂಡ್ ನಂತರ ಬಿದ್ದ ಸೇವೆಯಿಂದ ಬೇರ್ಪಡಿಸುವ ದಾರಿ.

status ಮತ್ತೆ ಓದುವ ಮೊದಲು unit ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ

ಏನು ಚಲಿಸುತ್ತಿದೆ ಎಂದು ಕೇಳುವ ಮೊದಲು systemd ಗೆ ಏನು ಇದೆ ಎಂದು ಕೇಳಿ. ಯಾವ ಇನ್ಸ್ಟೆನ್ಸ್ ರಚಿಸದೆಯೇ ಟೆಂಪ್ಲೇಟ್ ಸ್ಥಾಪಿತವಾಗಿರಬಹುದು, ಮತ್ತು ರಚಿಸಿದ unit ಮಾತ್ರ ಟನಲ್ ಹೊಂದಿರುತ್ತದೆ. ಲೋಡ್ ಆದ ಸೆಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ:

systemctl list-units 'openvpn*'

ಆ ಪಟ್ಟಿ systemd ಈ ಕ್ಷಣ ಲೋಡ್ ಮಾಡಿದ್ದು, ಮತ್ತು ಅದು ಟನಲ್ ಪಟ್ಟಿಗೆ ಹತ್ತಿರವಾದುದು. ಸ್ಥಾಪಿತ unit ಫೈಲ್ಗಳು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಏನೂ ರಚಿಸದಿದ್ದಾಗಲೂ ಆ ಪಟ್ಟಿ ಟೆಂಪ್ಲೇಟ್ ತೋರಿಸುತ್ತದೆ:

systemctl list-unit-files 'openvpn*'

ಎರಡೂ ಪಟ್ಟಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ, ಏಕೆಂದರೆ ಎರಡನೆಯದರಲ್ಲಿನ ಟೆಂಪ್ಲೇಟ್ ಮತ್ತು ಮೊದಲನೆಯದರಲ್ಲಿನ ಇನ್ಸ್ಟೆನ್ಸ್ ಎರಡು ಬೇರೆ ಉತ್ತರಗಳು. ಇರುವ ಟೆಂಪ್ಲೇಟ್ ಮತ್ತು ಓಡುತ್ತಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್ ಒಂದೇ ಸತ್ಯವಲ್ಲ, ಮತ್ತು ಎರಡನೆಯದು ಮಾತ್ರ ಟನಲ್ ಎಂದರ್ಥ. ಪ್ಯಾಕೇಜ್ ವಿನ್ಯಾಸಗಳು ವಿತರಣೆಗಳು ಮತ್ತು OpenVPN ಆವೃತ್ತಿಗಳ ನಡುವೆಯೂ ಭಿನ್ನ. ಹಳೆಯ openvpn@ ಟೆಂಪ್ಲೇಟ್, ಪ್ರತ್ಯೇಕ client ಮತ್ತು server ಜೋಡಿ, ಮತ್ತು ವಿತರಣಾ wrapper ಎಲ್ಲವೂ ತಮ್ಮ ಪ್ಯಾಕೇಜಿಂಗ್ನಲ್ಲಿ ಕಾನೂನುಬದ್ಧವಾಗಿರಬಹುದು.

ನೀವು ಕಂಡುಕೊಂಡ ಟ್ಯುಟೋರಿಯಲ್ಗಲ್ಲ, ನಿಮ್ಮ ಯಂತ್ರಕ್ಕೆ ಹೊಂದಿಸಿ. ಬೇರೆಯವರ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಇನ್ಸ್ಟೆನ್ಸ್ ಹೆಸರು office ಆಗಿರಬಹುದು, ನಿಮ್ಮದು home ಅಥವಾ work ಆಗಿರಬಹುದು. ವರ್ಗಾವಣೆಯಾಗುವುದು ವಿಧಾನ, ಸ್ಟ್ರಿಂಗ್ ಅಲ್ಲ.

ಇನ್ಸ್ಟೆನ್ಸ್ ಹೆಸರನ್ನು ಅದು ಓದುವ ಫೈಲ್ವರೆಗೆ ಅನುಸರಿಸಿ

upstream client ಟೆಂಪ್ಲೇಟ್ನಲ್ಲಿ unit ನ ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ /etc/openvpn/client ಮತ್ತು ಅದರ ಆದೇಶ ಅಲ್ಲಿಂದ %i.conf ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ openvpn-client@office /etc/openvpn/client/office.conf ಓದುತ್ತದೆ. ಉದಾಹರಣೆಯನ್ನು ನಂಬುವ ಬದಲು ಸ್ಥಾಪಿತ unit ನಲ್ಲಿ ಆ ನಕ್ಷೆಯನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್ ಹಳೆಯದಾಗಿರಬಹುದು ಅಥವಾ ವಿತರಣೆಯ ಮರುಬರವಣಿಗೆಯಾಗಿರಬಹುದು:

systemctl cat [email protected]

ಆ ಔಟ್ಪುಟ್ನ ಕೆಳಗೆ ಕಾಣುವ drop-in ಗಳನ್ನು ಓದಿ, ಏಕೆಂದರೆ .d/ ಅಡಿಯಲ್ಲಿನ ಫೈಲ್ ExecStart, ಕೆಲಸದ ಡೈರೆಕ್ಟರಿ ಅಥವಾ ಸಂರಚನಾ ಮಾರ್ಗವನ್ನು ಬದಲಿಸಬಹುದು. ನೀವು office.ovpn ಎಂದು ಡೌನ್ಲೋಡ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ಇನ್ಸ್ಟೆನ್ಸ್ ತೆರೆಯುವ ಫೈಲ್ ಅಲ್ಲ. ಈ ಅಂತರವೇ ನೀವು ಎಂದಿಗೂ ಸಂಪಾದಿಸದ ಮಾರ್ಗವನ್ನು ದೋಷ ಹೆಸರಿಸುವ ಸಾಮಾನ್ಯ ಕಾರಣ.

ಪ್ರೊಫೈಲ್ ಒಳಗಿನ ಸಾಪೇಕ್ಷ ಮಾರ್ಗಗಳು ಮುಂದಿನ ಬಲೆ. ca, cert ಮತ್ತು key ಉಲ್ಲೇಖಗಳನ್ನು ಸಾಪೇಕ್ಷವಾಗಿ ಇಟ್ಟು ಮುಖ್ಯ ಫೈಲ್ ಸರಿಸಿದರೆ, ಕಾಣೆಯಾದ-ಫೈಲ್ ದೋಷವನ್ನು ಇನ್ನೊಂದು ಕಾಣೆಯಾದ-ಫೈಲ್ ದೋಷಕ್ಕೆ ಬದಲಿಸುತ್ತೀರಿ. ಎರಡನೆಯದು ಇದೆ ಎಂದು ನೀವು ಖಚಿತವಾಗಿದ್ದ ಫೈಲ್ಗೆ ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೈಲ್ ಹೆಸರಿಗಿಂತ ಪ್ರೊಫೈಲ್ ಡೈರೆಕ್ಟರಿ ಮುಖ್ಯ.

ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಆ ಇನ್ಸ್ಟೆನ್ಸ್ನ ಜರ್ನಲ್ ಓದಿ

ನೀವು ಈಗಷ್ಟೇ ಪರಿಶೀಲಿಸಿದ ಇನ್ಸ್ಟೆನ್ಸ್ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಒಟ್ಟು unit ನ ಲಾಗ್ ಟನಲ್ನ ದೋಷಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ. ನಂತರ ಈ ಬೂಟ್ನ ಜರ್ನಲ್ ಓದಿ, ಅದೇ ಕ್ರಮದಲ್ಲಿ ಸಂರಚನಾ ದೋಷ, ಫೈಲ್-ಪ್ರವೇಶ ದೋಷ ಮತ್ತು ಸಂಪರ್ಕ ದೋಷವನ್ನು ಹುಡುಕಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಪ್ರಾರಂಭದ ಬೇರೆ ಹಂತದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

ಪ್ರಾರಂಭಿಸುವುದು ಮತ್ತು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಬೇರೆ ನಿರ್ಧಾರಗಳು: start unit ಅನ್ನು ಈಗ ಚಲಾಯಿಸುತ್ತದೆ, enable ಮುಂದಿನ ಬೂಟ್ ಏರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು enable --now ಎರಡನ್ನೂ ಒಂದು ಹಂತದಲ್ಲಿ ಮಾಡುತ್ತದೆ. daemon-reload unit ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಮತ್ತೆ ಓದುತ್ತದೆ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ ಅಥವಾ ಸಂಪಾದಿತ ಪ್ರೊಫೈಲ್ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್ ಬದಲಿಸಿದ ನಂತರ ಇನ್ಸ್ಟೆನ್ಸ್ ಮರುಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಫೈಲ್ ಮತ್ತೆ ಓದುವುದು ಅದೇ.

ಅದೇ ಟನಲ್ಗೆ ಎರಡನೇ ನಿರ್ವಾಹಕರನ್ನು ಹಾಕಬೇಡಿ

NetworkManager ಮತ್ತು OpenVPN 3 ಸೆಷನ್ ನಿರ್ವಾಹಕರು ತಮ್ಮದೇ ಸಂಪರ್ಕ ಸ್ಥಿತಿ ಹೊಂದಿದ್ದಾರೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದರ ಪಕ್ಕದಲ್ಲಿ systemd ಇನ್ಸ್ಟೆನ್ಸ್ ಇದ್ದರೆ ಅದೇ ಟನಲ್ಗೆ ಇಬ್ಬರು ಮಾಲೀಕರಾಗುತ್ತಾರೆ. ಲಕ್ಷಣವೆಂದರೆ ಟನಲ್ ಮೇಲೆ ಬಂದು ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಬದಲಾಗುವುದು, ಅಥವಾ ನಿಂತಿರಲು ನಿರಾಕರಿಸುವುದು. ನಿಮ್ಮ ವಿತರಣೆ ಡೆಸ್ಕ್ಟಾಪ್ಗೆ ದಾಖಲಿಸುವ ನಿರ್ವಾಹಕರನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಮತ್ತು ಸರ್ವರ್ನಲ್ಲಿ systemd ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬಳಸಿ.

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

ಮೂಲ ಪ್ರಶ್ನೆಗೆ ಇನ್ಸ್ಟೆನ್ಸ್ ಹೆಸರು, ಅದು ಓದಿದ ಫೈಲ್ ಮತ್ತು ವಿಫಲವಾದ ಜರ್ನಲ್ ಸಾಲಿನೊಂದಿಗೆ ಉತ್ತರಿಸಿ. systemd ಏಕೀಕರಣದ ಬಗ್ಗೆ OpenVPN ನ ಟಿಪ್ಪಣಿಗಳು ಟೆಂಪ್ಲೇಟ್ ವಿನ್ಯಾಸ ಮತ್ತು ಇನ್ಸ್ಟೆನ್ಸ್ ಹೆಸರು ಪರಿಹರಿಸುವ ಫೈಲ್ ನಕ್ಷೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ.