게이트웨이 인증서는 멀쩡한데 IKEv2 PEAP 로그인이 계속 실패하는 이유

VPN 게이트웨이 인증서는 유효하고 체인도 검증되지만, IKEv2 클라이언트는 인증서 유효 기간에 관한 메시지를 내며 로그인을 거부합니다. 첫 반응은 게이트웨이 인증서를 다시 발급하거나 EAP 방식을 바꾸는 것이지만, 둘 다 대개 틀렸습니다. 로그인 시도에는 두 개의 별개 서버 신원, 즉 IKE가 사용하는 게이트웨이 인증서와 PEAP을 종료하는 쪽이 제시하는 인증서가 실려 있습니다. 하나는 정상이고, 다른 하나가 클라이언트를 멈추게 한 이유입니다.

두 신원, 한 번의 로그인 시도

VPN 프로필의 인증서는 IKE 교환에 속하며, 설정된 IKE 정책 아래에서 게이트웨이가 프로필이 지목한 상대임을 증명합니다. 여기서 실패하는 인증서는 다른 대화, 즉 PEAP이 사용자를 인증하는 상대와 여는 TLS 세션에 속하며, 그 상대는 게이트웨이 자체가 아니라 NPS 같은 RADIUS 서버인 경우가 많습니다. 세 번째 확인인 사용자 자격 증명은 그 세션 안에서 일어납니다. 유효한 암호는 만료된 서버 인증서를 고칠 수 없고, 유효한 게이트웨이 인증서는 PEAP 엔드포인트를 보증할 수 없습니다.

이 계층 구조는 누군가 설정한 유일한 인증서가 게이트웨이의 것이었던 곳에서 인증서 오류가 왜 나타나는지 설명합니다. 같은 인증서를 다시 발급해도 아무것도 바뀌지 않는 이유도 설명합니다.

로그 줄을 단계와 대조해 읽으십시오

이유와 날짜를 밝히는 메시지를 찾으십시오. 주체 오류 옆에 유효 기간 불평이 있다면 서버가 넘겨받은 인증서를 거부한 것이지, 사용자가 로그인을 거부한 것이 아닙니다. 다음으로 단계를 찾으면 strongSwan의 charon 로그는 EAP 교환이 시작되기 전에 IKE_SA .* established 를 보여 주므로, 그 줄 뒤의 인증서 오류는 EAP 신원에 속하고 그 앞의 오류는 게이트웨이를 가리킵니다. Windows 클라이언트의 연결 패널에 있는 단계 텍스트도 같은 말을 합니다.

어떤 인증서든 건드리기 전에 클라이언트 시계를 확인하십시오. 시간이 몇 시간 어긋난 기기는 실제로 만료된 인증서와 같은 유효성 오류를 냅니다. 시계를 맞추는 것은 오 초의 수정이고, 애초에 문제가 아니었던 인증서를 교체하는 것은 서비스 중단입니다.

어느 엔드포인트가 PEAP을 종료하는지 찾으십시오

게이트웨이와 RADIUS 구성에서 게이트웨이는 EAP를 전달할 뿐 종료하지 않습니다. strongSwan의 eap-radius 플러그인이 교환을 RADIUS 서버에 넘기고, 그 서버가 PEAP TLS 세션과 인증서를 소유합니다. 실패한 시도 하나를 두 로그에서 대조하고, 어느 프로세스가 실제로 그 세션의 인증서를 골랐는지 확인하십시오.

NPS에서는 인증서가 로컬 컴퓨터 저장소에 있어야 하고, 서버 인증 용도를 지녀야 하며, 클라이언트가 기대하는 이름과 일치해야 하고, 서비스 계정이 읽을 수 있어야 합니다. NPS에 대한 Microsoft의 인증서 요구 사항이 이런 조건을 나열합니다. 다른 EAP 서버에는 자체 선택 규칙이 있으므로 NPS의 세부 사항을 FreeRADIUS 배포에 복사하거나 그 반대로 하지 마십시오. 두 구성 모두에서 통하는 규칙은 PEAP을 종료하는 엔드포인트가 여러분이 바꾸려는 인증서를 소유한다는 것입니다.

EAP가 끝나는 곳에서 인증서를 교체하십시오

PEAP을 종료하는 엔드포인트에서 지원되는 절차로 인증서를 갱신하거나 교체하고, 서버 인증 용도와 기대 이름을 유지하십시오. 서비스가 찾는 위치에 전체 체인을 설치하고 서비스에 개인 키 접근 권한을 주십시오. 많은 서비스가 이전 인증서를 메모리에 두고 계속 제시하므로 서비스를 다시 시작하거나 다시 바인딩하십시오. 컴퓨터에 복사한 파일은 서비스가 실제로 어느 인증서를 제시하는지 아무것도 증명하지 못합니다.

다음 시도를 서비스 자체 로그와 대조하거나 세션이 제시한 인증서를 검사해 변경을 확인하십시오. 그 로그에 아직 옛 지문이 보인다면 재시작이 적용되지 않은 것입니다.

디렉터리에서 가장 새로운 파일이 사용 중인 파일이라고 가정하지 마십시오. 이름은 맞고 권한이 틀린 복사본은 아무것도 바꾸지 못합니다. 변경은 파일 타임스탬프가 아니라 제시된 신원으로 판단하십시오.

하지 말아야 할 일

오류를 피하려고 PEAP 검증을 끄거나 더 약한 내부 방식을 강요하지 마십시오. 그러면 정책이 바뀌고, 만료된 인증서를 애초에 잡아낸 서버 인증 속성이 사라집니다. 동작하는 검사를 동작하는 연결과 맞바꾸는 셈이고, 다음 만료된 인증서는 아무런 예고도 없이 찾아올 것입니다.

다른 운영 체제의 성공적인 연결을 인증서가 허용 가능하다는 증거로 삼지 마십시오. 그 클라이언트는 다른 EAP 방식을 쓰거나 다른 신뢰 저장소를 쓰거나 서버 검증을 아예 하지 않을 수 있으므로, 성공했다고 해서 여기서 실패한 검사에 대해 말해 주는 것은 없습니다. 의도적인 부정 테스트를 하나 유지하되, 예를 들어 이름이 틀린 인증서나 신뢰할 수 없는 체인이 예상대로 실패하는지 확인하는 것입니다. 그 테스트가 이제 통과한다면 인증서를 고친 것이 아니라 검사를 없앤 것입니다. 어느 신원이 실패했는지 적어 두어 다음 사람이 다시 게이트웨이 인증서부터 시작하지 않게 하십시오.