GUI가 여는 프로필에서 OpenVPN 서비스가 실패할 때: 다섯 가지 점검

두 실행기가 한 머신에서 같은 프로필을 열지만 GUI만 연결됩니다. 파일은 멀쩡하고 설치 프로그램도 아마 정상일 것입니다. 다른 것은 각 실행기가 openvpn.exe에 주는 컨텍스트입니다. 작업 디렉터리, 계정 ID, 파일 속성은 모두 그 컨텍스트를 따라 움직입니다. 이 순서대로 확인하고 오류를 설명하는 첫 항목에서 멈추십시오.

어느 실행기가 실패하는지 확인하십시오

먼저 분리를 입증하십시오. 같은 프로필 경로로 GUI는 연결되고 서비스는 연결되지 않는다면, 파일은 누군가 읽을 수 있고 질문은 누가 어디서 읽는가로 바뀝니다. 둘 다 실패하면 프로필이 깨진 것이며 이 이야기는 해당되지 않습니다. 서비스 이름과 로드하도록 지시받은 정확한 프로필을 적어 두십시오.

자체 자동 시작 디렉터리를 가리키는 서비스는 편집기에서 연 파일을 로드하지 않을 수 있습니다. 서비스 구성의 경로와 GUI의 경로를 한 글자씩 비교하십시오. 끝에 붙은 폴더 이름이나 다른 드라이브 문자만으로도 잘못된 분기로 갈 수 있습니다.

상대 경로가 해석되는 곳

ca.crt이나 도우미 스크립트를 이름만으로 참조하는 프로필은 프로세스가 있는 위치를 기준으로 검색을 요구합니다. GUI는 구성 폴더에서 시작하므로 그 이름들이 해석됩니다. 서비스 관리자가 시작한 서비스에는 그런 시작점이 없어, 인증서를 읽기 전에 검색이 실패합니다. 그래서 같은 프로필이 한 실행기에서는 되고 다른 실행기에서는 안 되는 것입니다.

래퍼에 시작 디렉터리를 주거나 모든 참조를 절대 경로로 만드십시오. GUI의 컨텍스트를 명령줄에서 재현하면 다음과 같습니다.

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

그 명령의 상세도를 높이면 시도된 정확한 경로가 표시됩니다. 권한을 바꾸기 전에 이것을 하십시오. 파일 누락과 읽기 거부는 서로 다른 수정이 필요합니다. 기본 로그는 둘을 구분하지 못합니다. 플래그 하나로 한 시간의 추측을 아낄 수 있습니다.

서비스 ID가 읽을 수 없을 때

서비스는 당신이 아니라 시스템 ID로 실행됩니다. 당신의 사용자에게 모든 권한을 주고 다른 누구에게도 주지 않는 ACL은 당신의 세션에서는 완벽히 작동하지만 거기서는 실패합니다. 매핑된 드라이브나 인증된 공유에 둔 프로필도 같은 이유로 실패합니다. 다른 것을 보기 전에 파일 권한을 확인하십시오.

점검은 유효 권한 읽기와 서비스 ID로서 시도하는 읽기입니다. 앞부분은 관리자 권한 프롬프트에서 실행하십시오.

icacls "C:\VPN\profiles\office\office.ovpn"

그다음 같은 읽기를 서비스 ID로서 시도하십시오. 예를 들어 Sysinternals의 psexec -s -i를 사용하고 파일이 열리는지 보십시오. 열리지 않으면 어떤 경로 수정도 소용없습니다. ACL을 고치거나 서비스 ID가 읽을 수 있는 위치로 프로필을 옮기십시오.

파일 수준 암호화는 두 번째이자 더 드문 경우입니다. Encrypting File System 속성이 붙은 프로필은 암호화한 사용자에게는 투명하게 복호화되고 서비스 계정에는 읽히지 않습니다. 그래서 같은 파일이 편집기에서는 열리고 서비스 아래에서는 열리지 않습니다.

속성은 관리자 권한 프롬프트에서 보이며, 확인해도 프로필이 열리지는 않습니다. 두 명령을 모두 실행하고 출력을 읽으십시오.

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

속성을 지우면 파일을 읽을 수 있게 되지만, 그것이 지니던 보호도 사라집니다. 프로필이 보호된 채로 남아야 한다면 사용자별 암호화에 의존하는 대신 서비스 ID에 명시적 권한이 있는 위치에 비밀 자료를 두십시오. 그런 배치는 암호 변경에도 견디고, 파일을 암호화한 사람이 아닌 다른 사람이 접근을 검토할 수 있게 합니다.

터널의 소유자를 정하기

GUI는 암호를 요구할 수 있고 사용자 저장소에서 인증서를 읽을 수 있습니다. 서비스는 둘 다 못 하므로, 대화형 비밀에 의존하는 프로필은 경로를 어떻게 고쳐도 무인으로 시작되지 않습니다. 그 한계는 설계 결정이며 우회할 결함이 아닙니다. 다른 무엇을 바꾸기 전에 소유자를 하나 고르십시오.

로그인 전에 터널이 올라와 있어야 한다면 서비스에 무인 자격 증명 원본과 프로필의 자체 사본을 주십시오. 책상에 있는 동안만 존재하면 된다면 GUI에 두고 서비스 사본을 제거하십시오. 둘 다 동시에 두는 것이 어댑터 충돌과 중복 경로를 만드는 구성입니다.

그 충돌은 보통 하나의 어댑터를 두고 다투는 두 소유자가 아니라 구성 오류로 진단됩니다. 이벤트 로그에는 한 프로세스가 TAP 장치를 열지 못하는 것이 보이는데, 권한 문제처럼 보이지만 아닙니다. 먼저 소유자를 세십시오.

서비스 래퍼가 실제로 시작하는 것

서비스 진입점은 자신이 저장한 매개변수를 읽고 나서 openvpn.exe을 시작하는 작은 래퍼입니다. 이벤트 로그의 명령줄이 기대와 다를 때, 바로 그 값들이 살펴볼 대상입니다. 재설치하면 기본값으로 돌아가고 증거가 사라집니다. 먼저 읽으십시오.

값은 레지스트리의 서비스 자체 키 아래에 있고, sc qc은 서비스 관리자가 시작할 바이너리 경로를 보여 줍니다. 둘 중 하나를 편집하기 전에 그 경로를 래퍼의 저장된 구성과 비교하십시오.

래퍼를 직접 관리하는 스크립트로 바꾸는 것은 더 침습적이지만, 실효 명령줄을 읽을 수 있는 파일 하나로 접습니다. 재시작으로 끝내고, 첫 성공적인 시작 줄이 나타날 때까지 프로필별 로그를 읽으십시오. 서비스 상태가 실행 중이라는 것은 래퍼가 종료되지 않았다는 뜻일 뿐이며, 자식이 즉시 죽었을 때도 마찬가지입니다.