로그의 P_CONTROL_HARD_RESET_CLIENT_V2, 오류일까?

이 줄은 몇 초마다 반복되며 모든 것의 원인처럼 보인다. control hard reset이라는 이름의 패킷이 어디에도 도달하지 못하는 클라이언트에서 온다. 이것은 오류가 아니다. 새 세션의 첫 메시지이며, 반복은 그 뒤에서 다른 무언가가 실패하고 있다는 증상이다. 라벨이 말하는 것과 그 뒤에 연결이 한 일을 분리하는 것이 진단의 전부다.

오퍼코드는 프로토콜 안의 위치를 가리킨다

OpenVPN 은 여러 종류의 패킷을 하나의 소켓 위에 다중화하며, 오퍼코드는 수신 측에 어떤 종류인지 알려 준다. hard-reset 패킷은 세션을 열고, 제어 패킷은 핸드셰이크 재료를 실으며, 확인 응답은 수신을 확인하고, 데이터 패킷은 터널의 페이로드를 싣는다. 첫 바이트를 읽으면 그 교환에서 패킷이 어디에 속하는지 알 수 있고, 업스트림 패킷 정의 가 각 계열을 명시한다.

말하는 것은 그뿐이다. 초기 클라이언트 리셋으로 표시된 패킷은 그 패킷이 관측 지점에 도달했고 상대가 세션을 시작하려 한다는 것을 증명한다. 클라이언트가 당신의 인증서를 신뢰했는지, 자격 증명이 수락되었는지, 데이터 채널이 실제로 쓸 수 있게 되었는지는 증명하지 않는다.

V2 접미사는 그 패킷 계열의 프로토콜 세대 표시이며, 제품 버전도 아니고 당신이 설치하는 설정도 아니다. 이름 어디에도 터널 재설정, 서비스 재시작, 캐시 비우기를 뜻하는 내용은 없다.

그 순간 클라이언트가 실제로 하는 일

클라이언트는 세션 식별자를 열고, 양쪽 끝은 이후 제어 트래픽을 그것에 붙인다. 제어 채널 보호가 구성되어 있으면 그 첫 패킷은 이미 HMAC을 실어 수신 측이 나머지 교환에 노력을 들일지 판단하게 한다. 검증할 수 없는 수신 측은 패킷을 조용히 버린다. 그래서 잘못된 공유 키는 클라이언트가 허공에 대고 말하는 것처럼 보인다.

사용자에게 보이는 일은 아직 아무것도 일어나지 않았다. 인증서는 검증되지 않았고, 사용자 이름은 제시되지 않았고, 터널 주소도 할당되지 않았다. 리셋은 핸드셰이크의 서문이므로 이 시점의 연결 판단은 이르다.

유휴 재연결 루프에서 흥미로운 것은 간격이다. 진행 없이 고정 주기로 재시도하는 클라이언트는 보통 더 나아가기 전에 거부되며, 이유는 패킷 이름이 아니라 상대의 로그에 있다.

리셋 뒤에 숨어 있는 진짜 실패

두 로그를 나란히 읽고 리셋이 아닌 첫 사건을 찾아라. 클라이언트에서는 인증서 검증 실패가 구체적 이유와 함께 기록된다. 만료, 이름 불일치, 알 수 없는 발급자다. 서버에서는 자격 증명 거부가 고유한 이유를 가진 인증 실패로 기록된다. 둘 다 서버가 새 시도를 반복해서 바라보는 기록보다 훨씬 구체적이다.

각 로그를 따로 읽지 말고 한 번의 시도를 타임스탬프로 맞춰라. 같은 실패가 양쪽에 다른 표현과 다른 심각도로 나타나기 때문이다. 포기한 쪽은 대개 이유를 말한다.

어느 쪽도 거부를 보고하지 않는데 교환이 계속 멈춘다면 경계는 신뢰가 아니라 도달 가능성이다. 반환 방향을 버리는 방화벽, 매핑이 만료되는 네트워크 주소 변환 장치, 더 큰 핸드셰이크 패킷을 죽이는 MTU 문제는 모두 인증 오류 없이 멈춘 교환을 만든다.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

그 검색은 그 자체로 진단은 아니지만, 프로토콜 어휘에서 실제 장애 분류로 한 걸음에 옮겨 준다.

검증을 끄는 것이 잘못된 반사인 이유

리셋이 계속 나타날 때 가장 빨라 보이는 처방은 인증서 검증을 끄거나 무언가 연결되도록 제어 채널 보호를 포기하는 것이다. 그것은 진단 가능한 실패를 진단 불가능한 실패와 맞바꾸고, 거부하도록 만들어진 상대를 받아들이는 상태로 배포를 남긴다.

대신 실제로 실패한 경계를 바꿔라. 신뢰 문제는 인증 기관과 그것을 참조하는 프로필에 속한다. 시간 문제는 시계에 속한다. 자격 증명 문제는 그것을 거부한 인증 백엔드에 속하고, 도달할 수 없는 상대는 두 호스트 사이의 경로에 속한다.

오퍼코드가 지원 대화에서 쓸모 있는 것은 한 가지다. 상대가 시도할 만큼 나아갔다는 것을 알려 준다. 그 뒤에 무슨 일이 있었는지가 알아야 할 것이며, 첫 구체적 거부를 기록한 로그에 적혀 있다. 거기서 시작하면 리셋 줄은 원인처럼 보이기를 멈추고 타임스탬프처럼 보이기 시작한다.