토큰이 있는데도 OpenVPN이 계속 개인 키 파일을 요구하는 이유

토큰을 꽂으면 공급자 자체 도구는 이를 인식하지만 VPN 클라이언트는 여전히 개인 키 파일을 요구합니다. 이 요구는 토큰이 지원되지 않는다는 증거가 아닙니다. 보통 프로필이 클라이언트에 토큰 사용을 알려주지 않아 기본값으로 기대하는 인증서와 키 입력으로 돌아간 경우입니다.

그 대체 경로가 멈추려면 두 개의 별도 값이 올바라야 합니다. 토큰을 노출하는 공급자와 그 안에 있는 인증서 ID입니다. 이 둘은 서로 다른 옵션으로 지정되며 혼동하기 쉽습니다.

프로필이 그렇게 지시하기에 클라이언트가 파일을 요구한다

기본 프로필은 인증서 파일과 개인 키 파일, 또는 단일 PKCS#12 번들을 기대합니다. 이 입력이 없으면 클라이언트는 로드할 것이 없어 파일이 없을 때와 거의 같은 동작을 하므로, 증상은 빠진 메커니즘이 아니라 깨진 경로로 읽힙니다. PKCS#11 경로는 이 입력을 보완하는 것이 아니라 대체하므로, 여전히 키 파일을 지정한 프로필은 계속 파일을 사용합니다. 파일 입력을 의도적으로 제거하고 토큰이 두 부분을 모두 공급하도록 하세요.

공급자 옵션은 미들웨어 라이브러리를 지정하며, 장치도 인증서도 아닙니다. 패키지된 클라이언트가 그 라이브러리를 로드할 수 있는지는 빌드 방식에 달려 있으며, 일부 빌드만 켜는 선택적 p11-kit 지원도 포함됩니다. 일반 자습서로는 패키지의 구성을 알 수 없습니다.

직렬화된 ID는 다른 값이다

인증서 ID는 검색 프로세스가 만드는 긴 직렬화 문자열이며, 라이브러리 경로도, 토큰 PIN도, VPN 계정 이름도 아닙니다. 인용이 필요한 문자를 자주 포함하고, 인용하지 않은 값은 명확한 오류 없이 잘리거나 잘못 읽힐 수 있습니다. 클라이언트 자체의 ID 검색 옵션으로 토큰이 노출하는 항목을 나열한 뒤 원하는 항목을 정확히 복사하세요. 목록의 첫 번째 객체를 고르는 것이 장치가 결국 잘못된 인증서를 제시하는 경로입니다.

검색 출력은 앞선 질문에도 답합니다. 그 공급자를 통해 토큰이 아예 보이는지 여부입니다. 아무것도 나열하지 않으면 문제는 VPN 클라이언트보다 상류에 있으며 미들웨어에 속합니다.

연결하는 프로세스가 토큰에 도달해야 한다

데스크톱 세션에서 동작하는 토큰 작업은 시스템 서비스에 대해 아무것도 증명하지 않습니다. 서비스는 다른 사용자로, 다른 마운트 네임스페이스에서, 공급자 라이브러리를 빼는 모듈 경로로, 또는 장치 노드를 열 권한 없이 실행될 수 있습니다. 실제로 연결을 보유한 프로세스를 식별하고 그 맥락에서 테스트하세요.

PIN 처리는 별도의 결정이 필요합니다. 참조 구현은 PIN 캐시와 보호된 인증 경로를 제공하며, 둘 다 운영자가 워크플로를 발명하는 대신 선택할 수 있도록 존재합니다. 무인 요구를 공유 프로필 안의 평문 PIN으로 바꾸지 마세요. 토큰의 보호를 편의와 맞바꾸는 일입니다. 토큰이 키 내보내기를 금지하는 경우 서명은 장치에서 이루어지고 PIN이 유일한 로컬 비밀입니다. 그에 걸맞은 주의로 다루세요.

토큰이 대체하지 않는 것

토큰은 배포된 정책 아래에서 클라이언트를 인증하며, 서버에 대한 클라이언트의 검증을 대체하지 않습니다. 성공적으로 선택된 인증서는 예상치 못한 게이트웨이 인증서를 받아들일 권한이 아니며, 두 검증은 반대 방향을 보호합니다.

등록은 여전히 발급자 쪽에서 이루어져야 하고, 게이트웨이는 여전히 그 ID를 승인해야 합니다.

승인을 위해 단계를 분리하세요. 공급자가 로드되고, 의도한 인증서가 발견되고, 개인 키가 로컬 권한으로 사용되고, VPN이 인증되고, 리소스 작업이 성공합니다. 비밀번호를 오가며 암호화 스택을 재설치하는 대신 실패한 첫 단계에서 멈추세요.

버전, 모듈 소유권, 선택한 공개 식별자, 정리된 오류를 기록하고, PIN과 자격 증명 번들은 그 기록에서 제외하세요.