ಪರದೆ ಕತ್ತಲಾಗುತ್ತಿದ್ದಂತೆ VPN ಕಡಿತಗೊಳ್ಳುತ್ತದೆ: ಲಾಕ್, ಬ್ಲಾಂಕ್ ಅಥವಾ ಸಸ್ಪೆಂಡ್?
ಲಾಕ್ ಆದ ಸೆಷನ್, ಕತ್ತಲಾದ ಪರದೆ ಮತ್ತು ಸಸ್ಪೆಂಡ್ ಆದ ಯಂತ್ರ ಮೂರು ಬೇರೆ ಘಟನೆಗಳು. VPN ನ ಕೀಪ್‌ಅಲೈವ್ ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು journalctl ನೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಪರದೆ ಕತ್ತಲಾದಾಗ VPN ಸತ್ತಿತು ಎಂದು ಯಾರಾದರೂ ಹೇಳಿದಾಗ, ಮೊದಲ ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ ಎಂದರೆ ಮೂರು ಘಟನೆಗಳಲ್ಲಿ ಯಾವುದು ನಿಜವಾಗಿ ಸಂಭವಿಸಿತು: ಸೆಷನ್ ಲಾಕ್ ಆಯಿತು, ಪ್ಯಾನೆಲ್ ಆಫ್ ಆಯಿತು, ಅಥವಾ ಇಡೀ ಯಂತ್ರ ನಿದ್ರೆಗೆ ಹೋಯಿತು. ಇವು ಬೇರೆ ಬೇರೆ ಟೈಮರ್‌ಗಳಲ್ಲಿನ ಬೇರೆ ಬೇರೆ ಕಾರ್ಯವಿಧಾನಗಳು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಒಂದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಗದಿಗೊಳಿಸುವುದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಡೆಯಬಲ್ಲದು. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ. ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಮೊದಲ ಪರಿಶೀಲನೆಯಲ್ಲೇ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಅದರ ನಂತರದ ಪ್ರತಿ ಪರಿಶೀಲನೆಯೂ ಬೇರೆ ಯಾವುದೋ ಒಂದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ.
ಪರಿಶೀಲನೆ ಒಂದು: ಲಾಕ್ ಅನ್ನು ಬ್ಲಾಂಕ್ ಮತ್ತು ನಿದ್ರೆಯಿಂದ ಬೇರ್ಪಡಿಸಿ
ಲಾಕ್ ಸೆಷನ್ ಅನ್ನು ಯಾರು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ; ಕಂಪೋಸಿಟರ್ ಚಿತ್ರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ, ನೆಟ್‌ವರ್ಕ್ ಸ್ಟಾಕ್ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು VPN ಕ್ಲೈಂಟ್‌ಗೆ ಏನೂ ತಿಳಿಯುವುದಿಲ್ಲ. ಪರದೆಯ ಬ್ಲಾಂಕಿಂಗ್ ನಿಷ್ಕ್ರಿಯ ಅವಧಿಯ ನಂತರ ಪ್ಯಾನೆಲ್ ಆಫ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಯಂತ್ರವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಎಚ್ಚರದಲ್ಲೇ ಬಿಡುತ್ತದೆ. ಸಸ್ಪೆಂಡ್ ಪ್ರೊಸೆಸರ್‌ಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಅಂದರೆ ಬಳಕೆದಾರ-ಸ್ಥಳದ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆ ನಿಗದಿಯಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮಧ್ಯಂತರವನ್ನು ಎಷ್ಟೇ ಚಿಕ್ಕದಾಗಿ ಇಟ್ಟರೂ ಯಾವುದೇ ಕೀಪ್‌ಅಲೈವ್ ಚಾಲನೆಯಾಗಲಾರದು.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
ಆ ಕೋಷ್ಟಕವೇ «ಪರದೆ ಕತ್ತಲಾಯಿತು» ಎಂಬುದು ರೋಗನಿರ್ಣಯ ಅಲ್ಲ ಎಂಬುದಕ್ಕೆ ಕಾರಣ. ಐದು ನಿಮಿಷಕ್ಕೆ ಬ್ಲಾಂಕ್ ಮತ್ತು ಮೂವತ್ತಕ್ಕೆ ಸಸ್ಪೆಂಡ್ ಎಂದು ಹೊಂದಿಸಿದ ಡೆಸ್ಕ್‌ಟಾಪ್ ಆರನೇ ನಿಮಿಷದಲ್ಲಿ ಕತ್ತಲೆಯ ಪರದೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಟನೆಲ್ ಸಂಪೂರ್ಣ ಆರೋಗ್ಯವಾಗಿರುತ್ತದೆ. ಮೂವತ್ತನೇ ನಿಮಿಷದ ವೈಫಲ್ಯ ಬೇರೆ ಘಟನೆ ಮತ್ತು ಬೇರೆ ಪರಿಹಾರ, ಮತ್ತು ಕೊಠಡಿಯ ಇನ್ನೊಂದು ತುದಿಯಿಂದ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.
ಪರಿಶೀಲನೆ ಎರಡು: ವಿದ್ಯುತ್ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಘಟನೆಗಳನ್ನು ಒಂದೇ ಸಮಯರೇಖೆಯಲ್ಲಿ ಇರಿಸಿ
ಇಡೀ ಬೂಟ್‌ಗಿಂತ ಸೀಮಿತ ಅವಧಿಯ ಜರ್ನಲ್ ಓದಿ, ಮತ್ತು ಲಾಗಿನ್ ನಿರ್ವಾಹಕ ಹಾಗೂ ಸಂಪರ್ಕದ ಮಾಲೀಕ ಇಬ್ಬರನ್ನೂ ಸೇರಿಸಿ:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listಮೊದಲ ಆದೇಶ ನಿದ್ರೆಯ ವಿನಂತಿಗಳು, ಎಚ್ಚರಗೊಳ್ಳುವಿಕೆ ಮತ್ತು ಅವುಗಳ ನಂತರದ ನೆಟ್‌ವರ್ಕ್ ಪರಿವರ್ತನೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಈಗ ಯಾವುದು ತಡೆತಡೆಯ ಬೀಗವನ್ನು ಹಿಡಿದಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ಯಾವುದೋ ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿದ್ರೆಯನ್ನು ತಡೆಯುತ್ತಿದೆಯೇ ಮತ್ತು ಅದು ಯಾವ ಪ್ರೋಗ್ರಾಂ ಎಂಬುದನ್ನು ನಿಮಗೆ ಹೇಳುತ್ತದೆ. ನಿಮ್ಮ ಸಂಪರ್ಕದ ಮಾಲೀಕ NetworkManager ಅಲ್ಲದಿದ್ದರೆ ಘಟಕಗಳ ಹೆಸರುಗಳನ್ನು ಸರಿಪಡಿಸಿ, ಮತ್ತು ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರ ಘಟಕ ಅಥವಾ ಸಿಸ್ಟಮ್ ಜರ್ನಲ್ ಓದುವುದು ಸ್ಥಳೀಯ ನೀತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದು ನೆನಪಿಡಿ.
ಕಾಣೆಯಾದ ಸಾಲು ಋಣಾತ್ಮಕ ಫಲಿತಾಂಶವಲ್ಲ. ಆಯ್ಕೆ ಮಾಡಿದ ಘಟಕದ ಜರ್ನಲ್ ನಿಮ್ಮ ಖಾತೆಗೆ ಕಾಣದಿದ್ದರೆ, ಸಸ್ಪೆಂಡ್ ದಾಖಲೆಯ ಅನುಪಸ್ಥಿತಿ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಖಾಲಿ ಫಿಲ್ಟರ್‌ನಿಂದ «ಅದು ಎಂದೂ ನಿದ್ರಿಸಲಿಲ್ಲ» ಎಂದು ತೀರ್ಮಾನಿಸುವುದು ಜನರು ಒಂದು ವಾರ ಕೀಪ್‌ಅಲೈವ್ ಸರಿಹೊಂದಿಸುವಲ್ಲಿ ಕಳೆಯುವ ದಾರಿ.
ಪರಿಶೀಲನೆ ಮೂರು: ಅದು ನಿದ್ರಿಸಿದ್ದರೆ, ಅದು ಉದ್ದೇಶಪೂರ್ವಕವೇ ಎಂದು ನಿರ್ಧರಿಸಿ
ಸಮಯರೇಖೆಯಲ್ಲಿ ನಿದ್ರೆಯ ಪರಿವರ್ತನೆ ಕಾಣುತ್ತಿದ್ದಂತೆ, ಪ್ರಶ್ನೆ «VPN ಏಕೆ ಮುರಿಯಿತು» ಎಂಬುದರಿಂದ «ಯಂತ್ರವು ನಿಜವಾಗಿಯೂ ನಿದ್ರಿಸಬೇಕಿತ್ತೇ» ಎಂಬುದಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ. ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಉತ್ತರ ಸಾಮಾನ್ಯವಾಗಿ ಹೌದು, ಮತ್ತು ಟನೆಲ್ ಕಡಿತವು ನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆ, ಕ್ಲೈಂಟ್ ಎಚ್ಚರಗೊಳ್ಳುವಾಗ ಅದರಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು. ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕಾದ ಕಾರ್ಯಸ್ಥಳದಲ್ಲಿ ಬದಲಾಯಿಸಬೇಕಾದದ್ದು ನಿದ್ರೆಯ ನೀತಿ. ಈ ಎರಡು ಯಂತ್ರಗಳಲ್ಲಿ ಯಾವುದನ್ನು ನೀವು ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿರ್ಧರಿಸಲು ಒಂದು ಪ್ರಶ್ನೆ ಬೇಕು, ಮತ್ತು ಅದು ಜರ್ನಲ್ ನಿಮ್ಮ ಬದಲಿಗೆ ಉತ್ತರಿಸಬಲ್ಲ ಪ್ರಶ್ನೆಯಲ್ಲ.
ಲಾಗಿನ್ ಆದ ಸೆಷನ್‌ಗೆ ಸೇರಿದ ನಿಯಂತ್ರಣಗಳ ಮೂಲಕ ಅಥವಾ ಅವಶ್ಯಕತೆ ಇಡೀ ಯಂತ್ರಕ್ಕೆ ಅನ್ವಯಿಸಿದರೆ ನಿರ್ವಾಹಕ ಬೆಂಬಲಿತ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಅದನ್ನು ಬದಲಾಯಿಸಿ. ಬೇರೆ ಖಾತೆಯಲ್ಲಿ ಲಾಗಿನ್ ಆಗಿರುವಾಗ ಡಿಸ್‌ಪ್ಲೇ ನಿರ್ವಾಹಕದ ಸೆಟ್ಟಿಂಗ್ ಸಂಪಾದಿಸುವುದು ಅದೇ ಕ್ರಿಯೆಯಲ್ಲ ಮತ್ತು ಮುಂದಿನ ಸೆಷನ್ ಪ್ರಾರಂಭವಾಗುವವರೆಗೆ ಅದು ಕೆಲಸ ಮಾಡಿದಂತೆ ಕಾಣುತ್ತದೆ. ವಿದ್ಯುತ್ ನಿರ್ವಹಣೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಬ್ಯಾಟರಿ ಆಯುಷ್ಯವನ್ನು ವ್ಯಯಿಸುವ ಮತ್ತು ನಿಜವಾದ ನೀತಿ ಪ್ರಶ್ನೆಯನ್ನು ಮುಚ್ಚಿಡುವ ವಿಶಾಲ ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆ.
ಪರಿಶೀಲನೆ ನಾಲ್ಕು: ಅದು ಎಚ್ಚರವಾಗಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನೋಡಿ
ತನ್ನ ಟನೆಲ್ ಕಳೆದುಕೊಂಡ ಎಚ್ಚರದ ಯಂತ್ರಕ್ಕೆ ಮೂರು ಕಥೆಗಳಲ್ಲಿ ಒಂದು ಇರುತ್ತದೆ: ಪ್ರವೇಶ ನೆಟ್‌ವರ್ಕ್ ಬಿದ್ದಿತು, VPN ಕ್ಲೈಂಟ್ ನಿಂತಿತು ಅಥವಾ ಮರುಪ್ರಾರಂಭವಾಯಿತು, ಅಥವಾ ಸರ್ವರ್ ಬದಿ ಸಂಬಂಧವನ್ನು ಮುಗಿದುಹೋಗಲು ಬಿಟ್ಟಿತು ಆದರೆ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕದಲ್ಲಿದೆ ಎಂದು ನಂಬಿತ್ತು. ಆಧಾರವಾದ ಲಿಂಕ್ ಘಟನೆಯ ಸಮಯಮುದ್ರೆಗಳನ್ನು ಟನೆಲ್ ಘಟನೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಯಾವುದು ಮೊದಲು ಬಂತು ಎಂಬುದರಲ್ಲಿ ನಿಖರವಾಗಿರಿ.
ನಂತರ ಮೂಲ ಸೆಷನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಚೇತರಿಕೆಯ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ. ಚೇತರಿಸಿದ ಟನೆಲ್ ಮೂಲಕ ಹೊಸ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗಬಹುದು, ಆದರೆ ಕಡಿತಕ್ಕೆ ಮೊದಲು ತೆರೆದ ದೀರ್ಘಾವಧಿಯ ಅಪ್ಲಿಕೇಶನ್ ಸೆಷನ್ ಮುರಿದೇ ಉಳಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಅಪ್ಲಿಕೇಶನ್ ಹಳೆಯ ಸಾಕೆಟ್ ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಿದ ವಿಳಾಸವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡಿದೆ. ಅದು ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆ, ಟನೆಲ್ ಹಿಂತಿರುಗಲಿಲ್ಲ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಉಪಯುಕ್ತ ವರದಿಯಲ್ಲಿ ಏನಿರುತ್ತದೆ
ಸಮಯಮುದ್ರೆಗಳು ಮತ್ತು ಮಾಲೀಕರೊಂದಿಗೆ ಕ್ರಮವನ್ನು ಬರೆಯಿರಿ: ಸೆಷನ್ ಯಾವಾಗ ಲಾಕ್ ಆಯಿತು, ಪರದೆ ಯಾವಾಗ ಕತ್ತಲಾಯಿತು, ನಿದ್ರೆಯ ವಿನಂತಿ ದಾಖಲಾಯಿತೇ, ಲಿಂಕ್ ಯಾವಾಗ ಬಿದ್ದು ಮರಳಿ ಬಂತು, ಟನೆಲ್ ಯಾವಾಗ ಸ್ಥಿತಿ ಬದಲಾಯಿಸಿತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಏನು ಮಾಡಿತು. ಪ್ರತಿ ಅಂಶಕ್ಕೂ ಮಾಲೀಕ ಇದ್ದಾನೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಅಂಶವನ್ನೂ Linux ಬಗ್ಗೆ ಸಾಮಾನ್ಯ ದೂರಾಗುವ ಬದಲು ಸರಿಯಾದ ವ್ಯಕ್ತಿಗೆ ನೀಡಬಹುದು.
ಈ ಸಾಲುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಕಾಣೆಯಾಗಿದ್ದರೆ, ಅದು ಮುಂದೆ ಅಳೆಯಬೇಕಾದ ವಿಷಯ, ಮುಂದೆ ಬದಲಾಯಿಸಬೇಕಾದ ವಿಷಯವಲ್ಲ. ಅಂತರವಿರುವ ಸಮಯರೇಖೆ ಊಹೆಯ ಮೇಲೆ ಮಾಡಿದ ಸೆಟ್ಟಿಂಗ್ ಬದಲಾವಣೆಗಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಕರ.