VPN ಲಾಗ್ಗಳಿಗಾಗಿ journalctl: ಯಾವ ಯುನಿಟ್ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿದೆ?

ನಿಮಗೆ ನೆನಪಿರುವ ಲಾಗ್ ಆಜ್ಞೆಯಿಂದ ಅಲ್ಲ, VPN ಸಂಪರ್ಕವನ್ನು ನಿಜವಾಗಿ ಹೊಂದಿರುವ systemd ಯುನಿಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ನೇರ OpenVPN ಸೇವೆ, wg-quick ಯುನಿಟ್ ಮತ್ತು NetworkManager ಪ್ರೊಫೈಲ್ ತಮ್ಮ ಉಪಯುಕ್ತ ಸಂದೇಶಗಳನ್ನು ಬೇರೆ ಬೇರೆ ಯುನಿಟ್ಗಳಲ್ಲಿ ಇಡುತ್ತವೆ, ಮತ್ತು ತಪ್ಪು ಯುನಿಟ್ಗೆ ಮಾಡಿದ ಪ್ರಶ್ನೆ ಮೌನದಂತೆ ಕಾಣುವ ಖಾಲಿ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ. ಮೂರು ಸಾಮಾನ್ಯ ಮಾಲೀಕರನ್ನು ಹೋಲಿಸಿ, ವಿಂಡೋವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿ, ನಂತರ ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ಓದಿ.

ಮೂರು ಸಾಮಾನ್ಯ ಮಾಲೀಕರನ್ನು ಹೋಲಿಸಿ

OpenVPN ಕ್ಲೈಂಟ್ ಸೇವೆ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರೊಫೈಲ್ನ ಹೆಸರಿನ ಇನ್ಸ್ಟಾನ್ಸ್ ಯುನಿಟ್ ಆಗಿರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ [email protected]. ಅದರ ಸಂದೇಶಗಳಲ್ಲಿ ಸಂರಚನಾ ಮಾರ್ಗ, ಆಯ್ಕೆಗಳ ವಿಶ್ಲೇಷಣೆ, TLS ಕೈಚಾಚುವಿಕೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಮಾಡುವ ಮಾರ್ಗ ಸ್ಥಾಪನೆ ಸೇರಿವೆ.

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

NetworkManager ತಾನು ರಚಿಸಿದ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಆಧಾರವಾಗಿರುವ ಪ್ಲಗಿನ್ VPN ಸಹಾಯಕವಾಗಿದ್ದರೂ ಅದರ ಸಂದೇಶಗಳು NetworkManager.service ಅಡಿಯಲ್ಲಿ ಇರುತ್ತವೆ. ಪ್ರೊಫೈಲ್ ಆ ರೀತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಲ್ಪಟ್ಟಾಗ ನಿರ್ವಾಹಕ ಮತ್ತು ಸಹಾಯಕ ಯುನಿಟ್ ಎರಡನ್ನೂ ಕೇಳಿ.

ಪ್ರಶ್ನೆಯನ್ನು ಒಂದು ಯುನಿಟ್ ಮತ್ತು ಒಂದು ವಿಂಡೋಗೆ ಸಂಕುಚಿತಗೊಳಿಸಿ

ನೀವು ಗುರುತಿಸಿದ ಯುನಿಟ್ ಅನ್ನು ಕೇಳಿ, ಮತ್ತು ನೀವು ತನಿಖೆ ಮಾಡುತ್ತಿರುವ ಪ್ರಯತ್ನಕ್ಕೆ ಸಮಯವನ್ನು ಸೀಮಿತಗೊಳಿಸಿ. ಒಂದು ದಿನ ಸಾಮಾನ್ಯವಾಗಿ ಸಾಕು, ಮತ್ತು ಯಂತ್ರವು ಪದೇ ಪದೇ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡಾಗ ಚಿಕ್ಕ ವಿಂಡೋ ಉತ್ತಮ.

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

ಮೊದಲ ವಿಫಲ ಹಂತವನ್ನು ಓದಿ

ಘಟನೆಗಳು ಸಂಭವಿಸುವ ಕ್ರಮದಲ್ಲಿ ಓದಿ: ಎಂಡ್ಪಾಯಿಂಟ್ ಹುಡುಕಾಟ, ಸಾಗಣೆ, ಗುರುತು, ದೃಢೀಕರಣ, ಮಾರ್ಗ ಸ್ಥಾಪನೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ನಂತರದ ವೈಫಲ್ಯ. ಮೊದಲ ನಿರ್ದಿಷ್ಟ ವೈಫಲ್ಯವೇ ತನಿಖೆಗೆ ಅರ್ಹವಾದದ್ದು, ಏಕೆಂದರೆ ಅದರ ನಂತರದ ಎಲ್ಲವೂ ಪರಿಣಾಮ.

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

ವಿಫಲ ಸೇವೆಯನ್ನು ಕೈಯಿಂದ ಚಲಾಯಿಸಿದ ಕ್ಲೈಂಟ್ನೊಂದಿಗೆ ಬೆರೆಸಬೇಡಿ

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

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

ರಫ್ತು ಅಲ್ಲ, ಆಯ್ದ ಭಾಗವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ

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

ಸಂಕುಚಿತ ವಿಂಡೋ, ಯುನಿಟ್ನ ಹೆಸರು ಮತ್ತು ಮೊದಲ ವಿಫಲ ಹಂತವನ್ನು ಕಳುಹಿಸಿ, ಮತ್ತು ನೀವು ಈಗಾಗಲೇ ಏನನ್ನು ಹೊರಗಿಟ್ಟಿದ್ದೀರಿ ಎಂದು ಹೇಳಿ. systemd journalctl ಕೈಪಿಡಿ ಆಯ್ಕೆಕಾರರು ಮತ್ತು ಔಟ್ಪುಟ್ ಆಯ್ಕೆಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ನಿಮ್ಮ ವಿತರಣೆಯ ಆವೃತ್ತಿ ಬೆಂಬಲಿಸುವ ಸ್ವರೂಪ ಬೇಕಾದರೆ.