VPN 로그인이 RADIUS와 ID 공급자에 도달하는 방법
클라이언트에서 게이트웨이의 RADIUS 요청, 그 뒤의 ID 공급자, 그리고 수락 후 적용되는 정책까지 VPN 로그인을 따라갑니다.
지난주 한 사용자가 VPN에 로그인했는데도 아무것도 확인되지 않는 네트워크에 도착했습니다. 클라이언트는 연결됨이라고 했고, 게이트웨이 로그는 Access-Accept라고 했으며, ID 팀은 계정이 정상이라고 했습니다. 로그인은 성공했지만 그 뒤의 권한 부여는 실패했습니다. VPN 로그인이 실패하면 저는 요청이 실제로 지나는 경로 — 클라이언트, 게이트웨이, RADIUS 서버, ID 공급자 — 를 따라가며 응답이 다음 단계와 어긋나는 첫 지점에서 멈춥니다.
클라이언트는 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 서버는 ID 공급자의 전면일 뿐일 수 있다
사람들은 RADIUS와 ID 공급자를 같은 상자처럼 말합니다. 흔히 그렇지 않습니다. RADIUS 서버는 Access-Request를 받고 나서 응답하기 전에 다른 무언가 — LDAP나 Kerberos를 통한 Active Directory, 로컬 사용자 파일, 또는 외부 서비스 — 에 묻습니다. LDAP 또는 krb5 모듈을 쓰는 FreeRADIUS, Windows NPS, Cisco ISE가 모두 이 위치에 있습니다.
이 구분이 어디를 볼지 결정합니다. 거부된 비밀번호는 RADIUS가 중계하는 ID 공급자의 답입니다. 시간 초과는 보통 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 서버가 게이트웨이가 보내는 정확한 사용자 이름 형태를 해석하는지. 수락이 게이트웨이 정책에 필요한 속성을 나르는지. 네 가지가 모두 성립하면 그래도 실패하는 로그인은 인증이 아니라 게이트웨이 정책 문제입니다.