VPN ಗುಂಪಿಗೆ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸುವುದು ಸ್ವತಃ ಪ್ರವೇಶ ನೀಡುವುದಿಲ್ಲ
ಗುಂಪು ಸದಸ್ಯತ್ವ ಒಂದು ಷರತ್ತು, ಅನುಮತಿ ಅಲ್ಲ. ಗೇಟ್ವೇ ನಿಜವಾಗಿ ಏನನ್ನು ಹೊಂದಿಸಿತು ಎಂದು ನೋಡಿ, ಸ್ವೀಕಾರ ಅಥವಾ ನಿರಾಕರಣೆಯ ದಾಖಲೆಯನ್ನು ಓದಿ, ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಖಾತೆ ಸರಿಯಾದ ಗುಂಪಿನಲ್ಲಿದೆ, ಲಾಗಿನ್ ಯಶಸ್ವಿಯಾಯಿತು, ಆದರೂ ಸಂಪರ್ಕ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ ಅಥವಾ ಯಾವುದೇ ಉಪಯುಕ್ತ ವಸ್ತುವನ್ನು ತಲುಪುವುದಿಲ್ಲ. ಏನಾದರೂ ಸಡಿಲವಾಗುವವರೆಗೆ ಗುಂಪು ಸೇರಿಸುವುದು ಸಾಮಾನ್ಯ ಪ್ರತಿಕ್ರಿಯೆ, ಮತ್ತು ಹೀಗೆ ಸಂಸ್ಥೆಗಳು ಟಿಕೆಟ್ ಕೇಳಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ನೀಡುತ್ತವೆ. ಗುಂಪು ಸದಸ್ಯತ್ವ ಅನುಮೋದನೆ ನಿರ್ಣಯದ ಒಂದು ಇನ್ಪುಟ್, ಎಂದಿಗೂ ನಿರ್ಣಯವೇ ಅಲ್ಲ: ಗೇಟ್ವೇ ಸೆಷನ್ ಬಗ್ಗೆ ಕೆಲವು ಸತ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ, ಕ್ರಮಬದ್ಧ ನೀತಿಗೆ ಹೊಂದಿಸಿ, ನಂತರವೇ ಏನನ್ನು ಮುಟ್ಟಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಬೇರೆ ಷರತ್ತು ವಿಫಲವಾದರೆ, ಗುಂಪು ಬದಲಿಸುವುದು ನಿಮ್ಮ ಒಡ್ಡುವಿಕೆಯನ್ನು ಮಾತ್ರ ಬದಲಿಸುತ್ತದೆ.
ಗುಂಪು ಸದಸ್ಯತ್ವ ಷರತ್ತು, ಅನುಮತಿ ಅಲ್ಲ
RADIUS ನಲ್ಲಿ ಗುಂಪು ಅನುಮೋದನೆ ಗುಣಲಕ್ಷಣವಾಗಿ ಬರುತ್ತದೆ, ಗುಣಲಕ್ಷಣಗಳು ಸೆಷನ್ ಅನ್ನು ವಿವರಿಸುತ್ತವೆ, ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ. ಸರ್ವರ್ Access-Accept ಅಥವಾ Access-Reject ನಿಂದ ಉತ್ತರಿಸುತ್ತದೆ; ಸ್ವೀಕರಿಸಿದಾಗ Filter-Id, Class ಅಥವಾ RFC 2868 ನ ಟನಲ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸೇರಿಸಬಹುದು, ಮತ್ತು ಆಚೆಯ ನೆಟ್ವರ್ಕ್ ಸಾಧನವು ತಯಾರಕರ ನಿರ್ಣಯದಂತೆ ಅವನ್ನು ಅರ್ಥೈಸುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಗುಂಪನ್ನು ಪೂರ್ಣ ಪ್ರವೇಶಕ್ಕೆ ಬದಲಿಸುವ ಯಾವುದೂ ಇಲ್ಲ; ಆ ನಕ್ಷೆಯನ್ನು ನೀತಿ ಹೊಂದಿಸಿದವರು ಬರೆಯುತ್ತಾರೆ.
ಆದ್ದರಿಂದ ಒಂದೇ ಗುಂಪಿನ ಹೆಸರು ಎರಡು ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ. Microsoft NPS ಷರತ್ತು, ನಿರ್ಬಂಧ ಮತ್ತು ಸೆಟ್ಟಿಂಗ್ಗಳಿಂದ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳನ್ನು ರಚಿಸಿ ನಿಗದಿತ ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. OpenVPN Access Server ತನ್ನದೇ ಗುಂಪು ಮತ್ತು ಪ್ರವೇಶ ನಿಯಮ ಮಾದರಿಯನ್ನು ಹೊಂದಿದೆ, ಸಮುದಾಯ OpenVPN ಸರ್ವರ್ ಸಾಮಾನ್ಯವಾಗಿ ಇಡೀ ಪ್ರಶ್ನೆಯನ್ನು client-connect ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ client-config-dir ಫೈಲ್ಗೆ ಒಪ್ಪಿಸುತ್ತದೆ.
ನಿರ್ಣಯಿಸುವುದು ಹೊಂದಿದ ನಿಯಮ, ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಗುಂಪಲ್ಲ
ಹೆಚ್ಚಿನ ಎಂಜಿನ್ಗಳು ಮೊದಲ ಹೊಂದುವ ನೀತಿಯಲ್ಲಿ ಅಥವಾ ಅತ್ಯಂತ ನಿರ್ದಿಷ್ಟದಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆ. ನೀತಿ 3 ನಿರಾಕರಿಸಿ ನೀತಿ 7 ಅನುಮತಿಸಿದರೆ, ಅದನ್ನು ದಾಟಿಸಬಹುದಾದ ನಿಯಮವನ್ನು ತಲುಪದೆಯೇ ಸೆಷನ್ ವಿಫಲವಾಗಬಹುದು. ಕ್ರಮ NPS ಮತ್ತು ಹೆಚ್ಚಿನ ನೆಟ್ವರ್ಕ್ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ನಿಜವಾದ ಸೆಟ್ಟಿಂಗ್.
ಗುಂಪಿನೊಂದಿಗೆ ಹೋಗುವ ಷರತ್ತುಗಳು ಇನ್ನೊಂದು ಅರ್ಧ. ಸಾಧನದ ಸ್ಥಿತಿ, ದೃಢೀಕರಣ ವಿಧಾನ, ಪೂರ್ಣಗೊಂಡ MFA, ಮೂಲ ನೆಟ್ವರ್ಕ್, ಪ್ರಮಾಣಪತ್ರದ ವಿಷಯ ಅಥವಾ ಸಮಯ ಕಿಟಕಿ ಒಂದೇ ನೀತಿಯಲ್ಲಿರಬಹುದು. ಒಂದು ಪೂರೈಸದಿದ್ದರೆ ನೀತಿ ಹೊಂದುವುದಿಲ್ಲ, ಎಂಜಿನ್ ಕೆಳಗೆ ಬೀಳುತ್ತದೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ನಿರಾಕರಣೆ ಅನ್ವಯವಾಗುತ್ತದೆ. ಬಳಕೆದಾರರ ಕಡೆಯಿಂದ ಗುಂಪು ನಿರ್ಲಕ್ಷಿಸಿದಂತೆ ಕಾಣುತ್ತದೆ; ಎಂಜಿನ್ ಕಡೆಯಿಂದ ಗುಂಪನ್ನು ಕೇಳಿಯೇ ಇಲ್ಲ.
ಡೈರೆಕ್ಟರಿ ವಿವರಗಳು ಅದೇ ಭ್ರಮೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. Windows ಗುಂಪು ಸದಸ್ಯತ್ವದ ಮೇಲೆ ಹೊಂದಿಸುವ ನೀತಿ ಟೋಕನ್ನಲ್ಲಿರುವ SID ಗಳನ್ನು ಓದುತ್ತದೆ, ಅಲ್ಲಿ ಭದ್ರತಾ ಗುಂಪುಗಳಷ್ಟೇ ಪಟ್ಟಿಯಾಗಿರುತ್ತವೆ, ವಿತರಣಾ ಗುಂಪು ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ. ಪ್ರಾಥಮಿಕ ಗುಂಪು ತನ್ನದೇ ಕ್ಷೇತ್ರದಲ್ಲಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ಜೋಡಿಸಿದ ನೀತಿ ಮೌನವಾಗಿ ವಿಫಲವಾಗಬಹುದು.
ಗುಂಪನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಸ್ವೀಕಾರ ಅಥವಾ ನಿರಾಕರಣೆಯ ದಾಖಲೆಯನ್ನು ಓದಿ
ಮೊದಲು ಒಂದು ಪ್ರಶ್ನೆ: ವಿನಂತಿ ಅನುಮೋದನೆ ಹಂತವನ್ನು ತಲುಪಿತೇ? NPS ನಲ್ಲಿ ಉತ್ತರ ಈವೆಂಟ್ ಲಾಗ್ನಲ್ಲಿದೆ, ಅಲ್ಲಿ 6272 ನೀಡಿದ ಪ್ರವೇಶ, 6273 ನಿರಾಕರಣೆ, 6274 ನೀತಿ ಮೌಲ್ಯಮಾಪನಕ್ಕೆ ಮೊದಲು ಸರ್ವರ್ ಎಸೆದ ವಿನಂತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಆ ಮೂರು ಸಂಖ್ಯೆಗಳು ಸಮಸ್ಯೆಯನ್ನು ಮೂರು ಬೇರೆ ತನಿಖೆಗಳಾಗಿ ಒಡೆಯುತ್ತವೆ, ಒಂದೇ ಗುಂಪುಗಳ ಬಗ್ಗೆ.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
ಲಾಗ್ ಎಟುಕದಿದ್ದರೆ ಸರ್ವರ್ನ್ನು ನೇರವಾಗಿ ಕೇಳಿ ಅದು ಹಿಂತಿರುಗಿಸುವುದನ್ನು ಓದಿ. Filter-Id ಮತ್ತು ಟನಲ್ ಗುಣಲಕ್ಷಣಗಳಿಲ್ಲದ ಉತ್ತರ ಸರ್ವರ್ ಸೆಷನ್ ಸಾಮಾನ್ಯ ಎಂದು ಪರಿಗಣಿಸಿ ಗೇಟ್ವೇ ತನ್ನದೇ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದರ್ಥ. ಜಾರಿ ಬಿಂದು ಜಾರಿಗೊಳಿಸದ ಗುಣಲಕ್ಷಣಗಳಿರುವ ಉತ್ತರ ಬೇರೆ ದೋಷ: ಅನುಮೋದನೆ ದಾಟಿತು ಮತ್ತು ಸಾಧನ ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಲಕ್ಷಿಸಿತು.
radtest alice 'password' 10.0.0.5 0 testing123ಹಿಂತಿರುಗಿದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಗೇಟ್ವೇ ದಾಖಲಿಸುವವುಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ, ಗುಂಪಿನ ಹೆಸರು ಸೂಚಿಸುವುದರೊಂದಿಗೆ ಅಲ್ಲ. ಆ ಹೋಲಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ನೀತಿ ಸಮಸ್ಯೆಯನ್ನು ಜಾರಿ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.
ಗುಂಪು ಬದಲಾವಣೆ ಹಿಂದಿನದಕ್ಕೆ ಅನ್ವಯವಾಗುವುದಿಲ್ಲ
ಅನುಮೋದನೆ ಗುಣಲಕ್ಷಣಗಳು ಸೆಷನ್ ದೃಢೀಕರಣದ ಸಮಯದಲ್ಲಿ ಒಮ್ಮೆ ಮಾತ್ರ ಹಿಂತಿರುಗುತ್ತವೆ. ಗೇಟ್ವೇ ಅವನ್ನು ಸೆಷನ್ ಮೇಲೆ ಇರಿಸಿ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೂ ಡೈರೆಕ್ಟರಿಯನ್ನು ಮತ್ತೆ ಓದುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾರನ್ನಾದರೂ ಗುಂಪಿನಿಂದ ತೆಗೆದ ನಂತರವೂ ಸ್ಥಾಪಿತ ಸೆಷನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಬದಲಾವಣೆ ಜಾರಿಗೆ ಬರಲು ಹೊಸ ಅನುಮೋದನೆ ನಿರ್ಣಯ ಬೇಕು, ಹೊಸ ಕೀಗಳಷ್ಟೇ ಸಾಲದು. ಸರ್ವರ್ RFC 5176 ಕ್ರಿಯಾತ್ಮಕ ಅನುಮೋದನೆಯನ್ನು ಬೆಂಬಲಿಸಿದರೆ UDP 3799 ಗೆ Disconnect-Request ಅಥವಾ CoA-Request ಸೆಷನ್ ಮರುಮೌಲ್ಯಮಾಪನಕ್ಕೆ ಒತ್ತಾಯಿಸುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತೆ ಸೇರಲು ಬಿಡಿ. ಮರುಸಂಧಾನ ಟನಲ್ ಕೀಗಳನ್ನು ಹೊಸದಾಗಿಸಿ ಅನುಮೋದನೆ ಫಲಿತಾಂಶವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಿಡುತ್ತದೆ.
ಷರತ್ತನ್ನು ಸರಿಪಡಿಸಿ, ಗುಂಪನ್ನಲ್ಲ
ಯಾವ ನೀತಿ ಕಾರ್ಯಗತವಾಯಿತು ಎಂದು ತಿಳಿದ ನಂತರ ಸರಿಪಡಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಚಿಕ್ಕದು: ಉದ್ದೇಶಿತ ಅನುಮತಿಯನ್ನು ಮುಚ್ಚುವ ನಿರಾಕರಣೆಯ ಕ್ರಮ ಬದಲಿಸಿ, ಗುರಿಯಿಟ್ಟ ನೀತಿಗೆ ಕಾಣೆಯಾದ ಸಾಧನ ಅಥವಾ MFA ಷರತ್ತು ಸೇರಿಸಿ, ಅಥವಾ ಬಳಕೆದಾರರನ್ನು ಇನ್ನೂ ಹತ್ತು ಹೊತ್ತ ಗುಂಪಿಗೆ ಏರಿಸುವ ಬದಲು ಒಂದು ಸಂಪನ್ಮೂಲಕ್ಕೆ ಸಣ್ಣ ನಿಯಮ ಬರೆಯಿರಿ.
ಸಣ್ಣ ಸುತ್ತು ಬದಲಾವಣೆಯನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಇರಿಸುತ್ತದೆ:
- ಮೂಲ ಖಾತೆಯಿಂದ ನಿರಾಕರಣೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಈವೆಂಟ್ ID ಬರೆಯಿರಿ.
- ಒಂದೇ ವಸ್ತು ಬದಲಿಸಿ, ನೀತಿ ಕ್ರಮ, ಒಂದು ಷರತ್ತು ಅಥವಾ ಒಂದು ಗುಂಪು, ಮತ್ತು ಯಾವುದು ಎಂದು ದಾಖಲಿಸಿ.
- ಹೊಸ ಸೆಷನ್ ತೆರೆಯಿರಿ, ಅನುಮತಿ ಲಾಗ್ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ ನಿಜವಾಗಿ ತೆರೆಯುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
- ಇನ್ನೂ ನಿರಾಕರಿಸಬೇಕಾದ ಬಳಕೆದಾರರನ್ನು ಪರೀಕ್ಷಿಸಿ, ಸರಿಪಡಿಸುವಿಕೆ ಆಕಸ್ಮಿಕವಾಗಿ ನೀತಿಯನ್ನು ವಿಸ್ತರಿಸದಂತೆ.
ಅನುಮತಿ ಸರಿಯಾಗಿದ್ದು ಸಂಪನ್ಮೂಲ ತೆರೆಯದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಮಾರ್ಗನಿರ್ದೇಶನ ಅಥವಾ ಹೆಸರು ವಿಭಜನೆಗೆ ಹೋಗಿದೆ ಅನುಮೋದನೆ ದಾಟಿದ ಕ್ಷಣದಲ್ಲಿ. ಆ ಎರಡು ದೋಷಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ, ಮುಂದಿನ ಟಿಕೆಟ್ ಅರ್ಧ ದಿನದ ಬದಲು ನಿಮಿಷ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.