OpenVPN PAM: login ಆರ್ಗ್ಯುಮೆಂಟ್ ಒಂದು ಸೇವೆ, ಬಳಕೆದಾರರಲ್ಲ

ಸರ್ವರ್ನಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸಲಾಗಿತ್ತು, ಪಾಸ್ವರ್ಡ್ ಸರಿಯಾಗಿ ಟೈಪ್ ಮಾಡಲಾಗಿತ್ತು, ಆದರೂ ಸಂಪರ್ಕವು ಇನ್ನೂ AUTH_FAILED ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಲಗಿನ್ ಸಾಲೇ ಕಾರಣವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಪ್ಲಗಿನ್ ಮಾರ್ಗದ ನಂತರ ಬರುವ ಪದವು PAM ಸೇವಾ ಹೆಸರು, ಮತ್ತು ಯಾವ ಮಾಡ್ಯೂಲ್ಗಳ ಗುಂಪು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅದೇ ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದು ಬಳಕೆದಾರರ ಹೆಸರಲ್ಲ, ಮತ್ತು OpenVPN ಸ್ವತಃ ಓದುವ ಪಾಸ್ವರ್ಡ್ ಫೈಲ್ನ ಸೂಚಕವೂ ಅಲ್ಲ.

ಎರಡನೇ ಪದ ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ

ಸಂರಚನಾ ಸಾಲು ಒಂದು ಪ್ಲಗಿನ್ ಮಾರ್ಗ ಮತ್ತು ಒಂದು ಆರ್ಗ್ಯುಮೆಂಟ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

ಆ ಆರ್ಗ್ಯುಮೆಂಟ್ ಸೇವಾ ಹೆಸರಾಗಿ PAM ಲೈಬ್ರರಿಗೆ ರವಾನೆಯಾಗುತ್ತದೆ, ಹೀಗಾಗಿ /etc/pam.d/openvpn ನಲ್ಲಿರುವ ಸ್ಟ್ಯಾಕ್ ಚಾಲನೆಯಾಗುತ್ತದೆ. ಅಲ್ಲಿ login ಎಂದು ಬರೆದರೆ ಬದಲಾಗಿ ಸಂವಾದಾತ್ಮಕ ಲಾಗಿನ್ ನೀತಿ ಸಿಗುತ್ತದೆ, ನಿಮ್ಮ ವಿತರಣೆಯಲ್ಲಿ ಆ ನೀತಿ ಒಳಗೊಂಡಿರುವ ಮಾಡ್ಯೂಲ್ಗಳೂ ಸೇರಿ.

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

ಸ್ಟ್ಯಾಕ್ ವಾಸ್ತವವಾಗಿ ಖಾತೆಗಳನ್ನು ಓದುವ ಸ್ಥಳ

PAM ಒಂದು ಡಿಸ್ಪ್ಯಾಚರ್. ಸೇವಾ ಫೈಲ್ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಕ್ರಮದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಿಸಬಲ್ಲ ಮೊದಲನೆಯದು ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. pam_unix ಅನ್ನು ಕರೆಯುವ ಸ್ಟ್ಯಾಕ್ ಸ್ಥಳೀಯ ಖಾತೆಗಳನ್ನು ಓದುತ್ತದೆ; LDAP ಅಥವಾ RADIUS ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಕರೆಯುವ ಸ್ಟ್ಯಾಕ್ ರುಜುವಾತುಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಡೆಗೆ ಕಳುಹಿಸುತ್ತದೆ.

ಸೇವಾ ಹೆಸರು ಬಿಡಿಸುವ ಫೈಲ್ ಅನ್ನು ಓದಿ, ಅದು ಒಳಗೊಳ್ಳುವ ಎಲ್ಲವನ್ನೂ ಸೇರಿಸಿ:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

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

ಒಂದು ಪ್ರಯತ್ನ, ಎರಡು ಲಾಗ್ಗಳು

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

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

VPN ಮತ್ತು ಸ್ಟ್ಯಾಕ್ ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಡೀಬಗ್ ಮಾಡದಿರಲು, PAM ಮಾತನಾಡುವ ಯುಟಿಲಿಟಿಯಿಂದ ಸೇವೆಯನ್ನು ನೇರವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಅದೇ ಸೇವಾ ಹೆಸರು ಮತ್ತು ಖಾತೆಯೊಂದಿಗೆ ನೇರ ಪರೀಕ್ಷೆ ಯಶಸ್ವಿಯಾದರೆ ಸಮಸ್ಯೆ ಖಾತೆಯದ್ದಲ್ಲ, ಡೀಮನ್ ರುಜುವಾತುಗಳನ್ನು ಹೇಗೆ ರವಾನಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸೀಮಿತವಾಗುತ್ತದೆ.

pamtester openvpn alice authenticate

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

ಮೀಸಲಾದ ಸೇವೆ login ಸಂಪಾದನೆಗಿಂತ ಉತ್ತಮ

VPN ನ ಅಗತ್ಯಗಳು ಸಂವಾದಾತ್ಮಕ ಲಾಗಿನ್ನಿಂದ ಭಿನ್ನವಾದಾಗ, ಸಾಮಾನ್ಯವಾಗಿ ಅವು ಭಿನ್ನವಾಗಿರುತ್ತವೆ, ಅದಕ್ಕೆ ತನ್ನದೇ ಸೇವಾ ಫೈಲ್ ಕೊಡಿ. login ಅಥವಾ common-auth ಸಂಪಾದಿಸಿದರೆ ಅವನ್ನು ಒಳಗೊಳ್ಳುವ ಪ್ರತಿ ಪ್ರೋಗ್ರಾಂನ ನೀತಿಯೂ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ ಲಾಗಿನ್ ಸಮಸ್ಯೆಯನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ನಿಮ್ಮ ಬದಲಾವಣೆಯನ್ನು ವಾರಸುದಾರನಾಗಿ ಪಡೆಯುತ್ತಾನೆ.

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

ಕ್ಲೈಂಟ್ ಏನನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಏನನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ

ಕ್ಲೈಂಟ್ ತನ್ನ ಬೆಂಬಲಿತ ಪ್ರಾಂಪ್ಟ್ ಅಥವಾ ಫೈಲ್ ಮೂಲಕ ಬಳಕೆದಾರರ ಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಒದಗಿಸುತ್ತದೆ. ಸರ್ವರ್ ಪ್ಲಗಿನ್ ಆ ಮೌಲ್ಯಗಳನ್ನು PAM ಸಂಭಾಷಣೆಗೆ ರವಾನಿಸುತ್ತದೆ; ಅವನ್ನು ಸರ್ವರ್ನ ಸಂರಚನೆಯಿಂದ ಓದುವುದಿಲ್ಲ. ಪಾಸ್ವರ್ಡ್ ವ್ಯಾಖ್ಯಾನಿಸುವಂತೆ ಕಾಣುವ ಸರ್ವರ್-ಬದಿಯ ಸಾಲು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವ ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆಯೂ ಖಾತೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.

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

ಸ್ವೀಕಾರವು ಎರಡು ಬದಿಯದು: ಉದ್ದೇಶಿತ ಖಾತೆ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಮತ್ತು ನಿರಾಕರಿಸಬೇಕಾದ ಖಾತೆ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ. auth-pam ಪ್ಲಗಿನ್ README ಸೇವಾ ಆರ್ಗ್ಯುಮೆಂಟ್ ಮತ್ತು ಅದು ಮುಂಭಾಗದಲ್ಲಿ ಇರಿಸಬಹುದಾದ ಬ್ಯಾಕೆಂಡ್ಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ನೀವು ಕಟ್ಟಲು ಹೊರಟಿರುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಖಚಿತಪಡಿಸುವ ಸ್ಥಳ ಅದೇ.