실제로 어떤 OpenVPN 인스턴스가 당신의 PiVPN 프로필을 사용하고 있는가?

PiVPN은 서버 설정과 클라이언트 프로필을 쓰고 종료할 뿐, 트래픽을 실제로 나르는 프로세스가 되지는 않습니다. 그래서 실패한 핸드셰이크, 잘못된 엔드포인트로 접속하는 클라이언트, 재부팅 후 잘못 돌아오는 서비스는 설치 프로그램의 메뉴로는 설명할 수 없습니다. 그 증상은 지금 실행 중인 OpenVPN 데몬, 그 데몬이 실제로 읽어 들인 설정, 그리고 지정된 로그에 속합니다. 읽기 전용 명령 네 개면 대개 정리되고, 그중 어느 것도 인증서나 키를 바꾸지 않습니다.

도우미와 데몬은 서로 다른 객체입니다

혼란은 간단히 설명할 수 있습니다: 한 디렉터리에 도우미가 만든 파일, 데몬이 읽는 파일, 때로는 둘 다의 오래된 사본이 함께 있습니다. 도우미는 프로비저닝 스크립트입니다. 패키지를 설치하고 유닛 파일을 쓰고 클라이언트 프로필을 출력한 뒤 일을 마칩니다. 남는 것은 서비스 관리자의 항목과 명령줄 하나입니다.

systemd 호스트에서는 디렉터리 목록이 아니라 활성 유닛에서 시작하세요. 이름은 패키징에 따라 다른데, Debian과 Raspberry Pi OS 이미지는 보통 예를 들어 openvpn-server@server 같은 템플릿 인스턴스를 제공하며, 오래된 설치에서는 openvpn@server 를 씁니다. 파일 이름에서 추측하지 말고 관리자에게 어느 것이 실행 중인지 물어보세요.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

그 출력에서 ExecStart= 를 읽으세요. 실행 파일과 관리자가 실제로 시작하는 옵션, 그리고 모든 --config 경로를 알려주며, 근처에 있지만 어떤 명령도 참조하지 않는 설정 파일은 실행 중인 터널의 일부가 아닙니다.

데몬이 해석한 설정 체인을 따라가세요

OpenVPN 설정을 찾아 디렉터리를 스캔하지 않습니다. --config 로 전달된 파일을 읽고, 그 안의 모든 config 지시문을 따라간 다음 명령줄 옵션을 적용합니다. 2.6 설명서 가 그 순서를 설명하며, 두 파일이 포트, 장치, 암호에 대해 다를 때 중요합니다.

먼저 실제 호출을 덤프하고, 그다음 신원과 도달성을 결정하는 지시문을 보세요. 두 명령 모두 읽기 전용이고 실행 중인 서버에서 안전하지만, 두 번째는 공개 티켓에 넣고 싶지 않은 경로를 출력합니다.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

홈 디렉터리의 .ovpn 파일은 클라이언트 산출물입니다. 서버 데몬은 절대 읽지 않으므로, 서버 측 핸드셰이크 실패를 고치려고 그 파일을 편집해도 아무 소용이 없습니다.

인클루드가 또 다른 함정입니다. config 줄은 두 번째 파일을 끌어오고 그 옵션은 그 지점에서 처리되므로, 나중의 단일 값 지시문이 기본 파일이 말하는 것처럼 보이는 내용을 덮어쓸 수 있습니다. 보이는 파일이 맞아 보이는데 데몬이 여전히 다르게 동작한다면, 무언가를 바꾸기 전에 포함된 파일을 읽으세요.

로그를 기억나는 오류가 아니라 프로세스에 맞추세요

로그 목적지는 두 가지가 흔하고, 그중 하나만 journal입니다. log-append 가 설정되면 데몬은 그 파일에 쓰고 journal은 시작 줄 외에는 거의 남기지 않습니다. 그것이 없으면 journalctl 가 이벤트 원천입니다.

journalctl -u openvpn-server@server -n 80 --no-pager

연결 시도 하나를 시간 창 하나와 연관 지으세요. 클라이언트의 엔드포인트를 기록하고, 같은 초의 서버 이벤트를 읽으세요. 인증서 교환에 이르지 못하는 TLS 핸드셰이크는 도달성이나 프로토콜 불일치를 가리키고, 인증 거부는 터널 매개변수가 이미 합의된 뒤에 옵니다.

오래된 로그 항목은 오 분 전에 내려받은 프로필에 대해 아무것도 증명하지 않습니다. 클라이언트 파일을 다시 만들고, 한 번 연결하고, 그 시도 중에 나타난 줄만 읽으세요.

마지막 일반적인 실패가 아니라 첫 번째 구체적인 실패를 기록하세요. 바인드 오류, 응답 없는 외부 교환, 인증서 거부, 계정 거부는 각각 다른 계층으로 보내며, 끝의 타임아웃은 그 위의 유용한 이벤트를 자주 가립니다.

터널 재구축은 진단 단계가 아닙니다

유혹적인 지름길은 더 단순한 두 번째 터널을 세우는 것입니다: 정적 키, 인증서 없음, 추가 인증 없음. 그것은 자주 연결되며, 두 호스트가 서로 UDP나 TCP를 통과시킬 수 있다는 것만 증명합니다. 인증서로 인증된 배포가 왜 실패하는지는 말하지 않고, 유지하라는 보안 모델을 조용히 대체합니다.

같은 말이 tls-auth 또는 tls-crypt 를 끄고, verify-x509-name 를 느슨하게 하거나, 초록 상태를 얻으려고 두 번째 요소를 버리는 경우에도 해당됩니다. 검증을 제거했기 때문에 연결되는 터널은 다른 시스템이지 고쳐진 시스템이 아닙니다.

로그가 지목한 계층에서 한 가지 제한된 변경을 하고, 같은 유닛을 재시작하고, 그 한 번의 연결 시도를 반복하세요. 그러면 비교가 정직하게 유지되고 되돌릴 수 있는 변경이 남습니다.

다음 사람에게 넘길 것

아직 손에 있을 때 네 가지 사실을 적으세요: OpenVPN 버전은 openvpn --version 출력에서, 활성 유닛, 인클루드를 포함한 설정 체인, 그리고 한 번의 시도를 포괄하는 로그 창입니다. 그 네 가지가 모호한 불만을 재현 가능한 사례로 바꿉니다.

공유하기 전에 민감한 데이터를 가리세요. 개인 키, auth-user-pass 파일, 정적 키 자료, 전체 클라이언트 번들은 티켓에 속하지 않으며, 옵션 이름과 체인의 모양이 보통 두 번째 눈에는 충분합니다.

체인이 온전하고 로그가 여전히 네트워크를 가리킨다면, 다음 단계는 클라이언트와 서버 사이의 경로 이지 또 다른 설치가 아닙니다. 그것이 도우미가 한 번도 가져본 적 없는 이야기의 일부입니다.