ಒಂದು ಟೈಮ್ಔಟ್ ನಂತರ ನಿಮ್ಮ OpenVPN ಕ್ಲೈಂಟ್ ಏಕೆ ನಿಂತುಹೋಗುತ್ತದೆ

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

ಮಾನಿಟರಿಂಗ್ ಹೇಳುವುದರಿಂದ ಅಲ್ಲ, ಯುನಿಟ್ ನಿಜವಾಗಿ ಏನು ಮಾಡಿತು ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ. systemctl status openvpn-client@office ಮತ್ತು journalctl -u openvpn-client@office -n 50 ನಿರ್ಗಮನದ ಕಾರಣ ಮತ್ತು ಕ್ಲೈಂಟ್ ಹೋಗುವ ಮೊದಲು ಬರೆದ ಕೊನೆಯ ಸಾಲನ್ನು ತೋರಿಸುತ್ತವೆ.

ಯಾರೂ ಗಮನಿಸುವ ಮೊದಲೇ ಪ್ರಕ್ರಿಯೆ ನಿರ್ಗಮಿಸಿತು

ದೋಷವಿಲ್ಲದೆ ಮಾಯವಾಗುವ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಗಮಿಸಿರುತ್ತದೆ. ಈ ವರ್ತನೆಯನ್ನು ಪ್ರೊಫೈಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ, ಸೇವಾ ನಿರ್ವಾಹಕ ಅಲ್ಲ: ping-exit ಎದುರು ಬದಿ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಕ್ಷಣವೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ping-restart ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉಳಿಸಿಕೊಂಡು ಅದರೊಳಗೆ ಮತ್ತೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಸೆಷನ್ ಮಿತಿಗಳು ಮತ್ತು ನಿಷ್ಕ್ರಿಯತೆ ಟೈಮರ್ಗಳು ಹೊರಗಿನಿಂದ ಅದೇ ಚಿತ್ರವನ್ನು ನೀಡುತ್ತವೆ: ಸುರಂಗವೂ ಇಲ್ಲ, ಎಚ್ಚರಿಕೆಯೂ ಇಲ್ಲ.

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

ping-exit ಮತ್ತು ping-restart ನಡುವಿನ ಆಯ್ಕೆ

ತಾನೇ ಗುಣವಾಗಬೇಕಾದ ಲ್ಯಾಪ್ಟಾಪ್ ಅಥವಾ ದೂರದ ಸ್ಥಳಕ್ಕೆ ping-restart ಆರಿಸಿ, ಮತ್ತು ಸತ್ತ ಸುರಂಗ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಲ್ಲಿಸಿ ಬೇರೆ ಯಾವುದೋ ಅದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕಾದ ಸಂದರ್ಭಗಳಿಗೆ ping-exit ಇಡಿ. ಸಂಖ್ಯೆಗಳಿಗಿಂತ ಸಂಬಂಧ ಹೆಚ್ಚು ಮುಖ್ಯ: ping 10 ಜೊತೆಗೆ ping-restart 60 ಎಂದರೆ ಪರಿಶೀಲನೆಗೆ ಮೊದಲು ಹತ್ತು ಸೆಕೆಂಡುಗಳ ಮೌನ ಮತ್ತು ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಮೊದಲು ಅರವತ್ತು, ಇದು ನಷ್ಟವಿರುವ ಮೊಬೈಲ್ ಕೊಂಡಿಯಲ್ಲಿ ಆಕ್ರಮಣಕಾರಿ ಮತ್ತು ತಂತಿ ಕೊಂಡಿಯಲ್ಲಿ ಸಮಂಜಸ. ಕಾರಣವನ್ನು ಸಾಲಿನ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಓದುಗ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು ಉದ್ದೇಶಪೂರ್ವಕ ಎಂದು ಭಾವಿಸುತ್ತಾನೆ.

ನಂತರ ನಿರ್ಗಮಿಸಿದ್ದು ನಿಜವಾಗಿಯೂ ಪ್ರಕ್ರಿಯೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಸುರಂಗ ಸತ್ತಿದ್ದಾಗ ಸಕ್ರಿಯ ಎಂದು ವರದಿ ಮಾಡುವ ಯುನಿಟ್ ಬೇರೊಂದು ವೈಫಲ್ಯ, ಅದನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗಿದೆ.

ಯುನಿಟ್ ಅನ್ನು ನಿಜವಾಗಿ ಮರುಪ್ರಾರಂಭಿಸುವ ಮೇಲ್ವಿಚಾರಣೆ

systemd ಹೋಸ್ಟ್ನಲ್ಲಿ ಅತ್ಯಂತ ಚಿಕ್ಕ ಶಾಶ್ವತ ಬದಲಾವಣೆ ಒಂದು drop-in ಕಡತ: Restart=on-failure ಮತ್ತು RestartSec=10 /etc/systemd/system/[email protected]/restart.conf ನಲ್ಲಿ ಇವೆ. drop-in ಅನ್ನು systemd ತನ್ನ ಸ್ವಂತ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ಓದಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನಂತರ systemctl daemon-reload ಚಲಾಯಿಸಿ. ಮೌಲ್ಯ ಬಂದಿದೆ ಎಂದು ಭಾವಿಸುವ ಬದಲು systemctl show -p Restart -p ExecMainStatus openvpn-client@office ನಿಂದ ಪರಿಶೀಲಿಸಿ. ಕಡತದ ಹೆಸರಿನಲ್ಲಿರುವ ಇನ್ಸ್ಟಾನ್ಸ್ ಯುನಿಟ್ ನಿಜವಾಗಿ ಲೋಡ್ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಆಗಿರಬೇಕು, ಆದ್ದರಿಂದ office ಗಾಗಿ ಬರೆದ ಕಡತ openvpn-client@home ಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

on-failure ಒಂದು ಸಂದರ್ಭವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ: ಸ್ಥಿತಿ ಶೂನ್ಯವಿರುವ ಸ್ವಚ್ಛ ನಿರ್ಗಮನ. ಕೆಲವು ತೆರವು ಮಾರ್ಗಗಳು ಹಾಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಕೈಪಿಡಿ ಪುಟದ ಪದಗಳನ್ನು ನಂಬುವ ಬದಲು ದಾಖಲಾದ ಸ್ಥಿತಿಯನ್ನು ಓದಿ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಶೂನ್ಯದೊಂದಿಗೆ ಬಿಟ್ಟುಕೊಟ್ಟರೆ, ನಿಮಗೆ Restart=always ಬೇಕು, ಮತ್ತು ಅದರ ಬೆಲೆ ಎಂದರೆ ನಿಜವಾಗಿ ಒಡೆದ ಪ್ರೊಫೈಲ್ ಪ್ರಾರಂಭದ ದರ ಮಿತಿ ಸಕ್ರಿಯವಾಗಿ ಜರ್ನಲ್ ತುಂಬುವವರೆಗೆ ಮತ್ತೆ ಮತ್ತೆ ಹಿಂತಿರುಗುತ್ತದೆ.

Restart=always ಉದ್ದೇಶಪೂರ್ವಕ ನಿಲುಗಡೆಯ ನಂತರವೂ ಸಕ್ರಿಯವಾಗುತ್ತದೆ. ನಿರ್ವಹಣೆಗೆ systemctl stop ಬಳಸಿ, ಮತ್ತು ನೀವು ಕೆಲಸ ಮಾಡುವಾಗ ಯುನಿಟ್ ನಿಂತಿರಬೇಕಾದರೆ ಅದನ್ನು ಮಾಸ್ಕ್ ಮಾಡಿ.

ಸುರಂಗ ನಿಂತಿರುವಾಗ ಸೋರಿಕೆಯನ್ನು ಹಿಡಿಯಿರಿ

ಮೇಲ್ವಿಚಾರಣೆ ಸುರಂಗವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಸುರಂಗ ಇಲ್ಲದಿರುವಾಗ ಸಂಚಾರ ಹೊರಹೋಗುವುದನ್ನು ಅದು ತಡೆಯುವುದಿಲ್ಲ. persist-tun ಮರುಸಂಪರ್ಕಗಳ ನಡುವೆ ಸಾಧನ ಮತ್ತು ಅದರ ಮಾರ್ಗಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಇದು ಅನುಕೂಲಕರ ಮತ್ತು ಕಿಂಡಿಯನ್ನು ತೆರೆಯುತ್ತದೆ. ಸಾಧನ ಉಳಿಯುತ್ತದೆ, ಮಾರ್ಗಗಳು ಇನ್ನೂ ಅದನ್ನೇ ಗುರಿಯಾಗಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ಗಳು ರಕ್ಷಣೆಯಿಲ್ಲದೆ ಮತ್ತು ವರದಿಯಿಲ್ಲದೆ ಹೊರಹರಿಯುತ್ತವೆ. ಇದು ನೀತಿಯ ಆಯ್ಕೆ, ತಟಸ್ಥ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ.

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

ಕ್ಲೈಂಟ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಲ್ಲಿಸಿ ಇದನ್ನು ಪರೀಕ್ಷಿಸಿ. systemctl stop openvpn-client@office ಚಲಾಯಿಸಿ, ನಂತರ curl -m 5 https://example.com, ಅದು ಭೌತಿಕ ಕೊಂಡಿಯ ಮೇಲೆ ಯಶಸ್ವಿಯಾಗುವ ಬದಲು ವಿಫಲವಾಗಬೇಕು. ಯಶಸ್ಸು ಎಂದರೆ ಫೈರ್ವಾಲ್ ನಿಯಮ ಇಲ್ಲ ಅಥವಾ ತುಂಬಾ ಅನುಮತಿಸುವಂತಿದೆ.

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಸುರಂಗ ಮತ್ತೆ ಸಂಚಾರ ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ನಂತರವೇ ಪರಿಶೀಲನೆಯನ್ನು ಮಾನಿಟರಿಂಗ್ಗೆ ಸೇರಿಸಿ. cron ನಿಂದ ip addr ಅನ್ನು tun ಸಾಧನಕ್ಕಾಗಿ ಕೇಳುವುದು ಅತ್ಯಂತ ಹೆಚ್ಚು ವಿಫಲವಾಗುವ ಮೇಲ್ವಿಚಾರಣೆ, ಏಕೆಂದರೆ persist-tun ಇದ್ದಾಗ ಸಾಧನ ಸೆಷನ್ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಸಾಗಿಸದಿದ್ದರೂ ಪರಿಶೀಲನೆ ಆರೋಗ್ಯ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.