클라이언트 인증서 없는 OpenVPN: 프로필이 아닌 서버 정책

인증서와 키 줄을 지우고 프로필을 넘겨도 연결은 여전히 인증서 오류로 실패합니다. 그 요구 사항을 강제한 것은 프로필이 아니었습니다. 클라이언트 인증서가 필수인지 결정하는 것은 서버이며, 클라이언트 쪽 편집으로는 협상해 없앨 수 없습니다. 따라서 해결책은 의도적으로 수행하는 서버 정책 변경이며, 그에 의존하는 모든 것이 같은 작업에서 갱신됩니다.

프로필은 정책이 아니다

Community OpenVPN 2.6은 verify-client-cert의 기본값이 require이기 때문에 클라이언트 인증서가 필수인 상태로 제공됩니다. 이를 none로 설정하는 것이 인증서 요구를 멈추고 클라이언트 인증을 서버가 이미 운영하는 사용자 이름과 비밀번호 방식에 넘기는 방법입니다. 오래된 안내서는 같은 개념의 옛 표기인 client-cert-not-required로 손을 뻗지만, 설치된 버전이 문서화하는 지시문을 사용하십시오. 어느 쪽이든 변경은 서버에서 이루어지며 어떤 클라이언트 프로필로도 수행할 수 없습니다.

아래 조각은 서버 쪽 변경의 전부이며, 그 자체로는 동작하는 인증 구성이 아닙니다. verify-client-cert none는 인증서 요구를 제거하고, username-as-common-name는 계정 이름을 이후 콜백과 클라이언트별 파일이 보는 식별자로 만듭니다. 어느 줄도 비밀번호를 검사하지 않으므로 검증기는 여전히 존재해야 합니다.

verify-client-cert none
username-as-common-name

그 검증기는 auth-user-pass-verify에 의해 구동되는 플러그인 또는 스크립트이며, 위의 어느 줄이든 의미를 가지기 전에 제자리에 있어야 합니다. 순서를 뒤집으면 서버가 인증서를 요구하지도 않고 계정을 검사하지도 않는 구간이 생깁니다.

무엇이 여전히 서버를 검증하는가

클라이언트 인증서를 버리는 것이 TLS를 버리는 것은 아닙니다. 서버는 자신의 인증서와 키를 유지하고, 클라이언트는 사칭자와 대화하지 못하게 하는 CA 신뢰와 호스트 이름 검사를 유지합니다. 클라이언트에 더 이상 인증서가 없다고 remote-cert-tls server나 CA 번들을 제거하는 것은 흔하고 심각한 오독이며, 2.6 참조는 두 방향이 독립적임을 분명히 밝힙니다. 하나는 클라이언트에게 서버를 증명하고, 다른 하나는 서버에게 클라이언트를 증명합니다.

프로필은 tls-auth 또는 tls-crypt 블록을 가질 수도 있습니다. 이는 자체 배포 및 교체 주기를 가진 제어 채널 공유 키이므로, 인증서나 키 줄이 없는 파일이 자동으로 게시하기에 안전한 것은 아닙니다. 읽을 때까지 비밀로 취급하십시오.

동작하는 프로필에서 복사한 인증서 파일은 그 자체로 아무것도 증명하지 않으며, 소유는 그에 맞는 개인 키를 보유하는 것을 뜻하고, 인증서 인증 배포가 이를 검사합니다. 인증서를 담은 파일은 그것으로 인증할 수 있는 파일이 아닙니다.

검증기가 해야 할 일

인증서 요구가 제거되면 모든 것이 검증기, 즉 플러그인이거나 auth-user-pass-verify에 의해 구동되는 스크립트에 달려 있습니다. 유효하지 않은 자격 증명을 거부하고, 비활성화되었거나 자격이 없는 계정을 거부하며, 백엔드에 도달할 수 없을 때 닫힌 상태로 실패해야 합니다. username-as-common-name는 종종 함께 활성화되며, 이후 콜백과 클라이언트별 구성 파일이 보는 식별자를 바꿉니다. 비밀번호를 검증하지 않으며 자격이 없는 계정을 자격 있는 계정으로 만들지도 않습니다. 이들은 별개의 작업이며, 이를 혼동하는 것이 마이그레이션이 행복 경로 테스트를 통과하고 첫 실제 사고에서 실패하는 방식입니다.

부정적인 경우를 긍정적인 경우만큼 세심하게 시험하십시오. 비밀번호 프롬프트를 표시하는 프로필은 클라이언트가 프롬프트를 그릴 수 있다는 것만 증명하지만, 잘못된 비밀번호를 받아들이는 서버는 훨씬 더 나쁜 것을 증명합니다. 시험 집합에 나쁜 비밀번호만이 아니라 비활성화된 계정과 만료된 자격 증명도 추가하십시오.

정책, 프로필, 매핑을 함께 바꾸십시오

서버 지시문, 클라이언트 프로필, 그리고 클라이언트별 식별자 매핑의 세 가지를 조정하십시오. 따로 바꾸면 클라이언트가 검증 전에 실패하거나 관리자가 예상하지 못한 이름으로 연결되며, 후자는 성공처럼 보이기 때문에 더 나쁩니다. 잘못된 식별자로 성공한 연결은 실패한 연결보다 알아채기 어렵습니다.

이 경로에는 유효한 계정 하나와 알려진 불량 계정 하나, 두 개의 시험 계정을 두고 검증기를 바꿀 때마다 둘 다 사용하십시오. 유효한 계정은 행복 경로와 식별자 매핑을 증명하고, 불량 계정은 거부가 여전히 작동함을 증명합니다. 어느 시험도 자격 규칙에 대해 아무것도 알려주지 않으므로, 배포에 그러한 규칙이 있다면 정책상 거부되어야 할 계정을 추가하십시오. 모든 것을 받아들이기 시작한 검증기는 동작하는 로그인과 똑같이 보이므로, 변경할 때마다 셋 다 실행하십시오.

서버가 실제로 어떤 인증 방법을 받아들이는지, 프로필이 암시하는 방법이 아니라 기록하십시오. 그 기록은 사람들이 계속 묻는 질문, 즉 누가 이 서비스에 연결할 수 있는지에 답합니다. 또한 그렇지 않으면 패킷 캡처에서 이를 다시 발견하게 될 다음 관리자보다 오래 남습니다.