첫 순간에 죽는 VPN은 연결된 뒤 실패하는 VPN과 다른 존재이며, 흔한 실수는 둘을 같은 것으로 취급하는 것입니다. 여기에는 핸드셰이크도, 인증서 교환도, 살펴볼 라우트도 없습니다. 저널의 한 줄이 서로 무관한 여러 수리 중 어느 것이 해당하는지 결정하며, 그 줄을 건너뛰면 한 번도 읽히지 않은 설정을 고치느라 반나절을 버립니다. 먼저 그 줄을 읽으세요.

읽기 전용 명령 세 개면 거기에 닿습니다: 먼저 journalctl -u openvpn@server -b --no-pager, 다음으로 systemctl status openvpn@server, 그리고 UDP 리스너와 그 소유자를 위한 ss -lunp입니다.

첫 줄이 분기를 고릅니다

포트 충돌과 바이너리 부재는 둘 다 찰나에 시작을 죽이고, 서로 다른 첫 줄을 남깁니다. 주소가 이미 사용 중이라는 메시지는 포트를 지목하고, 실행 파일이 없으면 더 이상 존재하지 않는 경로를 지목하며, 조건 실패나 설정 파일 부재는 그 파일을 지목합니다. 이 셋은 서로 다른 수리로 이어지고, 어느 것도 클라이언트 재설치로 나아지지 않습니다. 다른 무엇을 실행하기 전에 첫 실패를 메모에 복사하세요.

원래 줄을 감추는 재시도 루프를 주의하세요. 재시작 정책이 있는 유닛은 첫 실패를 십여 개의 동일한 실패 밑에 묻을 수 있으므로, 유닛으로 걸러 위에서부터 읽은 journalctl -b이 꼬리보다 낫습니다.

누가 또 1194 포트를 잡고 있는가

범인은 보통 누군가 일부러 설정한 두 번째 서버가 아닙니다. 다른 터미널에서 아직 살아 있는 손으로 띄운 클라이언트, 같은 포트를 골라 버린 두 번째 프로필, 또는 자체 터널이 1194를 잡고 있는 벤더 번들을 예상하세요. 소켓 소유자는 ss -lunp에 나타나니, 그 PID를 systemctl status에 넘기면 유닛이 책임이 있는지 알 수 있습니다. 신호가 아니라 그 자체의 제어 경로로 내리세요.

유닛이 관리하는 프로세스에 보내는 신호는 보통 재시작을 유발하고, 같은 실패가 몇 순간 뒤 새 문제처럼 다시 나타납니다. 유닛에는 systemctl stop을, 벤더 설치에는 번들 자체의 서비스 명령을, 신호는 그 셸에서 직접 띄운 것에만 쓰세요.

제거 후 남은 유닛

제거는 바이너리를 지우지만, 보통 /etc/systemd/system 아래에 있는 손으로 쓴 유닛 파일은 살아남습니다. 그러면 Systemd가 더 이상 존재하지 않는 경로를 가리키는 유닛을 다시 시도하고, 메시지는 어제의 제거가 아니라 그 없는 파일에 관한 것입니다. systemctl status은 유닛의 프래그먼트 경로를 위쪽에 보여 주므로, 무엇이든 지우기 전에 dpkg -S으로 확인하세요. 고아가 사라지면 systemctl daemon-reload과 systemctl reset-failed이 상태를 정리하며, 그렇지 않으면 이후의 모든 상태 확인이 그 상태를 물려받습니다.

which openvpn이 /usr/local 아래의 무언가로 응답할 때, 문제의 바이너리는 apt가 아니라 벤더 설치 프로그램에서 온 것입니다. 그런 설치 프로그램은 보통 자체 리스너, 자체 부팅 항목, 자체 설정 디렉터리를 함께 가져오므로, 보이는 명령을 지워도 소켓은 점유된 채로 남습니다.

벤더가 문서화한 방식으로 제거하고, ss -lunp으로 포트가 비었는지 확인하며, 필요할 때만 배포판 클라이언트를 추가하세요.

다시 시도하기 전에 상태를 정리하세요

그것에서 결론을 내리기 전에 실패 상태를 지우세요: systemctl reset-failed은 카운터를 제거하고, 그다음 systemctl status은 유닛의 이력이 아니라 현재 상태를 보고합니다. 한 번 시작하고 그 실행 자체의 저널을 읽으세요, 기계 전체의 집계 상태가 아니라. 터널이 아무것도 나르지 않는데 active라고 보고하는 유닛은 별개의 문제이며 훨씬 흔합니다. 둘은 버그 리포트에서 뒤섞입니다, 둘 다 사용자가 VPN이 안 된다고 말하는 것으로 끝나기 때문입니다.

어느 분기를 택했는지 적어 두세요: 포트 충돌, 바이너리 부재, 설정 부재. 다음에는 더 빨리 알아볼 수 있습니다.

관련 글