.ovpn 파일을 편집해도 서버의 MFA가 켜지지 않는 이유

프로필에 auth-user-pass 를 추가하고 다시 연결하면 클라이언트가 사용자 이름과 비밀번호를 묻습니다. MFA가 켜진 것처럼 보입니다. 그런데 잘못된 계정의 코드나 십 분 전에 만료된 코드를 입력해도 터널은 그대로 올라옵니다. 이것이 증상입니다. 클라이언트는 바뀌었지만 서버는 바뀌지 않았습니다. 일회용 비밀번호는 서버의 검증자가 그 코드를 요구하는 신원에 대해 유효한지 판단할 때만 요소가 됩니다.

프롬프트가 증명하는 것은 클라이언트가 요청했다는 사실뿐입니다

.ovpn 파일은 클라이언트 측 문서입니다. 클라이언트에게 자격 증명을 요구하게 하거나, 캐시하게 하거나, 캐시를 중단하게 할 수 있습니다. 하지만 사용자를 등록하거나, PAM 모듈을 설치하거나, 서버가 지금 확인하지 않는 두 번째 요소를 요구하도록 만들 수는 없습니다.

휴대폰에 인증 앱을 설치해도 그 관계가 생기지는 않습니다. Google Authenticator PAM 프로젝트는 OTP 검증 구성 요소이며 OpenVPN 뒤에 둘 수는 있지만, 가져온 프로필에 Google 계정 로그인을 붙이는 방법은 아닙니다.

프로필이 할 수 없는 부분이 바로 등록입니다

TOTP에는 인증 앱과 그 검증자 사이에 공유되는 등록 자료가 필요합니다. 휴대폰의 여섯 자리는 출력이고, 그 뒤의 시드가 비밀이며, 하나의 신원에 속합니다.

따라서 운영자에게는 올바른 시드를 올바른 VPN 신원에 묶는 등록 절차와 함께 분실한 휴대폰을 위한 검증된 재발급 경로 가 필요합니다. 사용자가 자기 이름을 붙인 파일을 업로드하게 하면 등록이 계정 탈취의 기회가 되며, 업로드를 암호화해도 그것은 달라지지 않습니다.

PAM 기반 설계가 VPN 사용자마다 별도의 Unix 계정을 만들 필요는 없습니다. 모듈 문서 는 대체 비밀 경로와 파일 접근 전용 계정을 지원하는데, 이는 파일 시스템 신원이지 검증 대상인 로그인 신원이 아닙니다.

흔한 실수는 단일 사용자 예제에서 복사한, 사용자 이름 하나로 끝나는 고정 비밀 경로입니다. 그것은 하나의 신원을 보여 주는 예시일 뿐 사용자별 조회가 아니며, 모든 요청에 그것을 쓰면 누구도 독립적으로 등록된 인증 앱을 갖지 못합니다. 신원 매핑을 적어 두고, 시드 파일을 보호하고, 비밀번호·인증서·계정 검사를 같은 인증 스택에 두십시오.

PAM 스택을 읽고 실제로 무엇이 요구되는지 확인하십시오

account required pam_permit.so 같은 줄은 계정 자격을 구현하지 않으며 요소를 추가하지도 않습니다. 그것은 PAM 계정 관리 단계를 허용할 뿐이고, 이는 단계에 대한 진술이지 사용자에 대한 진술이 아닙니다.

관대한 등록 옵션도 마찬가지입니다. 등록된 비밀이 없는 사용자를 받아들이는 것은 의도적인 배포 선택일 수 있지만, MFA가 필수라는 증거는 아니며 종료 날짜가 있는 임시 예외로 기록해야 합니다.

클라이언트의 상호 작용을 서버 설계에 맞추십시오

auth-user-pass

이 지시문은 사용자 이름과 비밀번호 입력을 요구합니다. PAM을 설정하지도, 등록 기록을 만들지도, 비밀번호 필드에 TOTP 값이 들어 있다고 서버에 알리지도 않습니다. 서버 통합과 클라이언트는 배포가 실제로 지원하는 상호 작용에 합의해야 합니다. 챌린지, 문서화된 결합 자격 증명 형식, 또는 제품별 흐름입니다.

클라이언트가 필드 하나를 보여 준다고 해서 비밀번호에 코드를 덧붙이지 마십시오. 그것은 서버 플러그인이 정확히 그 형식을 기대하는 곳에서만 동작하고, 다른 모든 곳에서는 혼란스럽게 실패합니다.

시드와 QR 자료는 공유 프로필과 일상적인 진단 로그에서 멀리 두십시오. 인증된 로그인 채널로 제출한 코드는 통제된 등록 중에 발급된 시드와 같은 객체가 아니며, 둘을 지원 티켓에서 섞는 것이 비밀이 새는 경로입니다.

재연결, 토큰, 그리고 결판을 내는 테스트

첫 로그인에 성공한 뒤에 무슨 일이 일어나는지 계획하십시오. 이전에 받아들여진 코드는 다음 인증에서 만료되었거나 재전송으로 거부될 수 있습니다. auth-nocache 는 자격 증명 보존을 제어할 뿐 MFA를 설치하지 않으며, reneg-sec 0 도 포럼 스레드에 아무리 자주 등장해도 TOTP 지원의 정의가 아닙니다.

일부 배포는 최초 확인 후 인증 토큰을 발급해 재연결 때 다시 묻지 않게 합니다. 그것은 자체 유효 기간과 폐기 절차를 가진 설계 결정이지, 물려받는 기본값이 아닙니다.

그다음 사람들이 실제로 쓰는 클라이언트로 입장 정책을 시험하십시오. 올바른 비밀번호와 인증서, 현재 코드를 가진 등록된 사용자는 연결되어야 합니다. 잘못된 코드, 등록이 없는 사용자, 금지된 계정은 각각 실패해야 하고, 그 이유가 서버 로그에 보여야 합니다. 그 거부들을 보기 전까지는 정책이 아니라 프롬프트가 있는 것입니다.