TLS 오류 후 OpenVPN이 계속 재시도합니다: 멈추는 방법

클라이언트가 연결하고 TLS 협상 중 실패하며 기다린 뒤 같은 결과로 같은 서버를 다시 시도합니다. 실패한 프로세스를 다시 시작하는 감독자 아래에서 그 시도들은 저널 속 끝없는 루프가 되고, 첫 진단 줄은 손이 닿지 않는 곳으로 밀려납니다. OpenVPN에는 그 협상 실패를 또 한 번의 재시도 대신 눈에 보이는 종료로 바꾸는 옵션이 있습니다. 이것은 진단과 감독을 위한 설정이지 수리가 아니므로, 프로세스가 실제로 내려가 있게 허용하는 정책과 함께 쓰세요.

첫 오류를 감추는 순환

보이는 것은 한 번의 실패가 아니라 반복되는 블록입니다: 연결 시도, TLS 오류, 멈춤, 그리고 같은 순서. 반복될 때마다 원래 줄은 저널에서 더 위로 밀립니다. 유닛이 실패 시 다시 시작하면 아무도 원인을 읽지 않은 채 순환이 몇 시간씩 이어질 수 있습니다. 증상은 루프이지만 근본 결함은 하나의 협상 문제입니다.

대화형 세션은 일시적 실패가 다음 시도에서 사라질 수 있기 때문에 이를 견딥니다. 자동 연결은 같은 낙관을 허용할 수 없습니다: 사람이나 모니터가 상태를 볼 수 있도록 프로세스가 멈춰야 합니다.

무엇이든 바꾸기 전에 한 번의 완전한 순환을 기록하세요. 원격 주소, 오류에 나온 TLS 단계, 프로세스가 아예 종료되는지를 적어 두세요.

루프 뒤의 재시도 구조

재시도가 기본인 이유는 서로 무관한 여러 타임아웃이 같은 구조를 공유하기 때문입니다. connect-retry은 연결 시도 사이의 간격을 정하고, connect-retry-max은 각 원격 항목을 얼마나 자주 시도할지 제한할 수 있으며, resolv-retry는 반복되는 이름 조회를 관리합니다. TLS 협상 실패는 전송 이벤트로 그 구조에 도달하므로 클라이언트는 보고하는 대신 다음 시도를 예약합니다. 기본값은 불안정한 회선에는 도움이 되고 치유될 수 없는 결함에는 해롭습니다.

--tls-exit 옵션은 협상 경우만 바꿉니다. 매뉴얼은 이를 TLS 협상 실패 시 종료로 설명하며, 모든 오류에서 종료하는 것보다 좁습니다. 타임아웃, 확인자 실패, 인증 거부는 각자의 동작을 유지합니다.

TLS 실패 시 클라이언트가 종료하게 만들기

클라이언트가 실제로 불러오는 프로필에 tls-exit를 넣거나 시작할 때 --tls-exit를 주고, 한 번 포그라운드에서 실행하세요. 감독자가 반응하는 것이 상태이므로 종료 상태와 마지막 로그 줄을 함께 읽으세요. 협상 실패 후 영이 아닌 종료가 의도된 결과입니다. 프로세스가 끝나지 않고 계속 재시도한다면, 그 옵션은 클라이언트가 실제로 불러오는 프로필에 없습니다.

그 종료가 보일지는 감독자가 정합니다. Restart=always 또는 Restart=on-failure이 있는 systemd 유닛은 클라이언트를 다시 시작하므로 루프가 계속되고 옵션은 아무것도 하지 않는 것처럼 보입니다. 클라이언트를 탓하기 전에 정책을 확인하세요:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no는 프로세스가 내려가 있게 하고, Restart=on-failure는 영이 아닌 상태 뒤에도 다시 시작합니다. 실패가 보이되 서비스는 무관한 충돌에서 회복되길 원한다면 Restart=on-failure을 설정하고 재시작 폭풍을 멈추기 위해 StartLimitBurst와 StartLimitIntervalSec를 사용하세요. 그다음 마지막 종료 코드를 확인하려고 유닛 상태를 읽으세요: systemctl status가 이를 보고하고, 저널은 재시작들 위에 첫 오류를 남깁니다.

결정을 유닛이나 프로필 메모에 적으세요. TLS 실패 시 종료하는 프로필은 이유가 기록되지 않으면 다음 사람에게 사고처럼 보입니다. 어떤 실패가 프로세스를 멈춰야 하고 어떤 것을 재시도해야 하는지 밝히세요.

일회용 엔드포인트로 증명하기

동작을 믿기 전에 보려면 프로필을 복사하고 그 사본을 TCP 연결은 받지만 OpenVPN을 말하지 않는 엔드포인트로 향하게 하세요. 응답한 뒤 조용해지는 리스너로 충분합니다. tls-exit가 있으면 핸드셰이크가 실패할 때 클라이언트가 끝나야 하고, 없으면 같은 프로필이 계속 순환해야 합니다. 사본을 쓰고, 작동 중인 프로필은 절대 쓰지 마세요.

두 실행은 각각 얼마나 오래 갔는지가 아니라 종료 상태와 첫 오류 줄로 비교하세요. 상태는 옵션이 발동했는지, 첫 줄은 어느 단계가 실패했는지 알려줍니다.

끝나면 테스트 프로필을 제거하세요. 일부러 잘못된 엔드포인트가 있는 사본은 나중에 디렉터리의 모든 프로필을 시작하는 사람에게 함정입니다.

이 옵션이 결코 닿지 않는 단계

인증 거부는 더 뒤의 단계입니다. 서버가 계정을 평가해 거부하면 TLS는 이미 협상되었으므로 tls-exit는 발동하지 않습니다. 다음으로 볼 곳은 인증 재시도 설정이고, 서버의 이유가 클라이언트의 마지막 줄보다 중요합니다. 잘못된 암호와 없는 인증서는 클라이언트 쪽에서 비슷한 메시지를 만들 수 있습니다.

빠진 경로, 잘못된 확인자, 닿을 수 없는 게이트웨이도 이 옵션 밖입니다: 협상 실패가 아니기 때문입니다. 조용한 패킷 손실은 가장 분명하지 않은 경우입니다: 교환이 얼마나 진행되었는지에 따라 클라이언트는 협상 실패를 보고하거나 그냥 시간 초과될 수 있습니다.

메모에 이 구분을 남기세요. 이 설정은 수리가 아니라 진단과 감독을 위한 것이므로 암호 불일치, 인증서 문제, 잘못된 포트를 고치지 않습니다. 먼저 실패한 협상의 원인을 고치고, 그다음 즉시 종료가 배포에 여전히 맞는지 판단하세요.