PAM ಮಾಡ್ಯೂಲ್ ಅಜ್ಞಾತವಾಗಿದೆ: ವಾಸ್ತವವಾಗಿ ಯಾವ ಪ್ರಕ್ರಿಯೆ ವಿಫಲವಾಯಿತು

ಆ ವಾಕ್ಯವನ್ನು ಪಾಸ್ವರ್ಡ್ ಬಗ್ಗೆ ಅಲ್ಲ, ಹಂಚಿಕೆಯ ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಫಂಕ್ಷನ್ ಪಾಯಿಂಟರ್ ಬಗ್ಗೆ ಹೇಳಿಕೆಯಾಗಿ ಓದಿ. ಅದೇ ಪದಗಳು ಒಂದು OpenVPN ಪ್ಲಗಿನ್ನಿಂದ, ಒಂದು ಸೇವೆಗೆ ಲೋಡ್ ಮಾಡಿದ PAM ಸ್ಟಾಕ್ನಿಂದ, ಅಥವಾ RADIUS ಡೀಮನ್ ಒಳಗಿನಿಂದ ಬರಬಹುದು, ಮತ್ತು ಇವು ಮೂರು ವಿಭಿನ್ನ ತನಿಖೆಗಳು. ಮೊದಲು ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ಧರಿಸಿ.

ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳು ಸಂದೇಶವು VPN ಲಾಗಿನ್ನಲ್ಲಿ Linux-PAM ಏಕೀಕರಣದ ಮೂಲಕ ಬಂದಿದೆ ಎಂದು ಊಹಿಸುತ್ತವೆ. ಅದು RADIUS ಸರ್ವರ್ನ ಸ್ವಂತ ಸಂರಚನೆಯಿಂದ ಬಂದಿದ್ದರೆ, ಆ ಡೀಮನ್ನ ಸಾಕ್ಷ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸಿ.

ಪ್ಯಾಕೇಜ್ ಹೆಸರಿಸುವ ಮೊದಲು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಸರಿಸಿ

ಮೂರು ಅಂಶಗಳನ್ನು ಮಾಡ್ಯೂಲ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗದು. OpenVPN ದೃಢೀಕರಣ ಪ್ಲಗಿನ್ ಅನ್ನು VPN ಡೀಮನ್ ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಆ ಡೀಮನ್ನ ಕಾಲ್ಬ್ಯಾಕ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ. PAM ಮಾಡ್ಯೂಲ್ ಒಂದು ಹಂಚಿಕೆಯ ಆಬ್ಜೆಕ್ಟ್, ಅದನ್ನು libpam ಹೆಸರಿಸಿದ ಸೇವೆಗಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ಈ ರೀತಿಯ ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತದೆ: pam_sm_authenticate. FreeRADIUS ಮಾಡ್ಯೂಲ್ ಆ ಡೀಮನ್ನ ಸ್ವಂತ ಸಂರಚನೆಯ ಒಂದು ಭಾಗ. ಅದೇ ಪದಗಳಿರುವ ಸಂದೇಶ ಮೂರರಲ್ಲಿ ಯಾವುದರಿಂದಲಾದರೂ ಬರಬಹುದು, ಆದ್ದರಿಂದ ಮೊದಲ ಪ್ರಶ್ನೆ ಎಂದರೆ ಯಾವ ಲಾಗ್ ಸಾಲು ಅದನ್ನು ಉತ್ಪಾದಿಸಿತು.

ಒಂದು ವಿಫಲ ಪ್ರಯತ್ನದ ಸಮಯಮುದ್ರೆಯನ್ನು VPN ಲಾಗ್ ಮತ್ತು ಸಿಸ್ಟಂ ದೃಢೀಕರಣ ಲಾಗ್ ನಡುವೆ ಹೊಂದಿಸಿ, ನಂತರ ಸಾರಾಂಶಕ್ಕಿಂತ ಮೊದಲಿನ ಸಾಲುಗಳನ್ನು ಓದಿ. ನಿರ್ದಿಷ್ಟ ಲೋಡರ್ ಸಂದೇಶ ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲಿಯೇ ಇರುತ್ತದೆ.

ಲೋಡಿಂಗ್ ದೋಷವನ್ನು ಓದಿ, ನಂತರ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು

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

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

ಸ್ಟಾಕ್ ನೀಡುತ್ತಿದ್ದ ಖಾತರಿಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ

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

ಬಹು-ಮಾಡ್ಯೂಲ್ ಸ್ಟಾಕ್ ವಿಫಲ ನಮೂದಿಗಿಂತ ಮೊದಲು ಇನ್ನೊಂದು ಬ್ಯಾಕೆಂಡ್ ಚಲಾಯಿಸಿದ್ದಿರಬಹುದು, ಆದ್ದರಿಂದ ಈ ದೋಷ ಯಾವುದೇ RADIUS ವಿನಂತಿ ಕಳುಹಿಸಲಾಗಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಮಾಡ್ಯೂಲ್ ಅಲ್ಲ, ಲಾಗಿನ್ ಪರಿಶೀಲಿಸಿ

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

ಮಾಡ್ಯೂಲ್ ಸ್ವಚ್ಛವಾಗಿ ಲೋಡ್ ಆಗುವುದು ಪ್ರಗತಿ, ಪೂರ್ಣಗೊಂಡ ಪರೀಕ್ಷೆ ಅಲ್ಲ.

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