OpenVPN PAM: login 인수는 사용자가 아니라 서비스입니다

서버에 사용자를 추가했고 비밀번호도 올바르게 입력했는데 연결은 여전히 AUTH_FAILED로 끝납니다. 보통은 플러그인 줄이 이유를 설명합니다: 플러그인 경로 뒤의 단어는 PAM 서비스 이름이며, 어떤 모듈 스택이 질문에 답할지 결정합니다. 그것은 사용자 이름이 아니고, OpenVPN이 직접 읽는 비밀번호 파일을 가리키는 것도 아닙니다.

두 번째 단어가 선택하는 것

설정 줄은 플러그인 경로와 인수 하나를 받습니다:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

그 인수는 서비스 이름으로 PAM 라이브러리에 전달되므로 /etc/pam.d/openvpn의 스택이 실행됩니다. 그곳에 login를 쓰면 대신 대화형 로그인 정책이 적용되며, 그 정책이 배포판에서 포함하는 모듈이 무엇이든 함께 적용됩니다.

다른 호스트에서 복사한 경로가 아니라 설치된 패키지가 제공하는 플러그인 경로를 사용하세요. 파일 이름과 디렉터리는 배포판마다 다르며, 잘못된 경로는 인증 시점이 아니라 시작 시점에 플러그인 로드 오류로 실패합니다.

스택이 실제로 계정을 읽는 곳

PAM은 디스패처입니다. 서비스 파일은 모듈을 순서대로 나열하며, 답할 수 있는 첫 번째 모듈이 결과를 결정합니다. pam_unix를 호출하는 스택은 로컬 계정을 읽고, LDAP 또는 RADIUS 모듈을 호출하는 스택은 자격 증명을 완전히 다른 곳으로 보냅니다.

서비스 이름이 해석되는 파일을, 그것이 포함하는 모든 것과 함께 읽으세요:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

스택이 디렉터리로 위임하면 로컬 계정을 추가해도 아무것도 바뀌지 않습니다. 스택이 로컬 계정을 읽으면 디렉터리에서 사용자를 만들어도 마찬가지로 아무것도 바뀌지 않습니다. 계정은 스택이 찾는 곳에 존재해야 하며, 대부분의 이런 보고서에서 진단은 바로 이것입니다.

한 번의 시도, 두 개의 로그

실패한 연결 하나를 양쪽에서 함께 추적하세요. OpenVPN 로그는 플러그인 결과와 클라이언트의 거부를 보여 주고, 시스템 인증 로그는 어떤 모듈이 실행되었고 무엇을 결정했는지 보여 줍니다. 같은 시간대에 두 로그를 함께 읽는 것이 서비스 파일 누락과 백엔드 시간 초과를 구분합니다. 인증 로그에 공백이 있다면 스택까지 전혀 도달하지 않았다는 뜻입니다.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

VPN과 스택을 동시에 디버깅하지 않도록, PAM을 지원하는 유틸리티로 서비스를 직접 테스트하세요. 같은 서비스 이름과 계정으로 직접 테스트가 성공하면 문제는 계정 자체가 아니라 데몬이 자격 증명을 전달하는 방식으로 좁혀집니다.

pamtester openvpn alice authenticate

직접 테스트가 콘솔에서 작동하는 것과 같은 자격 증명으로 실패하면 스택은 당신이 가정한 계정 원본을 읽고 있지 않은 것입니다. 성공하면 플러그인이 수행하는 대화와 클라이언트가 실제로 보낸 내용을 확인하세요. 일부러 틀린 비밀번호로도 한 번 실행해 보면 거부와 모듈 오류의 차이를 볼 수 있습니다. 그 두 결과는 VPN 로그에서는 똑같아 보이고 여기서는 완전히 다릅니다.

전용 서비스가 login 편집보다 낫습니다

VPN 요구 사항이 대화형 로그인과 다를 때, 보통은 다릅니다만, VPN에 자체 서비스 파일을 주세요. login나 common-auth를 편집하면 그것을 포함하는 모든 프로그램의 정책이 바뀌고, 무관한 로그인 문제를 디버깅할 다음 사람이 당신의 변경을 물려받습니다.

필요한 모듈을 작은 서비스 파일에 복사하고 순서를 명시적으로 유지하며 누가 소유하는지 적어 두세요. 비밀번호 재설정이 효과가 없어 보일 때 확인해야 할 대상이 바로 그 파일입니다.

클라이언트가 보내는 것과 보내지 않는 것

클라이언트는 지원되는 프롬프트나 파일을 통해 사용자 이름과 비밀번호를 제공합니다. 서버 플러그인은 그 값을 PAM 대화로 전달하며, 서버 설정에서 읽지 않습니다. 비밀번호를 정의하는 것처럼 보이는 서버 측 줄은 그런 일을 하지 않으며, 어떤 프로필 편집도 계정을 만들지 않습니다.

사용자 이름과 비밀번호는 클라이언트 인증서와 공존할 수 있습니다, PAM을 켠다고 인증서 검증을 멈출 이유는 없습니다. 배포가 의도한 계층은 그대로 두고 계정 원본만 고치세요.

수용 검사는 양방향입니다: 의도한 계정은 성공하고, 거부되어야 할 계정은 여전히 실패합니다. auth-pam 플러그인 README에는 서비스 인수와 그것이 앞단에 둘 수 있는 백엔드가 설명되어 있으며, 구축하려는 구성을 확인할 곳이 바로 거기입니다.