OpenVPN username-as-common-name: CN 검사가 비어 있는 이유
common_name과 username을 비교하는 client-connect 스크립트는 이름을 자기 자신과 비교할 수 있습니다. 대체가 실행되기 전에 인증서를 계정에 묶으십시오.
client-connect 스크립트를 추가해 common_name 이 username 과 다른 모든 연결을 거부하면, 인증서와 계정을 묶는 것처럼 보입니다. username-as-common-name 을 실행하는 서버에서는 스크립트가 실행될 때 그 비교가 이미 의미를 잃은 상태입니다. 두 값이 같은 문자열이므로, 완전히 다른 사람에게 발급된 인증서에도 테스트가 통과합니다.
스크립트를 나쁘게 작성해서 검사가 틀린 것이 아닙니다. 읽는 값이 같은 연결 안에서 앞서 대체되었기 때문에 틀린 것입니다.
그 비교가 증명하는 것처럼 보이는 것
인증서 인증과 비밀번호 인증은 별개의 증명이며, 서버는 두 가지가 같은 사람의 것임을 요구하지 않고도 둘 다 요구할 수 있습니다. 그 간극은 실재합니다: 유효한 장치 인증서와 임의의 유효한 계정의 조합은 같은 인증서와 이름이 지정된 하나의 계정의 조합과 다른 주장입니다. common_name 과 username 을 비교하는 스크립트는 둘 사이의 빠진 고리처럼 읽힙니다. common_name 이 아직 인증서가 말한 것을 뜻한다면 실제로 그럴 것입니다.
그런지는 서버 옵션 하나에 달려 있고, 그 옵션은 보통 무관한 이유, 예를 들어 사용자별 구성 파일의 이름을 붙이기 쉽게 하려는 이유로 켜집니다.
username-as-common-name이 이름에 하는 일
username-as-common-name 이 켜져 있으면, OpenVPN 은 사용자 이름과 비밀번호가 검증된 뒤 인증서의 공통 이름을 인증된 사용자 이름으로 대체합니다. 그 검사 중에 실행되는 검증 훅은 대체가 아직 일어나지 않았으므로 여전히 인증서의 공통 이름을 받습니다. 그 이후의 모든 것, client-connect 을 포함해, 사용자 이름을 봅니다. 따라서 나중의 콜백은 같은 신원을 두 번 받고 제시된 인증서와 비교할 수 없습니다.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
bob-device 에 발급된 인증서, alice 로서의 디렉터리 로그인 성공, 옵션이 켜져 있는 한 가지 예시 연결을 따라가 봅시다. 검증 단계는 여전히 두 개의 서로 다른 문자열을 볼 수 있습니다. 연결 단계는 alice 과 alice 을 봅니다.
그 예시는 비교가 왜 비어 있는지 보여 줍니다. 인증서 유효성 검사와 비밀번호 검증이 여전히 따로 실행되므로, 연결이 다른 이유로 허용되었을 것인지는 보여 주지 않습니다.
두 신원이 여전히 존재하는 단계에 연결 고리를 두십시오
규칙은 인증서 신원과 계정을 동시에 보는 단계에서 적용되어야 하며, 실제로는 사용자 이름과 비밀번호 검증 훅이나 그곳에 로드된 플러그인을 의미합니다. 이미 비밀번호 검증을 수행하는 지원 플러그인이 보통 짝 규칙을 추가하기에 알맞은 곳이며, 이름 비교로 대체하면 비밀번호 검사가 완전히 사라지기 때문입니다.
동일성이 실제 정책인 경우는 드물기 때문에 코드를 작성하기 전에 매핑을 정의하십시오. 인증서는 흔히 장치를 식별하고 로그인은 사람을 식별하며, 하나의 장치가 여러 사람에게 정당하게 쓰일 수 있습니다. 관계를 발급을 통제할 수 있는 형태로 저장하고, 이름 변경, 재발급, 도메인 한정 이름에서 무슨 일이 일어나는지 정하십시오. 디렉터리를 이해하지 않은 채 소문자로 바꾸거나 도메인 접두사를 제거하면 별개로 남아야 할 두 계정이 합쳐질 수 있습니다.
client-config-dir 은 공통 이름을 기준으로 정해지므로, 이 옵션은 어떤 클라이언트별 구성이 적용되는지도 바꾼다는 점을 기억하십시오.
두 개의 유효한 자격 증명으로 짝 규칙을 시험하십시오
정책이 허용하는 짝에서 시작해 연결되는지 확인하십시오. 그다음 같은 유효한 인증서를 다르지만 유효한 계정과 함께 제시하면 그 시도는 실패해야 하며, 비밀번호를 잘못 입력해서가 아니라 짝 규칙 때문에 실패해야 합니다. 잘못된 비밀번호는 비밀번호 검사가 작동함을 증명할 뿐, 인증서와 계정 사이의 규칙에 대해서는 아무것도 말하지 않습니다.
인증서가 없는 경로와 유효하지 않은 인증서 경로도 확인하고, 서버가 클라이언트별 설정에 어떤 신원을 쓰는지 확인하십시오. 비교가 작동하게 하는 유일한 방법이 username-as-common-name 을 끄는 것이라면 모든 클라이언트의 구성 조회가 인증서 이름으로 되돌아가기 때문에 먼저 그 변경의 비용을 따져 보십시오.