.ovpn ಫೈಲ್ ಸಂಪಾದಿಸುವುದು ಸರ್ವರ್‌ನಲ್ಲಿ MFA ಅನ್ನು ಏಕೆ ಆನ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ

ನೀವು ಪ್ರೊಫೈಲ್‌ಗೆ auth-user-pass ಸೇರಿಸುತ್ತೀರಿ, ಮತ್ತೆ ಸಂಪರ್ಕಿಸುತ್ತೀರಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಕೇಳುತ್ತದೆ. MFA ಆನ್ ಆಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ನಂತರ ನೀವು ತಪ್ಪು ಖಾತೆಯ ಕೋಡ್, ಅಥವಾ ಹತ್ತು ನಿಮಿಷಗಳ ಹಿಂದೆ ಅವಧಿ ಮುಗಿದ ಕೋಡ್ ಟೈಪ್ ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಸುರಂಗವು ಹೇಗಾದರೂ ಮೇಲೇಳುತ್ತದೆ. ಇದೇ ಲಕ್ಷಣ: ಕ್ಲೈಂಟ್ ಬದಲಾಯಿತು, ಸರ್ವರ್ ಬದಲಾಗಲಿಲ್ಲ. ಒಂದು ಬಾರಿಯ ಪಾಸ್‌ವರ್ಡ್ ಸರ್ವರ್‌ನಲ್ಲಿನ ಪರಿಶೀಲಕವು ಅದನ್ನು ಕೇಳುವ ಗುರುತಿಗೆ ಮಾನ್ಯವೇ ಎಂದು ನಿರ್ಧರಿಸಿದಾಗ ಮಾತ್ರ ಒಂದು ಅಂಶವಾಗುತ್ತದೆ.

ವಿನಂತಿ ಕ್ಲೈಂಟ್ ಕೇಳಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಹೆಚ್ಚೇನೂ ಇಲ್ಲ

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

ಫೋನ್‌ನಲ್ಲಿ ದೃಢೀಕರಣ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಾಪಿಸುವುದೂ ಆ ಸಂಬಂಧವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. Google Authenticator PAM ಯೋಜನೆ OTP ಪರಿಶೀಲನೆಯ ಘಟಕವಾಗಿದ್ದು ಅದು OpenVPN ನ ಹಿಂದೆ ಕುಳಿತುಕೊಳ್ಳಬಹುದು; ಆಮದು ಮಾಡಿದ ಪ್ರೊಫೈಲ್‌ಗೆ Google ಖಾತೆ ಲಾಗಿನ್ ಅನ್ನು ಅಂಟಿಸುವ ಮಾರ್ಗ ಅದಲ್ಲ.

ಪ್ರೊಫೈಲ್ ಮಾಡಲಾಗದ ಭಾಗವೇ ನೋಂದಣಿ

TOTP ಗೆ ದೃಢೀಕರಣ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದರ ಪರಿಶೀಲಕದ ನಡುವೆ ಹಂಚಿಕೊಂಡ ನೋಂದಣಿ ಸಾಮಗ್ರಿ ಬೇಕು. ಫೋನ್‌ನಲ್ಲಿನ ಆರು ಅಂಕಿಗಳು ಔಟ್‌ಪುಟ್; ಅವುಗಳ ಹಿಂದಿನ ಬೀಜ ರಹಸ್ಯ, ಮತ್ತು ಅದು ಒಂದೇ ಗುರುತಿಗೆ ಸೇರಿದೆ.

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

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

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

PAM ಸ್ಟಾಕ್ ಓದಿ ನಿಜವಾಗಿ ಏನು ಬೇಕು ಎಂದು ನೋಡಿ

account required pam_permit.so ನಂತಹ ಸಾಲು ಖಾತೆ ಅರ್ಹತೆಯನ್ನು ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅಂಶವನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ಅದು ಆ PAM ಖಾತೆ ನಿರ್ವಹಣೆ ಹಂತಕ್ಕೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಅದು ಹಂತದ ಬಗ್ಗೆ ಹೇಳಿಕೆ, ನಿಮ್ಮ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಅಲ್ಲ.

ಸಡಿಲ ನೋಂದಣಿ ಆಯ್ಕೆಗಳಿಗೂ ಇದೇ ಅನ್ವಯಿಸುತ್ತದೆ. ನೋಂದಾಯಿತ ರಹಸ್ಯವಿಲ್ಲದ ಬಳಕೆದಾರರನ್ನು ಸ್ವೀಕರಿಸುವುದು ಉದ್ದೇಶಪೂರ್ವಕ ರೋಲ್‌ಔಟ್ ನಿರ್ಧಾರವಾಗಿರಬಹುದು, ಆದರೆ ಅದು MFA ಕಡ್ಡಾಯ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಅಂತ್ಯ ದಿನಾಂಕದೊಂದಿಗೆ ತಾತ್ಕಾಲಿಕ ವಿನಾಯಿತಿಯಾಗಿ ಬರೆಯಬೇಕು.

ಕ್ಲೈಂಟ್‌ನ ಸಂವಹನವನ್ನು ಸರ್ವರ್‌ನ ವಿನ್ಯಾಸಕ್ಕೆ ಹೊಂದಿಸಿ

auth-user-pass

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

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

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

ಮತ್ತೆ ಸಂಪರ್ಕ, ಟೋಕನ್‌ಗಳು ಮತ್ತು ವಿಷಯವನ್ನು ನಿರ್ಣಯಿಸುವ ಪರೀಕ್ಷೆ

ಮೊದಲ ಯಶಸ್ವಿ ಲಾಗಿನ್ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂದು ಯೋಜಿಸಿ. ಹಿಂದೆ ಸ್ವೀಕರಿಸಿದ ಕೋಡ್ ಮುಂದಿನ ದೃಢೀಕರಣದಲ್ಲಿ ಅವಧಿ ಮುಗಿದಿರಬಹುದು ಅಥವಾ ಪುನರಾವರ್ತನೆ ಎಂದು ತಿರಸ್ಕರಿಸಬಹುದು. auth-nocache ರುಜುವಾತುಗಳ ಧಾರಣೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ ಮತ್ತು MFA ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಮತ್ತು reneg-sec 0 ಫೋರಂ ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಎಷ್ಟೇ ಬಾರಿ ಕಾಣಿಸಿಕೊಂಡರೂ TOTP ಬೆಂಬಲದ ವ್ಯಾಖ್ಯಾನವಲ್ಲ.

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

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