L2TP ಡೀಬಗ್ ಲಾಗ್ ಖಾಲಿಯಾಗಿದೆಯೇ? ದೋಷ ಬಹುಶಃ ಜರ್ನಲ್ನಲ್ಲಿದೆ

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

ನಾಲ್ಕು ಪ್ರಕ್ರಿಯೆಗಳು, ಲಾಗ್ನ ಎರಡು ಗಮ್ಯಸ್ಥಾನಗಳು

ಸಂಪರ್ಕವು IPsec ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಅದು ಸ್ಥಾಪನೆಯ ಆಧಾರದ ಮೇಲೆ libreswan ಅಥವಾ strongSwan ಆಗಿರುತ್ತದೆ. ನಂತರ L2TP ಡೀಮನ್, ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ xl2tpd ಮತ್ತು ಕೆಲವು ಬಿಲ್ಡ್ಗಳಲ್ಲಿ kl2tpd, ಟನಲ್ ನಡೆಸುತ್ತದೆ. ಕೊನೆಯದಾಗಿ pppd ಅದರ ಒಳಗೆ ದೃಢೀಕರಣ ಮತ್ತು ವಿಳಾಸೀಕರಣವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಸಹಾಯಕ ಸೇವೆ ಆ ಭಾಗಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ತನ್ನದೇ ಪ್ರಗತಿಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. IPsec ಡೀಮನ್ ಮತ್ತು pppd ಸಾಮಾನ್ಯವಾಗಿ ಸಿಸ್ಟಮ್ ಜರ್ನಲ್ ಮೂಲಕ ವರದಿ ಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಟರ್ಮಿನಲ್ ವಿಫಲವಾಗುವ ಸಂಪರ್ಕವನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಕಾರಣ ನೀವು ತೆರೆಯದ ಫೈಲ್ನಲ್ಲಿದೆ.

ಈ ವಿಭಜನೆ PSK ದೋಷ ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ದೋಷ ಡೆಸ್ಕ್ಟಾಪ್ನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುವುದನ್ನು ಸಹ ವಿವರಿಸುತ್ತದೆ: ಎರಡೂ ಸಾಮಾನ್ಯ ಸಂಪರ್ಕ ಕಡಿತವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ, ಮತ್ತು ವಿಫಲವಾದ ಹಂತವು ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಮಾತ್ರ ಕಾಣುತ್ತದೆ. ಇಲ್ಲಿ ಜರ್ನಲ್ ಮುಖ್ಯವಾಗುವ ಸಂಪೂರ್ಣ ಕಾರಣ ಅದೇ. ಡೆಸ್ಕ್ಟಾಪ್ನಲ್ಲಿ ಒಂದು ಸಾಮಾನ್ಯ ಸಂದೇಶ, ಅದರ ಹಿಂದೆ ನಾಲ್ಕು ಸಂಭಾವ್ಯ ಲೇಖಕರು.

ಒಂದು ಪ್ರಯತ್ನವನ್ನು ಸಂಗ್ರಹಿಸಿ, ನಂತರ ಕ್ರಮವನ್ನು ಓದಿ

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

ಈ ಆದೇಶಗಳು ಪ್ರಸ್ತುತ ಬೂಟ್ಗೆ ಭಾಗವಹಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮ ವಿತರಣೆಯಲ್ಲಿ ಪ್ಲಗಿನ್ ಮಾರ್ಗವನ್ನು ಖಚಿತಪಡಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

ಒಂದು ಕರೆಯಲ್ಲಿ ಪುನರಾವರ್ತಿತ ಕ್ಷೇತ್ರಗಳು ಆ ಪ್ರಕ್ರಿಯೆಗಳ ಒಕ್ಕೂಟವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ, ಇದು ಅನುಕ್ರಮವನ್ನು ಸಮಯ ಕ್ರಮದಲ್ಲಿ ಇಡುತ್ತದೆ. Debian ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಮಾನ ಪ್ರಶ್ನೆ dpkg -L ಆಗಿದೆ; ಮುಖ್ಯ ಅಂಶವೆಂದರೆ ಸಹಾಯಕವನ್ನು ಕೈಯಿಂದ ಚಲಾಯಿಸುವ ಮೊದಲು ಅದು ನಿಜವಾಗಿ ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು.

ಮುಂದಿನ ಹೆಜ್ಜೆಯನ್ನು ಮೂರು ಷರತ್ತುಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ

ಮೊದಲ ವಿಫಲ ಹಂತವನ್ನು ಓದಿ, ನಂತರ ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿ. IPsec ಪ್ರಸ್ತಾವನೆ ಅಥವಾ ಸಹಚರ ದೃಢೀಕರಣದ ವೈಫಲ್ಯವನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಟನಲ್ ಎಂದೂ ರೂಪುಗೊಂಡಿಲ್ಲ, ಮತ್ತು PPP ಪಾಸ್ವರ್ಡ್ ಬದಲಿಸುವುದರಿಂದ ಸಹಾಯವಾಗುವುದಿಲ್ಲ.

ಟನಲ್ ರೂಪುಗೊಂಡು pppd ಲಾಗಿನ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಿದರೆ, ಹಂಚಿದ ರಹಸ್ಯ ಈಗಾಗಲೇ ಸರಿಯಾಗಿತ್ತು ಮತ್ತು ರುಜುವಾತು ಸಮಸ್ಯೆ ಒಂದು ಪದರ ಮೇಲಿದೆ. pppd ವಿಳಾಸದ ಬಗ್ಗೆ ಮಾತುಕತೆ ನಡೆಸಿ ವೈಫಲ್ಯ ನಂತರ ಕಾಣಿಸಿಕೊಂಡರೆ, ಎರಡೂ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ ಮತ್ತು ಉಳಿದ ಸಮಸ್ಯೆ ರೂಟಿಂಗ್, DNS ಅಥವಾ ಸರ್ವರ್ನ ಸ್ವಂತ ನೀತಿ.

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

ಡೀಬಗ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಯಾವ IPsec ಬ್ಯಾಕೆಂಡ್ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸುವುದೂ ಯೋಗ್ಯ. strongSwan ಗಾಗಿ ಬರೆದ ಲಾಗಿಂಗ್ ಆಯ್ಕೆ libreswan ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಯಾರೂ ಓದದ ಫೈಲ್ ಅನ್ನು ನೀವು ಸಂಪಾದಿಸುತ್ತಿರುವಾಗ ಸಂಪರ್ಕ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತಲೇ ಇರುತ್ತದೆ.

ಡೀಬಗ್ ಮೋಡ್ ಫೈಲ್ಗಳನ್ನು ಬಿಡುತ್ತದೆ

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

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

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

ನಂತರ ಸಾಮಾನ್ಯ ಸಹಾಯಕವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ

ತನಿಖೆ ಮುಗಿದಾಗ ಕೈಯಿಂದ ಚಲಾಯಿಸಿದ ಪ್ರತಿಯನ್ನು ನಿಲ್ಲಿಸಿ, ಉಳಿಸಿಟ್ಟ ರನ್ಟೈಮ್ ಫೈಲ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಸಾಮಾನ್ಯ ಮಾರ್ಗದ ಮೂಲಕ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ವಾಸ್ತವಕ್ಕೆ ಹೊಂದುವ ಕಾನ್ಫಿಗರೇಶನ್ ನೋಡಲಿ.

ನಂತರ ಫಲಿತಾಂಶವನ್ನು ವಿಫಲವಾದ ಪದರದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ, ಡೆಸ್ಕ್ಟಾಪ್ ಐಕಾನ್ನಲ್ಲಿ ಅಲ್ಲ:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

ದೃಢೀಕರಣ ಮಾಡುವ, ವಿಳಾಸ ಪಡೆಯುವ ಮತ್ತು ಉದ್ದೇಶಿತ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ರೂಟ್ ಮಾಡುವ ಸೆಷನ್ ನೀವು ಡೀಬಗ್ ಮಾಡುತ್ತಿದ್ದ ಫಲಿತಾಂಶ. ವಿಫಲ ಪ್ರಯತ್ನದ ಸಮಯದಲ್ಲಿ ಮೌನ ಟರ್ಮಿನಲ್ ನಿಮಗೆ ಕೇವಲ ಔಟ್ಪುಟ್ ಎಲ್ಲಿ ಬರೆಯಲಿಲ್ಲ ಎಂಬುದನ್ನು.