ಲ್ಯಾಪ್ಟಾಪ್ ಎದ್ದ ನಂತರ OpenVPN ಏಕೆ ಸಾಯುತ್ತದೆ?

ಸ್ಲೀಪ್ OpenVPN ಸೆಷನ್ ಅನ್ನು ಕೊಂದು tun0 ಅನ್ನು ಉಳಿಸಬಹುದು. ಟನೆಲ್ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಸಾಧನವಲ್ಲ, systemd ಸ್ಲೀಪ್ ಹುಕ್ನಿಂದ ಯುನಿಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ.

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಮೊದಲು ಎಚ್ಚರವನ್ನು ಮರುಸೃಷ್ಟಿಸಿ

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

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

systemd ಸ್ಲೀಪ್ ಹುಕ್ ನಿಜವಾಗಿ ಎಲ್ಲಿದೆ

ಹಳೆಯ ಅನೇಕ ಮಾರ್ಗದರ್ಶಿಗಳು /etc/pm/sleep.d ಅನ್ನು ತೋರಿಸುತ್ತವೆ, ಇದು pm-utils ಒಡೆತನದ ಡೈರೆಕ್ಟರಿ ಮತ್ತು systemd ಆಧಾರಿತ ಸ್ಲೀಪ್ ಅದನ್ನು ಎಂದಿಗೂ ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. systemd /usr/lib/systemd/system-sleep/ ಮತ್ತು /etc/systemd/system-sleep/ ನಿಂದ ಹುಕ್ಗಳನ್ನು ಓದುತ್ತದೆ, ಮೊದಲು ಹಂತ ಮತ್ತು ನಂತರ ಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ pre ಮತ್ತು post ಹುಕ್ ಕವಲೊಡೆಯುವ ಏಕೈಕ ಮೌಲ್ಯಗಳು. ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಫೈಲ್ ಸಂಪಾದಿಸುವ ಬದಲು ಸ್ಥಳೀಯ ಪ್ರತಿಯನ್ನು /etc ಅಡಿಯಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ಪರಿವರ್ತನೆಯ ಮಧ್ಯದಲ್ಲಿ root ಆಗಿ ಚಲಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ, ಆದ್ದರಿಂದ ಅದು ಬೇಗ ಮರಳಬೇಕು.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart ಯುನಿಟ್ ಅನ್ನು ಈಗಾಗಲೇ ಸಕ್ರಿಯವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಮುಟ್ಟುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಫ್ ಮಾಡಿದ ಟನೆಲ್ ಎಚ್ಚರದ ಉದ್ದಕ್ಕೂ ಆಫ್ ಆಗಿಯೇ ಇರುತ್ತದೆ. --no-block ಕ್ಲೈಂಟ್ ಮಾತುಕತೆ ನಡೆಸುತ್ತಿರುವಾಗ ಹುಕ್ ಕಾಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದು ನೆಟ್ವರ್ಕ್ ಇನ್ನೂ ಮೇಲೆ ಬಾರದಿದ್ದಾಗ ಮುಖ್ಯ. ಎರಡೂ ಫ್ಲ್ಯಾಗ್ಗಳು ಒಟ್ಟಿಗೆ ಸಂಪೂರ್ಣ ಎಚ್ಚರ ಅನುಕ್ರಮವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಬದಲು ಮೌನವಾಗಿ ವಿಫಲವಾಗುವ ಹುಕ್ ಅನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಯುನಿಟ್ ಈಗಾಗಲೇ ನಿಂತಿದ್ದರೆ ಏನೂ ನಡೆಯುವುದಿಲ್ಲ, ಅದು ನೀವು ಅಲ್ಲಿ ಬಯಸುವ ಫಲಿತಾಂಶವೇ.

ಸೇವೆಯನ್ನು ಚೇತರಿಸಿ, tun0 ಅನ್ನು ಬಿಡಿ

tun0 ಅನ್ನು ಕೈಯಿಂದ ಕೆಳಗಿಳಿಸಿದರೆ ಡೀಮನ್ ಇನ್ನು ತನ್ನದಲ್ಲದ ಇಂಟರ್ಫೇಸ್ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತಿರುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ಸ್ಥಿತಿ ಬದಲಾವಣೆ ಗೊಂದಲದ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ ಬದಲು ಸೇವೆ ಅಥವಾ ಅದರ ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಗುರಿಯಾಗಿಸಿ; ಮೊದಲು ಯುನಿಟ್ನ ನಿಖರ ಹೆಸರು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ವಿತರಣಾ ಪ್ಯಾಕೇಜ್ಗಳು, OpenVPN 3 ಮತ್ತು NetworkManager ಎಲ್ಲಾ ಬೇರೆ ಬೇರೆ ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ. NetworkManager ಪ್ರೊಫೈಲ್ ಆ ಸಂಪರ್ಕವನ್ನು ಮರುಚಕ್ರೀಕರಿಸಿದಾಗ ಮರಳುತ್ತದೆ, ಆದ್ದರಿಂದ systemd ಯುನಿಟ್ ಅಲ್ಲಿ ಗುರಿಯಲ್ಲ. ಕಾರ್ಯವಿಧಾನ ಯಾವುದೇ ಇರಲಿ, ಅದು ನೀವು ಕೈಯಿಂದ ಪರಿಶೀಲಿಸಿದ ಅದೇ ಕ್ರಿಯೆಯಾಗಿರಬೇಕು.

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

ನೀವು ನಿಯಂತ್ರಿಸಲಾಗದ ಸಮಯವನ್ನು ನಿಭಾಯಿಸಿ

ವೈರ್ಲೆಸ್ ಸಂಯೋಜನೆ ಮತ್ತು DHCP ಸಾಮಾನ್ಯವಾಗಿ ಹುಕ್ ಚಲಿಸಿದ ನಂತರ ಪೂರ್ಣಗೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ಗೆ ಮಾರ್ಗ ಇನ್ನೂ ಇಲ್ಲದಿರುವಾಗ ಮರುಪ್ರಾರಂಭ ವಿಫಲವಾಗಬಹುದು. ಆ ವಿಳಾಸಕ್ಕಾಗಿ ಸ್ವಲ್ಪ ಕಾಯಿರಿ, ಒಮ್ಮೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಲಾಗ್ ಮಾಡಿ.

ಹೆಸರು ವಿಭೇದನವು ಪ್ರತ್ಯೇಕ ಸ್ಪರ್ಧೆ, ಏಕೆಂದರೆ ಡೆಸ್ಕ್ಟಾಪ್ನ ನೆಟ್ವರ್ಕ್ ಸ್ಟ್ಯಾಕ್ ಟನೆಲ್ ಈಗಾಗಲೇ ಮೇಲೆ ಬಂದ ನಂತರ DNS ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು. ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗದಿಂದ ಅನುಮಾನಿಸುವ ಬದಲು resolvectl query internal.example ನೊಂದಿಗೆ ಹುಡುಕಾಟಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಸರಿಯಾಗಿ ಮಾರ್ಗ ನೀಡಿ ಏನನ್ನೂ ಬಗೆಹರಿಸದ ಟನೆಲ್ DNS ಸಮಸ್ಯೆ, ಹುಕ್ನ ಸಮಸ್ಯೆ ಅಲ್ಲ.

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

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