OpenVPN ಪ್ರಾರಂಭವಾಗುತ್ತಿಲ್ಲ: ಕಾನ್ಫಿಗ್ ಅಲ್ಲ, ಮೊದಲ ಸಾಲನ್ನು ಓದಿ

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

ಮೂರು ಓದಲು-ಮಾತ್ರ ಆದೇಶಗಳು ನಿಮ್ಮನ್ನು ಅಲ್ಲಿಗೆ ಕರೆದೊಯ್ಯುತ್ತವೆ: ಮೊದಲು journalctl -u openvpn@server -b --no-pager, ನಂತರ systemctl status openvpn@server, ಮತ್ತು UDP ಆಲಿಸುವವರು ಹಾಗೂ ಅವರ ಮಾಲೀಕರಿಗಾಗಿ ss -lunp.

ಮೊದಲ ಸಾಲೇ ಶಾಖೆಯನ್ನು ಆರಿಸುತ್ತದೆ

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

ಮೂಲ ಸಾಲನ್ನು ಮರೆಮಾಡುವ ಮರುಪ್ರಯತ್ನ ಲೂಪ್ಗೆ ಗಮನ ಕೊಡಿ. ಮರುಪ್ರಾರಂಭ ನೀತಿ ಇರುವ ಯುನಿಟ್ ಮೊದಲ ವೈಫಲ್ಯವನ್ನು ಡಜನ್ಗಟ್ಟಲೆ ಸಮಾನ ವೈಫಲ್ಯಗಳ ಕೆಳಗೆ ಹೂಳಬಹುದು, ಆದ್ದರಿಂದ ಯುನಿಟ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಿ ಮೇಲಿನಿಂದ ಓದಿದ journalctl -b ಬಾಲಕ್ಕಿಂತ ಉತ್ತಮ.

ಇನ್ನಾರು 1194 ಪೋರ್ಟ್ ಹಿಡಿದಿದ್ದಾರೆ

ಅಪರಾಧಿ ಸಾಮಾನ್ಯವಾಗಿ ಯಾರೋ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂರಚಿಸಿದ ಎರಡನೇ ಸರ್ವರ್ ಅಲ್ಲ. ಇನ್ನೊಂದು ಟರ್ಮಿನಲ್ನಲ್ಲಿ ಇನ್ನೂ ಜೀವಂತವಾಗಿರುವ ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ ಕ್ಲೈಂಟ್, ಅದೇ ಪೋರ್ಟ್ ಆರಿಸಿಕೊಂಡ ಎರಡನೇ ಪ್ರೊಫೈಲ್, ಅಥವಾ ತನ್ನದೇ ಸುರಂಗವು 1194 ಹಿಡಿದಿರುವ ಮಾರಾಟಗಾರರ ಬಂಡಲ್ ನಿರೀಕ್ಷಿಸಿ. ಸಾಕೆಟ್ನ ಮಾಲೀಕ ss -lunp ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ; ಯುನಿಟ್ ಜವಾಬ್ದಾರಿಯೇ ಎಂದು ತಿಳಿಯಲು ಆ PID ಅನ್ನು systemctl status ಗೆ ಕೊಡಿ. ಸಿಗ್ನಲ್ನಿಂದಲ್ಲ, ಅದರ ಸ್ವಂತ ನಿಯಂತ್ರಣ ಮಾರ್ಗದಿಂದ ಅದನ್ನು ಇಳಿಸಿ.

ಯುನಿಟ್ ನಿರ್ವಹಿಸುವ ಪ್ರಕ್ರಿಯೆಗೆ ಸಿಗ್ನಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಮರುಪ್ರಾರಂಭವನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ವೈಫಲ್ಯ ಕೆಲವು ಕ್ಷಣಗಳ ನಂತರ ಹೊಸ ಸಮಸ್ಯೆಯಂತೆ ಮತ್ತೆ ಕಾಣಿಸುತ್ತದೆ. ಯುನಿಟ್ಗೆ systemctl stop, ಮಾರಾಟಗಾರರ ಸ್ಥಾಪನೆಗೆ ಬಂಡಲ್ನ ಸ್ವಂತ ಸೇವಾ ಆದೇಶ, ಮತ್ತು ಸಿಗ್ನಲ್ ಅನ್ನು ಆ ಶೆಲ್ನಲ್ಲಿ ನೀವೇ ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ್ದಕ್ಕೆ ಮಾತ್ರ ಬಳಸಿ.

ತೆಗೆದುಹಾಕಿದ ನಂತರ ಉಳಿದ ಯುನಿಟ್ಗಳು

ತೆಗೆದುಹಾಕುವಿಕೆ ಬೈನರಿಗಳನ್ನು ಅಳಿಸುತ್ತದೆ; ಕೈಯಿಂದ ಬರೆದ ಯುನಿಟ್ ಫೈಲ್ಗಳು, ಸಾಮಾನ್ಯವಾಗಿ /etc/systemd/system ಅಡಿಯಲ್ಲಿ, ಅದರಿಂದ ಬದುಕುಳಿಯುತ್ತವೆ. ನಂತರ Systemd ಇನ್ನು ಇಲ್ಲದ ಮಾರ್ಗಕ್ಕೆ ತೋರಿಸುವ ಯುನಿಟ್ ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಮತ್ತು ಸಂದೇಶ ನಿನ್ನೆಯ ತೆಗೆದುಹಾಕುವಿಕೆಯ ಬಗ್ಗೆ ಅಲ್ಲ, ಆ ಕಾಣೆಯಾದ ಫೈಲ್ ಬಗ್ಗೆ. systemctl status ಯುನಿಟ್ನ ತುಣುಕು ಮಾರ್ಗವನ್ನು ಮೇಲ್ಭಾಗದಲ್ಲಿ ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಏನನ್ನಾದರೂ ಅಳಿಸುವ ಮೊದಲು ಅದನ್ನು dpkg -S ನಿಂದ ಪರಿಶೀಲಿಸಿ. ಅನಾಥ ಹೋದ ಮೇಲೆ systemctl daemon-reload ಮತ್ತು systemctl reset-failed ಸ್ಥಿತಿಯನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುತ್ತವೆ; ಇಲ್ಲದಿದ್ದರೆ ನಂತರದ ಪ್ರತಿ ಸ್ಥಿತಿ ಪರಿಶೀಲನೆ ಅದನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ.

which openvpn /usr/local ಅಡಿಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಉತ್ತರಿಸಿದಾಗ, ಬಳಕೆಯಲ್ಲಿರುವ ಬೈನರಿ apt ನಿಂದ ಅಲ್ಲ, ಮಾರಾಟಗಾರರ ಸ್ಥಾಪಕದಿಂದ ಬಂದಿದೆ. ಅಂತಹ ಸ್ಥಾಪಕ ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನದೇ ಆಲಿಸುವವ, ತನ್ನದೇ ಬೂಟ್ ನಮೂದು ಮತ್ತು ತನ್ನದೇ ಕಾನ್ಫಿಗ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ತರುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಾಣುವ ಆದೇಶವನ್ನು ತೆಗೆದರೂ ಸಾಕೆಟ್ ಹಿಡಿದೇ ಇರುತ್ತದೆ.

ಮಾರಾಟಗಾರರು ದಾಖಲಿಸಿರುವ ರೀತಿಯಲ್ಲಿ ಅದನ್ನು ಅನ್ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿ, ss -lunp ನಿಂದ ಪೋರ್ಟ್ ಮುಕ್ತವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಮಾತ್ರ ವಿತರಣೆಯ ಕ್ಲೈಂಟ್ ಸೇರಿಸಿ.

ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಿ

ಅದರಿಂದ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ವಿಫಲ ಸ್ಥಿತಿಯನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ: systemctl reset-failed ಕೌಂಟರ್ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ನಂತರ systemctl status ಯುನಿಟ್ನ ಇತಿಹಾಸವಲ್ಲ, ಅದರ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಅದನ್ನು ಒಮ್ಮೆ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಯಂತ್ರದ ಒಟ್ಟು ಸ್ಥಿತಿಯಲ್ಲ, ಆ ನಡೆಯ ಸ್ವಂತ ಜರ್ನಲ್ ಓದಿ. ಸುರಂಗ ಏನನ್ನೂ ಸಾಗಿಸದಿದ್ದರೂ ಸಕ್ರಿಯ ಎಂದು ವರದಿ ಮಾಡುವ ಯುನಿಟ್ ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆ, ಮತ್ತು ಹೆಚ್ಚು ಸಾಮಾನ್ಯ. ಎರಡೂ ಬಗ್ ವರದಿಗಳಲ್ಲಿ ಒಂದಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಎರಡೂ ಬಳಕೆದಾರರು «VPN ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ» ಎಂದು ಹೇಳುವಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ.

ನೀವು ತೆಗೆದುಕೊಂಡ ಶಾಖೆಯನ್ನು ಬರೆದಿಡಿ: ಪೋರ್ಟ್ ಘರ್ಷಣೆ, ಕಾಣೆಯಾದ ಬೈನರಿ, ಕಾಣೆಯಾದ ಕಾನ್ಫಿಗ್. ಮುಂದಿನ ಬಾರಿ ಗುರುತಿಸುವುದು ವೇಗವಾಗಿರುತ್ತದೆ.