OpenVPN ಯಾವುದೇ ದೋಷವಿಲ್ಲದೆ ಪ್ರಾರಂಭವಾಗುತ್ತಿಲ್ಲವೇ? ಜರ್ನಲ್ ನೋಡಿ

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

ಔಟ್ಪುಟ್ ಅನ್ನು ನಾಲ್ಕು ಸ್ಥಳಗಳು ಹೀರಿಕೊಳ್ಳುತ್ತವೆ: ಯುನಿಟ್ನ ಜರ್ನಲ್, ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುವ ಪ್ಲಗಿನ್, ಸುರಂಗದ ಇನ್ನೊಂದು ತುದಿ, ಮತ್ತು ನೀವು ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಭಾವಿಸುವುದಕ್ಕಿಂತ ವಿಭಿನ್ನ ಬೈನರಿ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಪರಿಶೀಲನೆ ಇದೆ.

ಮೌನ ಎಂದರೆ ನೀವು ಸರಿಯಾದ ಚಾನಲ್ ನೋಡುತ್ತಿರಲಿಲ್ಲ

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

ಸ್ವಚ್ಛ ನಿರ್ಗಮನವನ್ನು ಸಿಗ್ನಲ್ನಿಂದ ಬೇರ್ಪಡಿಸಲು ಸೇರಿಸಿ systemctl show -p Result -p ExecMainStatus openvpn-client@office. ಸ್ಥಿತಿ 1 ಮತ್ತು Result=exit-code ಪ್ರೋಗ್ರಾಂನ ನಿರ್ಧಾರ; Result=signal ಅಥವಾ ಟೈಮೌಟ್ ಬದಲಿಗೆ ಪರಿಸರವನ್ನು ಸೂಚಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆಯ ಯಾವುದೇ ಪ್ರಮಾಣ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಏನನ್ನಾದರೂ ಮರುಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಎರಡೂ ಮೌಲ್ಯಗಳನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಮರುಪ್ರಾರಂಭವು ಅವುಗಳನ್ನು ಉತ್ಪಾದಿಸಿದ ತಾತ್ಕಾಲಿಕ ಸ್ಥಿತಿಯನ್ನು ಅಳಿಸುತ್ತದೆ.

ಇನ್ಸ್ಟನ್ಸ್ ಹೆಸರು ಪಥದ ಭಾಗವಾಗಿದೆ

ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಟೆಂಪ್ಲೇಟ್ ಯುನಿಟ್ ಫೈಲ್ ಪಥವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಅದು ಇನ್ಸ್ಟನ್ಸ್ ಹೆಸರನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಹುಡುಕಲು ಆ ಹೆಸರನ್ನು ಡೈರೆಕ್ಟರಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ: office Debian ಮತ್ತು Ubuntu ಪ್ಯಾಕೇಜಿಂಗ್ನಲ್ಲಿ /etc/openvpn/client/office.conf ಎಂದು ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. office-v2.conf ಎಂಬ ಫೈಲ್ @office ಆಗಿ ಪ್ರಾರಂಭಿಸಿದರೆ ಎಂದೂ ಓದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಯುನಿಟ್ ಸದ್ದಿಲ್ಲದೆ ನಿರ್ಗಮಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅದರ ದೃಷ್ಟಿಯಿಂದ ಮಾಡಲು ಏನೂ ಇರಲಿಲ್ಲ. ಹುಡುಕಾಟ ಡೈರೆಕ್ಟರಿ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಮೋಡ್ಗಳಲ್ಲಿ ಭಿನ್ನವಾಗಿದೆ, ಆದ್ದರಿಂದ ಟೆಂಪ್ಲೇಟ್ ಬದಲಿಸಿದಾಗ ಅದೇ ತಪ್ಪು ಸಂಪೂರ್ಣ ಬೇರೆಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ.

ಈ ಅಸಂಗತಿಯೇ ಮೌನ ವಿಫಲತೆಯ ಸಾಮಾನ್ಯ ಮೂಲ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸರಿಯಾಗಿರುವುದರಿಂದ ಅದು ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಕಾಣುವುದಿಲ್ಲ. ನಿಜವಾಗಿ ಏನಿದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಪ್ಯಾಕೇಜಿಂಗ್ ನಿರೀಕ್ಷಿಸುವ ಯಾವುದೇ ವಿಸ್ತರಣೆ ಸೇರಿದಂತೆ ಎರಡು ಹೆಸರುಗಳನ್ನು ಅಕ್ಷರದಂತೆ ಹೋಲಿಸಿ.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

ಪ್ಲಗಿನ್ ಸುರಂಗವನ್ನು ಹೊಂದಿರುವಾಗ, ಟರ್ಮಿನಲ್ ಏನನ್ನೂ ಕಾಣುವುದಿಲ್ಲ

ಡೆಸ್ಕ್ಟಾಪ್ ಆ್ಯಪ್ಲೆಟ್ನಿಂದ ಪ್ರಾರಂಭವಾದ ಸಂಪರ್ಕವನ್ನು NetworkManager ಹೊಂದಿದೆ, ಮತ್ತು ಅದರ OpenVPN ಔಟ್ಪುಟ್ ನೀವು ತೆರೆದಿರುವ ಯಾವುದೇ ಶೆಲ್ಗೆ ಅಲ್ಲ, ಆ ಸೇವೆಯ ಜರ್ನಲ್ಗೆ ಹೋಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಅನ್ನು ಕೈಯಿಂದ ಚಲಾಯಿಸಿ ಏನನ್ನೂ ಕಾಣದಿರುವುದು ಆ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಿರೀಕ್ಷಿತ, ಏಕೆಂದರೆ ಕೈಯಿಂದ ಚಲಾಯಿಸಿದ ಪ್ರಕ್ರಿಯೆಯೇ ಸಂಪರ್ಕವನ್ನು ಹೊತ್ತೊಯ್ಯುವ ಪ್ರಕ್ರಿಯೆ ಅಲ್ಲ.

ಅದನ್ನು ಹೊಂದಿರುವ ಸೇವೆಯನ್ನು ಜರ್ನಲ್ನಲ್ಲಿ ಹುಡುಕಿ, ನಂತರ ನೀವು ಓದಬಹುದಾದ ವಿವರಮಟ್ಟದೊಂದಿಗೆ ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಕೆಳಗಿನ ಎರಡು ಆದೇಶಗಳು ಒಂದೇ ವಿಫಲತೆಯ ವಿಭಿನ್ನ ಮಾಲೀಕರನ್ನು ನೋಡುತ್ತವೆ.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

ಎರಡು ಬೈನರಿ, ಒಂದು PATH

ಕೈಯಿಂದ ನಿರ್ಮಿಸಿದ ಸ್ಥಾಪನೆ /usr/local ಅಡಿಯಲ್ಲಿದ್ದರೆ ಶೆಲ್ ಕರೆಯಲ್ಲಿ ಗೆಲ್ಲುತ್ತದೆ, ಏಕೆಂದರೆ /usr/local/sbin ಡಿಫಾಲ್ಟ್ Ubuntu PATH ನಲ್ಲಿ /usr/sbin ಗಿಂತ ಮೊದಲು ಬರುತ್ತದೆ. ಯುನಿಟ್ ನಿಮ್ಮ PATH ಬಳಸುವುದಿಲ್ಲ; ಅದು ExecStart ನಲ್ಲಿ ಬರೆದ ಸಂಪೂರ್ಣ ಪಥವನ್ನು ಚಲಾಯಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ನಿಮ್ಮ ಟರ್ಮಿನಲ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಆವೃತ್ತಿ ಮತ್ತು ಸೇವೆಯಾಗಿ ವಿಫಲವಾಗುವ ಆವೃತ್ತಿ ನಿಜವಾಗಿಯೂ ವಿಭಿನ್ನ ಪ್ರೋಗ್ರಾಂಗಳಾಗಿರಬಹುದು.

ಏನನ್ನಾದರೂ ಮರುನಿರ್ಮಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಹೋಲಿಸಿ. ಮೂರನೇ ಆದೇಶವೇ ವಾದವನ್ನು ನಿರ್ಣಯಿಸುತ್ತದೆ.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

ಇನ್ನೊಂದು ಪರಿಸರ ವ್ಯತ್ಯಾಸ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಅಡಗಿದೆ. ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಯುನಿಟ್ /run ಅಡಿಯಲ್ಲಿ systemd ಅದಕ್ಕಾಗಿ ರಚಿಸುವ ರನ್ಟೈಮ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ; ಆ ಸೆಟ್ಟಿಂಗ್ ಬಿಟ್ಟುಬಿಡುವ ಕೈಯಿಂದ ಬರೆದ ಬದಲಿ ಯುನಿಟ್ ಒಂದು ಫೈಲ್ ತೆರೆಯುವ ಮೊದಲೇ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ವಿಫಲತೆ ಯಾವುದೇ OpenVPN ಸಂದೇಶವಿಲ್ಲದ ಸಾಮಾನ್ಯ ನಿರಾಕರಣೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ವರದಿ ಮಾಡಲಾಗದ ವಿಫಲತೆಗಳು

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

ಇನ್ನೊಂದು ಮೌನ ಸಂದರ್ಭವೆಂದರೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಕ್ಲೈಂಟ್. ಕ್ಲೈಂಟ್-ಮೋಡ್ ಸುರಂಗ ಎಂದೂ ಪೋರ್ಟ್ನಲ್ಲಿ ಕೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ತೆರೆದ ಶ್ರೋತೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವ ಪರಿಶೀಲನೆ ಏನನ್ನೂ ವರದಿ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ವಿಫಲತೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಖಾಲಿ ಪೋರ್ಟ್ ಪಟ್ಟಿಯಿಂದ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ನೀವು ಯಾವ ಮೋಡ್ ಪ್ರಾರಂಭಿಸಿದಿರಿ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಪದರಗಳನ್ನು ಕ್ರಮವಾಗಿ ಕೆಲಸ ಮಾಡಿ: ಯುನಿಟ್ ಇದೆಯೇ ಮತ್ತು ಇನ್ಸ್ಟನ್ಸ್ ಹೆಸರು ಸರಿಯೇ, ಜರ್ನಲ್ ಅಥವಾ --log, ಯಾವ ಬೈನರಿ ಮತ್ತು ಪ್ರೊಫೈಲ್ ನಿಜವಾಗಿ ಚಲಿಸಿತು, ಮತ್ತು ವಿಫಲತೆ ಸ್ಥಳೀಯವೇ ಅಥವಾ ದೂರದ್ದೇ. ಪ್ರತಿ ಉತ್ತರವೂ ಒಂದು ಪದರವನ್ನು ತೆಗೆಯುತ್ತದೆ. ಪ್ರೊಫೈಲ್ನಿಂದ ಪ್ರಾರಂಭಿಸುವುದು ಎಂದರೆ ಎಂದೂ ತೆರೆಯದಿರಬಹುದಾದ ಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವುದು.