VPN ಲಾಗಿನ್ RADIUS ಮತ್ತು ನಿಮ್ಮ ಗುರುತಿನ ಪೂರೈಕೆದಾರರನ್ನು ತಲುಪುವುದು ಹೇಗೆ
ಕ್ಲೈಂಟ್ನಿಂದ ಗೇಟ್ವೇಯ RADIUS ವಿನಂತಿ, ಅದರ ಹಿಂದಿನ ಗುರುತಿನ ಪೂರೈಕೆದಾರ ಮತ್ತು ಸ್ವೀಕಾರದ ನಂತರ ಅನ್ವಯವಾಗುವ ನೀತಿಯವರೆಗೆ VPN ಸೈನ್-ಇನ್ ಅನ್ನು ಅನುಸರಿಸಿ.
ಕಳೆದ ವಾರ ಬಳಕೆದಾರರೊಬ್ಬರು VPN ಗೆ ಸೈನ್ ಇನ್ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು ಮತ್ತು ಆದರೂ ಏನೂ ಪರಿಹರಿಸದ ನೆಟ್ವರ್ಕ್ಗೆ ಇಳಿದರು. ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದಿತು, ಗೇಟ್ವೇ ಲಾಗ್ Access-Accept ಎಂದಿತು, ಮತ್ತು ಗುರುತಿನ ತಂಡ ಖಾತೆ ಸರಿಯಾಗಿದೆ ಎಂದಿತು. ಲಾಗಿನ್ ಕೆಲಸ ಮಾಡಿತ್ತು; ಅದರ ಹಿಂದಿನ ಅಧಿಕಾರ ನೀಡಿಕೆ ಮಾಡಲಿಲ್ಲ. VPN ಸೈನ್-ಇನ್ ವಿಫಲವಾದಾಗ, ವಿನಂತಿ ನಿಜವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ಮಾರ್ಗವನ್ನು ನಾನು ನಡೆಯುತ್ತೇನೆ — ಕ್ಲೈಂಟ್, ಗೇಟ್ವೇ, RADIUS ಸರ್ವರ್, ಗುರುತಿನ ಪೂರೈಕೆದಾರ — ಮತ್ತು ಉತ್ತರ ಮುಂದಿನದರೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗದ ಮೊದಲ ಹಂತದಲ್ಲಿ ನಿಲ್ಲುತ್ತೇನೆ.
ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ RADIUS ಮಾತನಾಡುವುದಿಲ್ಲ
ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿನ ಅಪ್ಲಿಕೇಶನ್ ಏನೇ ತೋರಿಸಿದರೂ, ಅದರ ಮೊದಲ ಹಂತ VPN ಪ್ರೋಟೋಕಾಲ್: IKEv2, OpenVPN, WireGuard ಅಥವಾ TLS ಆಧಾರಿತ ಕ್ಲೈಂಟ್. RADIUS ಆ ವಿನಿಮಯದಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇಗೆ ಪ್ರಮಾಣಪತ್ರ, ಬಳಕೆದಾರಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್, ಅಥವಾ ಟನೆಲ್ ಸೆಟಪ್ನೊಳಗೆ ಸಾಗಿಸಲಾದ EAP ವಿಧಾನದಿಂದ ದೃಢೀಕರಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಲಾಗ್ಗಳನ್ನು ಓದುವಾಗ ಇದು ಮುಖ್ಯ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರು ಕಾಣುವ ಸಾಮಾನ್ಯ ದೃಢೀಕರಣ ದೋಷವನ್ನು ಗೇಟ್ವೇ ಬೇರೆ ಯಾವುದೋ ಜೊತೆ ಮಾತನಾಡಿದ ನಂತರ ಉತ್ಪಾದಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ ಗೇಟ್ವೇ ತಲುಪದಿದ್ದರೆ, ಡೀಬಗ್ ಮಾಡಲು RADIUS ವಿನಂತಿ ಇರುವುದಿಲ್ಲ, ಮತ್ತು RADIUS ಸರ್ವರ್ನಲ್ಲಿ ಕಳೆದ ಒಂದು ಗಂಟೆ ವ್ಯರ್ಥವಾಗುತ್ತದೆ. ಬ್ಯಾಕೆಂಡ್ ಮುಟ್ಟುವ ಮೊದಲು ಟನೆಲ್ ಬಂದಿತೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಗೇಟ್ವೇಯೇ RADIUS ಕ್ಲೈಂಟ್
ಟನೆಲ್ ಸೆಟಪ್ ರುಜುವಾತುಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾದ ಹಂತವನ್ನು ತಲುಪಿದಾಗ, ಗೇಟ್ವೇ ನೆಟ್ವರ್ಕ್ ಪ್ರವೇಶ ಸರ್ವರ್ ಆಗುತ್ತದೆ. ಅದು Access-Request ನಿರ್ಮಿಸುತ್ತದೆ: User-Name, ಪಾಸ್ವರ್ಡ್ ಅಥವಾ EAP ಪೇಲೋಡ್, NAS-IP-Address ಅಥವಾ NAS-Identifier, ಮತ್ತು ವಿಧಾನ ಬೇಡಿದಾಗ Message-Authenticator. ವಿನಂತಿ ಡೀಫಾಲ್ಟ್ ಆಗಿ UDP 1812 ಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಲೆಕ್ಕಪತ್ರ 1813 ಗೆ. ಹಳೆಯ ನಿಯೋಜನೆಗಳು ಇನ್ನೂ 1645 ಮತ್ತು 1646 ಬಳಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಒಂದು ಜೋಡಿಗೆ ಬರೆದ ಫೈರ್ವಾಲ್ ನಿಯಮ ಅನೇಕ ಮೌನ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಎರಡೂ ಕಡೆ ಒಂದು ರಹಸ್ಯವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅದು ಬಳಕೆದಾರ ರುಜುವಾತಲ್ಲ. ಅದು ವಿನಿಮಯಕ್ಕೆ ಸಹಿ ಹಾಕುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಉತ್ತರವೂ ಅದರ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಎರಡೂ ಕಡೆ ರಹಸ್ಯವನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಮತ್ತು ಸರ್ವರ್ ಕೆಟ್ಟ ರಹಸ್ಯ ಎಂದು ಉತ್ತರಿಸುವುದಿಲ್ಲ — ಅದು ವಿನಂತಿಯನ್ನು ಬಿಡುತ್ತದೆ ಅಥವಾ ಉತ್ತರ ಪರಿಶೀಲನೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಹೀಗಾಗಿ ಗೇಟ್ವೇ ಸಮಯ ಮುಗಿದಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ತಪ್ಪು ರಹಸ್ಯ ಮತ್ತು ಸತ್ತ ಸರ್ವರ್ ಗೇಟ್ವೇಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಡೈರೆಕ್ಟರಿಯನ್ನು ದೂಷಿಸುವ ಮೊದಲು ನಾನು ಕ್ಲೈಂಟ್ ಉಪಕರಣದಿಂದ ಹಂತವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತೇನೆ.
ಪ್ರೋಟೋಕಾಲ್ ಚಿಕ್ಕದು ಮತ್ತು ಹಳೆಯದು — RFC 2865 ದೃಢೀಕರಣ ವಿನಿಮಯವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ — ಆದರೆ ಅದು ಸಾಗಿಸುವ ಗುಣಲಕ್ಷಣಗಳೇ ಹೆಚ್ಚಿನ VPN ನೀತಿಯ ತಳಹದಿ.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS ಸರ್ವರ್ ಕೇವಲ ಗುರುತಿನ ಪೂರೈಕೆದಾರರ ಮುಂಭಾಗವಾಗಿರಬಹುದು
ಜನರು RADIUS ಮತ್ತು ಗುರುತಿನ ಪೂರೈಕೆದಾರರ ಬಗ್ಗೆ ಅವು ಒಂದೇ ಪೆಟ್ಟಿಗೆ ಎಂಬಂತೆ ಮಾತನಾಡುತ್ತಾರೆ. ಹೆಚ್ಚಾಗಿ ಹಾಗಲ್ಲ. RADIUS ಸರ್ವರ್ Access-Request ಸ್ವೀಕರಿಸಿ, ಉತ್ತರಿಸುವ ಮೊದಲು ಬೇರೆ ಯಾವುದನ್ನೋ ಕೇಳುತ್ತದೆ — LDAP ಅಥವಾ Kerberos ಮೂಲಕ Active Directory, ಸ್ಥಳೀಯ ಬಳಕೆದಾರ ಫೈಲ್, ಅಥವಾ ಬಾಹ್ಯ ಸೇವೆ. LDAP ಅಥವಾ krb5 ಮಾಡ್ಯೂಲ್ನೊಂದಿಗೆ FreeRADIUS, Windows NPS ಮತ್ತು Cisco ISE ಎಲ್ಲವೂ ಈ ಸ್ಥಾನದಲ್ಲಿವೆ.
ಈ ವ್ಯತ್ಯಾಸವೇ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ನಿರಾಕರಿಸಲಾದ ಪಾಸ್ವರ್ಡ್ RADIUS ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಗುರುತಿನ ಪೂರೈಕೆದಾರರ ಉತ್ತರ. ಸಮಯ ಮುಗಿಯುವುದು ಸಾಮಾನ್ಯವಾಗಿ RADIUS ನಿಂದ ಡೈರೆಕ್ಟರಿಯವರೆಗಿನ ಭಾಗ: ಅವಧಿ ಮುಗಿದ ಬೈಂಡ್ ಖಾತೆ, ತಲುಪಲಾಗದ ಡೈರೆಕ್ಟರಿ, ಅಥವಾ ತಪ್ಪು ಬ್ಯಾಕೆಂಡ್ಗೆ ಕಳುಹಿಸಿದ ವಿನಂತಿ. ಬಳಕೆದಾರಹೆಸರಿನಲ್ಲಿ ಡೊಮೇನ್ ಪ್ರತ್ಯಯವಿದ್ದರೆ, ಸರ್ವರ್ ಅದರ ಮೇಲೆ ಮಾರ್ಗ ನಿರ್ದೇಶಿಸಬಹುದು, ಮತ್ತು CORP\alice ಹಾಗೂ [email protected] ಎಂದು ಕಳುಹಿಸಿದ ಅದೇ ಖಾತೆ ಬೇರೆ ಬೇರೆ ಕಡೆ ಬೀಳಬಹುದು. Windows NPS ನಲ್ಲಿ, Security ಲಾಗ್ ಅನುಮತಿಗೆ 6272 ಮತ್ತು ನಿರಾಕರಣೆಗೆ 6273 ದಾಖಲಿಸುತ್ತದೆ, ಇದು ನಿರ್ಧಾರ NPS ನಿಂದಲೇ ಬಂದಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ.
ವೈಫಲ್ಯವನ್ನು ಅದನ್ನು ಉಂಟುಮಾಡಿದ ಹಂತದಲ್ಲೇ ಓದಿ
ಒಂದೇ ಸಂಪರ್ಕಿಸಲಾಗದ ಸಂದೇಶ ನಾಲ್ಕು ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು, ಲಕ್ಷಣವನ್ನು ಅದನ್ನು ಉಂಟುಮಾಡಿದ ಹಂತಕ್ಕೆ ಹೊಂದಿಸಿ.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
ಕೊನೆಯ ಸಾಲೇ ಜನರನ್ನು ತಪ್ಪು ತಂಡಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. Access-Accept ಎಂದರೆ ರುಜುವಾತುಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ; ಗೇಟ್ವೇ ಬಳಕೆದಾರರನ್ನು ಸರಿಯಾದ ಪೂಲ್ನಲ್ಲಿ ಇರಿಸಿದೆ ಅಥವಾ ಮಾರ್ಗಗಳನ್ನು ತಳ್ಳಿದೆ ಎಂದಲ್ಲ. ಗುಂಪು ಗುಣಲಕ್ಷಣಗಳು ಗೇಟ್ವೇ ನೀತಿ ಅವನ್ನು ಓದಿದರೆ ಮಾತ್ರ ಮುಖ್ಯ. ಸರಿಯಾದ ಲಾಗಿನ್ ಅತಿಥಿ ಪೂಲ್ಗೆ ಬಿದ್ದುದನ್ನು ನೋಡಿದ್ದೇನೆ, ಏಕೆಂದರೆ RADIUS ಬದಿಯಲ್ಲಿ ಗುಂಪು ಮ್ಯಾಪಿಂಗ್ ಗೇಟ್ವೇ ಪರಿಶೀಲಿಸುವ ಗುಣಲಕ್ಷಣಕ್ಕಿಂತ ಬೇರೆಯದಕ್ಕೆ ಕಾನ್ಫಿಗರ್ ಆಗಿತ್ತು.
ಒಂದು ಲಾಗಿನ್ ಅನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಅನುಸರಿಸಿ
ಒಂದು ಪರೀಕ್ಷಾ ಖಾತೆ ಮತ್ತು ಒಂದು ಗೇಟ್ವೇ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಅದೇ ಪ್ರಯತ್ನವನ್ನು ನಾಲ್ಕೂ ಹಂತಗಳಲ್ಲಿ ಗಮನಿಸಿ. RADIUS ಬದಿಯಲ್ಲಿ ಡೀಬಗ್ ರನ್ ಪ್ರಾರಂಭಿಸಿ — freeradius -X ವಿನಂತಿ ಮತ್ತು ಅದು ಸ್ಪರ್ಶಿಸುವ ಪ್ರತಿ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ — ಗೇಟ್ವೇಯ ದೃಢೀಕರಣ ಲಾಗ್ ಅನ್ನು ಅನುಸರಿಸಿ, ಮತ್ತು UDP ವಿನಿಮಯಕ್ಕಾಗಿ tcpdump ಚಲಾಯಿಸಿ. ಒಮ್ಮೆ ಸಂಪರ್ಕಿಸಿ ನಾಲ್ಕು ಜಾಡುಗಳನ್ನು ಕ್ರಮವಾಗಿ ಓದಿ.
ನೀವು ನೋಡಲು ಬಯಸುವುದು ಒಮ್ಮತ: ಗೇಟ್ವೇ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಬಳಕೆದಾರರ ಬಗ್ಗೆ ಕೇಳಿತು, RADIUS ಸರ್ವರ್ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಬ್ಯಾಕೆಂಡ್ ಆಯ್ಕೆಮಾಡಿತು, ಆ ಬ್ಯಾಕೆಂಡ್ ನಿರ್ಧಾರ ಹಿಂತಿರುಗಿಸಿತು, ಮತ್ತು ಉತ್ತರದ ಗುಣಲಕ್ಷಣಗಳು ಗೇಟ್ವೇ ಅನ್ವಯಿಸುವ ನೀತಿಗೆ ಹೊಂದುತ್ತವೆ. ಜಾಡುಗಳು ಮೊದಲು ಒಮ್ಮತ ತಪ್ಪುವ ಸ್ಥಳವೇ ನಿಮ್ಮ ದೋಷರೇಖೆ. ಉತ್ತರದಲ್ಲಿ ಗುಂಪು ಗುಣಲಕ್ಷಣವಿಲ್ಲದಿದ್ದರೆ, ಸಮಸ್ಯೆ VPN ಪ್ರೊಫೈಲ್ನಲ್ಲಲ್ಲ, RADIUS ಬದಿಯಲ್ಲಿದೆ; ಗುಣಲಕ್ಷಣ ಇದ್ದು ಗೇಟ್ವೇ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ಸಮಸ್ಯೆ ಗೇಟ್ವೇ ನೀತಿಯಲ್ಲಿದೆ.
ಅಲ್ಲಿರುವಾಗ ಒಂದು ಭದ್ರತಾ ಟಿಪ್ಪಣಿ. ಹಂಚಿದ ರಹಸ್ಯ ವಿನಿಮಯವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದಿಲ್ಲ. ಗೇಟ್ವೇ ಮತ್ತು RADIUS ಸರ್ವರ್ ಬೇರೆ ಬೇರೆ ವಿಭಾಗಗಳಲ್ಲಿದ್ದರೆ, ಆ ಹಂತವನ್ನು TLS ಮೇಲಿನ RADIUS ಅಥವಾ ಖಾಸಗಿ ಮಾರ್ಗದಲ್ಲಿ ಇರಿಸಿ. ಎನ್ಕ್ರಿಪ್ಟ್ ಆದ ಬಳಕೆದಾರ ಟನೆಲ್ ಬ್ಯಾಕೆಂಡ್ ಕೊಂಡಿಯ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.
ಟಿಕೆಟ್ ಮುಚ್ಚುವ ಮೊದಲು ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಖಚಿತಪಡಿಸಿ. ಗೇಟ್ವೇ ನಿಜವಾಗಿ ಕಾನ್ಫಿಗರ್ ಆಗಿರುವ ಪೋರ್ಟ್ನಲ್ಲಿ RADIUS ಸರ್ವರ್ ತಲುಪಬಲ್ಲದು. ಹಂಚಿದ ರಹಸ್ಯ ಎರಡೂ ಕಡೆ ಹೊಂದುತ್ತದೆ. RADIUS ಸರ್ವರ್ ಗೇಟ್ವೇ ಕಳುಹಿಸುವ ನಿಖರ ಬಳಕೆದಾರಹೆಸರಿನ ರೂಪವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಸ್ವೀಕಾರ ಗೇಟ್ವೇ ನೀತಿಗೆ ಬೇಕಾದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ. ನಾಲ್ಕೂ ನಿಜವಾದಾಗ, ಇನ್ನೂ ವಿಫಲವಾಗುವ ಲಾಗಿನ್ ದೃಢೀಕರಣದ್ದಲ್ಲ, ಗೇಟ್ವೇ ನೀತಿಯ ಸಮಸ್ಯೆ.