RADIUS가 VPN 사용자 이름 대신 IP 주소를 보는 이유

strongSwan은 EAP 교환이 일어나기 전에 IKE ID를 RADIUS User-Name에 넣을 수 있습니다. 계정 ID를 누가 요청할지 정한 다음 한 번의 시도를 연관 지으십시오.

Windows IKEv2 클라이언트가 연결되고 RADIUS 요청에는 계정 이름이 있어야 할 자리에 주소가 들어 있습니다. 아직 아무것도 실패하지 않았고, 혼란스러운 점은 게이트웨이가 클라이언트가 IKE 계층에서 제시한 ID를 보고하고 있다는 것입니다. 백엔드가 원하는 사용자 이름은 아직 일어나지 않은 별도의 EAP 교환에서 올 수 있습니다. 계정을 바꾸기 전에 누가 그것을 요청할지 정하십시오.

하나의 연결에서 두 개의 ID가 이동한다

하나의 연결에서 두 개의 이름이 나타날 수 있습니다. IKE ID는 터널 설정 중에 피어를 식별하고 eap-radius 플러그인이 처음에 그것을 RADIUS User-Name으로 복사합니다. EAP ID는 사용자 인증에 쓰이는 다른 값이며 아무도 요청하지 않으면 전혀 전송되지 않을 수 있습니다.

그래서 계정이 있고 비밀번호가 맞는데도 RADIUS 로그에 주소가 표시될 수 있습니다. 백엔드에 잘못된 계층을 묻고 있는 것입니다. RADIUS 속성은 선택된 이름을 위한 전송 수단일 뿐입니다.

게이트웨이에 EAP ID를 요청하게 하라

지원되는 한 가지 구성은 게이트웨이가 인증을 RADIUS에 넘기기 전에 EAP ID를 요청하게 합니다. 연결의 원격 인증 섹션에서 방식을 eap-radius로 설정하고 EAP ID를 명시적으로 요청하십시오. 아래 조각은 자체 파일이 아니라 기존 연결 블록 안에 속합니다. 다른 배포에서 구문을 복사하기 전에 연결과 구성 백엔드를 확인하십시오.

remote {
    auth = eap-radius
    eap_id = %any
}

그렇게 하면 백엔드는 IKE 주소 대신 클라이언트가 EAP 교환에서 제공하는 ID를 받습니다. 연결에 대해 다른 것은 바뀌지 않습니다.

또는 RADIUS가 EAP 교환을 시작하게 하라

다른 구성은 첫 움직임을 RADIUS 쪽에 둡니다. 플러그인은 초기 ID 응답을 기다리는 대신 EAP-Start 표시를 보낼 수 있으며 그러면 서버가 교환을 주도할 수 있습니다. 이는 플러그인 수준 구성이므로 플러그인을 사용하는 모든 연결에 영향을 줍니다.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

둘 다 활성화하고 바라기보다는 RADIUS 운영자와 한 가지 구성을 고르십시오. 둘은 서로 다른 작업 흐름을 설명하며 시작하기를 기대하는 서버가 대화를 시작하는 게이트웨이를 반드시 처리하지는 못합니다. 플러그인 문서는 각 단계가 어떤 ID를 나르는지 포함해 둘 다 설명합니다.

한 번의 시도를 두 로그에서 추적하라

한 번의 시도를 두 로그에서 연관 지으십시오. IKE ID를 보고 다음으로 EAP-Identity 교환이 일어나는지 그리고 인증 단계가 어떤 이름을 받는지 보십시오. EAP 교환 전에 주소를 거부하는 백엔드는 의도한 ID가 보이기도 전에 처리를 멈출 수 있습니다.

journalctl -u strongswan -f

ID 시스템이 기대하는 정확한 사용자 이름 형식을 도메인 접두사까지 포함해 유지하십시오. 주소 형태의 값에서 계정을 만들어 내지 말고 정책 규칙을 만족시키려고 인증을 끄지 마십시오. EAP ID는 주장된 이름이며 방식은 여전히 그것을 증명해야 합니다. 결과 이름을 테스트 기록에 적어 다음 시도가 알려진 상태에서 시작하게 하십시오.

수정된 흐름이 올바른 계정에 도달했는데도 거부된다면 다음 증거는 ID가 아니라 EAP 방식과 백엔드 정책입니다. 비밀번호 재설정을 반복해도 이전 프로토콜 계층에서 선택된 값을 고칠 수는 없습니다.

관련 글