openvpn3 session-start가 자격 증명 파일을 무시하는 이유

2.x 클라이언트로 연결하면 프로필이 작동하지만, 같은 파일을 3.x 클라이언트에 넘기면 암호 프롬프트에서 멈춥니다. --auth-user-pass creds.txt 옵션을 openvpn3 session-start 명령에 넘겨도 새 클라이언트에는 그 파일을 읽는 단계가 없으므로 결과는 같습니다. 이 거부는 의도된 것으로, 자격 증명은 세션에 속하며 세션은 터미널의 프로세스가 아니라 서비스가 만듭니다. 대화형 프롬프트와 autoload 도우미 중 무엇을 쓸지 고르고, 각각이 무엇을 저장하는지 알아 두십시오.

저장된 파일이 갈 곳이 없는 이유

새로운 설계에서는 구성 관리와 세션 관리가 시스템 버스를 통해 통신하는 별개의 서비스입니다. 이 분리가 있기에 일반 사용자가 특권 데몬이 대신 보호된 암호 파일을 읽지 않아도 세션을 시작할 수 있습니다. 파일 기반 자격 증명은 그 모델에서 설 자리가 없는데, 그것을 읽을 데몬 측 시작 단계가 없기 때문입니다. 이 거부는 아키텍처의 결과이며 빠진 기능이 아닙니다.

옛 방식을 이름 붙여 두면 잊기 쉽습니다: 프로필이 자격 증명 파일을 참조하고, 터널이 시작될 때 데몬이 그것을 읽습니다. 새 모델에서 자격 증명은 세션에 속하며 그 세션이 시작될 때 제공됩니다. openvpn3 session-start --config work.ovpn 명령은 그것을 묻고, --auth-user-pass creds.txt 옵션은 거부되는데 그 경로에는 파일을 열 무엇도 없기 때문입니다. 찾을 수 있는 모든 2.x 요령은 더 이상 존재하지 않는 단계를 전제로 합니다.

구성과 사이트 로컬 설정도 분리되어 있으며, 이것이 두 번째 놀라움을 설명합니다. 프로필은 완전해 보여도 그것이 만든 연결에 라우팅과 리졸버 구성이 빠져 있을 수 있습니다. 그 부분들은 가져온 파일과 별도로 사이트 로컬 설정으로 적용됩니다.

프롬프트 경로와 그것이 남기는 세션

세션이 시작될 때 암호를 제공하는 것이 의도된 작업 흐름입니다. 클라이언트는 한 번 묻고 자격 증명을 세션 백엔드에 넘긴 뒤 계속합니다:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

그 경로로는 디스크에 아무것도 기록되지 않습니다. 세션은 터미널이 닫힌 뒤에도 계속 실행되며, 이는 프로세스가 셸과 함께 죽으리라 기대하는 사람들을 놀라게 합니다. 세션 처리를 서비스로 옮긴 이유가 바로 그것입니다. 세션은 그것을 요청한 터미널보다 오래 살아남으며 명시적으로 중지해야 합니다.

사람이 앞에 있는 워크스테이션에서는 이것이 가장 안전한 선택이기도 합니다, 보호하거나 잊어야 할 저장된 비밀이 없기 때문입니다. 사람이 입력할 수 없는 곳에서만 부적합합니다.

키보드 앞에 사람이 없는 자동화

사람 없이 기계가 연결해야 하는 곳을 위해 프로젝트는 openvpn3-autoload 도구를 제공합니다. 이것은 프로필 디렉터리와 프로필마다 대응하는 설명자를 읽으며, 설명자가 자격 증명을 평문으로 제공합니다. 도우미는 보통 /usr/sbin/openvpn3-autoload 에 있는 별도 바이너리이고 session-start 명령의 플래그가 아닙니다. 설정하려면 디렉터리를 만들고 설명자가 기대하는 이름으로 프로필을 복사하고 설명자를 작성해야 합니다.

사용자별 설정은 다음과 같으며 세션을 소유할 계정으로 실행합니다. 디렉터리 모드가 다른 로컬 사용자를 배제합니다:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

설명자는 자격 증명을 지정하고 자동 시작을 요청합니다. 암호 값은 버전 관리 밖에 두십시오:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

그다음 도우미를 한 번 호출하고 세션이 나타나는지 확인합니다. 두 번째 명령은 확인이지 또 다른 설정 단계가 아닙니다:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

부팅 시 openvpn3-autoload.service 이라는 패키지된 유닛은 사용자별 디렉터리가 아니라 시스템 전체 디렉터리 /etc/openvpn3/autoload 를 사용합니다. 그 위치에는 root 소유권과 더 엄격한 모드가 필요하며, 설명자에는 여전히 암호가 평문으로 들어 있습니다. 절충은 명확합니다: 이제 암호가 디스크에 있으므로 그 디렉터리를 비밀로 취급하고, 호스트 밖 백업에서 제외하고, 사람이 있을 때는 항상 대화형 경로를 선택하십시오.

암호 오류처럼 보이는 버스 오류

자격 증명 탓으로 돌려지는 오류 중에는 전혀 그렇지 않은 것이 있습니다. 서비스 활성화 경로를 지목하는 권한 오류는 두 가지 중 하나를 뜻합니다: 백엔드가 실행 중이 아니거나, 호출자에게 그것을 활성화할 권한이 없거나. 프로필을 편집해도 둘 다 바뀌지 않습니다. 구성을 건드리기 전에 서비스 상태와 함께 제공되는 버스 정책을 확인하십시오.

아래 명령은 이 둘을 구분합니다. 첫 번째는 백엔드가 실행 중인지 보고하고, 두 번째는 최근 버스 오류를 보여 줍니다:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

또 하나 흔한 오독은 나타났다가 곧바로 사라지는 세션입니다. 그 패턴은 보통 사이트 로컬 설정이 적용된 적이 없어서 터널이 그것을 유용하게 만드는 경로와 리졸버 변경 없이 올라왔다는 뜻입니다. 마지막 줄이 아니라 순서를 읽으십시오: 세션이 생성되었는지, 연결 상태에 도달했는지, 살아남았는지는 세 가지 별개의 사실입니다.

옛 클라이언트를 아직 쓰는 경우

2.x 클라이언트는 여전히 자격 증명 파일을 받아들이고, 키링은 비밀이 디스크에 닿지 않게 프롬프트에 답할 수 있습니다. 래퍼가 항목을 해석하므로 파일에는 암호가 아니라 조회 이름이 들어갑니다. 이 구성은 잠금 해제된 키링에 의존하며, 로그인 세션이 없는 컨테이너나 누군가 로그인하기 전에 시작되는 유닛은 그것을 제공할 수 없습니다. 그러면 조회 도구는 쓸 수 없는 컬렉션을 보고하고, 키링 오류가 자격 증명 오류처럼 보입니다.

그런 것을 만들기 전에, 프로필의 keepalive 설정이 재시작 필요성을 아예 없애는지 확인하십시오. 계속 올라와 있는 세션은 자동화하려는 프롬프트에 결코 도달하지 않습니다.