OpenVPN 3 Linux: 되돌리기 전에 D-Bus 오류를 읽으세요

OpenVPN 3 Linux의 실패는 낯선 이름이 붙은 D-Bus 메서드 오류로 도착하며, 패키지를 내리고 기도하고 싶어진다. 클라이언트는 하나의 프로그램이 아니다. 명령줄 프런트엔드는 버스를 통해 프로필, 세션, VPN 엔진, 특권이 필요한 네트워크 변경을 각각 소유한 서비스와 대화한다. 실패한 호출을 이 다섯 중 누가 가졌는지 가리는 것이 진단의 대부분이며, 비용은 되돌리기가 아니라 명령 하나다. 다음은 그 판단을, 실패가 보통 나타나는 순서대로 정리한 것이다.

명령 하나 뒤의 다섯 주인

중요한 것은 다섯 프로세스이고 각자 자신의 버스 이름을 가진다. 명령을 받는 프런트엔드, 프로필과 그 접근 정책을 보관하는 구성 관리자, 세션 수명을 소유하는 세션 관리자, OpenVPN 3 Core Engine을 통해 연결을 돌리는 백엔드, 그리고 인터페이스와 경로, DNS 설정을 설치하는 네트워크 구성 서비스다. 그러므로 구성 객체를 지목하는 오류는 백엔드 오류가 아니고, 시작하지 않는 백엔드는 인증 실패가 아니다. 메시지를 어느 줄에 넣을지는 무엇이든 바꾸기 전에 정해야 한다. 이후의 모든 단계가 어느 줄이 참인지에 달려 있기 때문이다. 줄을 짐작하는 것이 작은 수정을 패키지 작업 반나절로 만드는 길이다.

다른 무엇을 묻기 전에 시스템 버스에 어떤 서비스가 있는지 묻고, 이어서 설치된 조각들이 같은 버전에 합의하는지 확인한다. OpenVPN 3 Linux는 그 서비스들을 시스템 유닛으로 등록하므로 물어야 할 버스는 시스템 버스이고, 버전 조회에는 관리 권한이 필요하며, --user 로 만든 목록은 유닛이 결코 나타나지 않는 당신의 로그인 세션을 읽는다. 서비스는 요청에 따라 활성화되고 일부는 유휴 상태에서 종료되므로, 첫 요청 전에 없는 서비스는 그저 아직 아무것도 물어본 적이 없을 뿐이다. 아래 세 명령은 VPN 세션을 열지 않고 존재, 버전, 유닛 상태를 답한다.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

각 목록이 실제로 무엇을 증명하는가

클라이언트 자신의 화면이 가장 값싼 증거이고, 그중 어느 것도 보이는 것보다 적게 증명한다. 구성 목록의 프로필은 프로필이 가져와졌다는 것만 보여 주고 누군가 그것으로 연결해도 되는지는 말하지 않는다. 세션 목록의 세션은 세션 객체가 존재한다는 것만 보여 주고 원격 인증이 끝났는지는 말하지 않는다.

openvpn3 configs-list
openvpn3 sessions-list

그 출력의 객체 경로는 파일이 아니라 버스에서 관리되는 객체를 가리키므로 편집할 수 없고, 앞서 적어 둔 경로는 그 세션이 끊기는 순간 낡는다. 메모에서 하나를 다시 쓰면 VPN과 아무 관계 없는 "no such object" 오류가 생긴다. 아래 단계표는 연결의 각 단계가 무엇을 세우고 무엇을 열어 두는지 나눈다. 되돌리기 판단이 기대는 것이 바로 그 구분이다. 당신의 증거에 맞는 줄을 읽고, 이어서 오류 문장을 다시 읽어라.

연결 호출은 터널이 존재하기 전에 돌아온다

연결 호출은 지켜볼 세션을 건네고 돌아온다. 그래서 겉보기에 성공한 호출 뒤에 침묵이 이어지는 것은 모순이 아니라 정상적인 중간 상태다. 프런트엔드는 여전히 상태 변화를 따라가고 어떤 상호작용 요청에도 답해야 한다. 자격 증명이 필요한데 응답이 오지 않는 프로필은 멈춘 백엔드와 똑같이 보이는 상태에서 기다린다. 그 대기 상태는 알아볼 가치가 있다. 사람들을 잘못된 구성 요소로 보내기 때문이다.

시도가 도는 동안 그 프로필에 대해 세션 목록과 프런트엔드 자신의 로그를 지켜보라. 초기 상태를 결코 벗어나지 않는 세션이 멈춘 구성 요소를 지목하고, 로그는 보통 첫 몇 줄에서 그것을 지목한다. 프로필 이름을 손에 두어라. 로그 명령은 세션 경로가 아니라 프로필을 받는다. 이것도 경로를 재사용하는 대신 목록을 다시 읽을 이유의 하나다.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

세션을 열지 않고 한 구성 요소의 로그 읽기

프런트엔드가 쓸모 있는 것을 보고하지 않을 때는 새 연결을 시작하는 대신 실패를 기록한 구성 요소로 가라. systemd-journald 로거를 설정해 두면 관리자의 범위가 정해진 저널 보기가 버스 정책을 건드리지 않고 세션도 열지 않은 채 한 구성 요소의 사건을 읽는다. 이것은 중요하다. 측정하는 시스템을 바꾸는 진단은 거의 아무것도 증명하지 못하기 때문이다. syslog 태그가 아니라 유닛으로 걸러라. 개별 서비스 유닛은 공통 식별자를 보장하지 않으므로 태그 조회가 빈 페이지를 돌려줄 수 있다. 유닛 자신은 실패를 기록했는데도 그렇다.

누군가에게 도움을 청하기 전에 네 칸을 적어라. 오류의 전체 이름, 관련된 서비스와 객체, 시각 표시, 그리고 설치된 패키지 버전이다. 유지보수하는 사람이 필요한 것이 이것이며, 어느 것도 프로필이나 자격 증명을 티켓에 붙이기를 요구하지 않는다. 오류를 잠재우려고 버스 접근 정책을 넓히는 것은 진단이 아니다. 당신 대신 구성 요소를 지목하던 경계를 지워 버린다. 프로필의 사적인 내용이 공유 보고에서 빠지는 것은 자격 증명과 같은 이유다.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

거부한 경계를 고치기

지도의 각 줄에는 저마다의 수정이 있고 줄들은 서로를 대신하지 않는다. 프로필에서 거부된 작업은 정책과 소유의 문제이고, 활성화되지 않는 백엔드는 서비스와 패키징의 문제다. 인증을 거부하는 서버는 둘 다 아니므로 비밀번호를 반복해서 바꿔도 로컬 활성화 문제는 고쳐지지 않는다. 잘못된 수정을 고르는 것이 정책 문제를 재설치로 바꾸는 길이다.

패키지를 바꾼 뒤에는 낡은 바이너리 하나를 제자리에 복사하는 대신 일관되고 지원되는 설치를 확인하라. 통제된 되돌리기는 확인된 회귀에 대한 정당한 답이며, 패키지가 호환으로 남고 지원되는 유지보수로 돌아갈 길이 있다는 조건이 붙는다. 그 길은 서비스가 시작을 멈추기 전에 마련하라. 그 뒤가 아니라.

다른 플랫폼은 같은 핵심 VPN 라이브러리를 공유해도 Linux의 버스 서비스는 공유하지 않는다. 그래서 Windows에서 비슷해 보이는 실패는 이 실패에 대해 아무것도 말하지 않는다. D-Bus 개요는 구성과 세션을 위해 노출되는 객체 경로를 문서화하며, 이 진단이 기대는 것이 바로 그 부분이다. 한 번 읽어 두면 다음 오류는 이미 구성 요소를 달고 온다.