☰

OpenVPN TLS 핸드셰이크가 P_Control_HARD_RESET_SERVER_V2에서 중단됨(수신되지 않음)

tag-icon • tag-icon openvpn
OpenVPN TLS 핸드셰이크가 P_Control_HARD_RESET_SERVER_V2에서 중단됨(수신되지 않음)

UDP OpenVPN 서버가 있습니다(TAP 모드에서 실행되지만 중요하지 않음). 연결이 성공적으로 시작되고 TLS-AUTH(HMAC)를 통과하지만 거기서 멈춰 있습니다. 서버 로그에 다음이 중복되어 있습니다.

Sun Jan 14 13:34:10 2018 us=104130 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:10 2018 us=104252 <CLIENT>:59975 UDPv4 WRITE [66] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=524356 <CLIENT>:59975 UDPv4 WRITE [54] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=650416 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
....

하지만 클라이언트 측에는 다음이 있습니다.

2018-01-14 13:34:56 us=989963 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:00 us=476619 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:08 us=911249 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:24 us=86742 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0

여기서 무슨 일이 일어나고 있는 걸까요? 방화벽이 이를 차단하는 것은 아니며 다른 서비스를 사용하여 이 포트를 통해 올바르게 통신할 수 있습니다(netcat 서버를 실행하면 양방향 통신이 잘 작동합니다).

답변1

openvpn 메일링 리스트의 이 대화는 나를 올바른 방향으로 이끌었습니다.

단방향 링크가 있는 것 같습니다. 클라이언트는 서버와 통신할 수 있지만 서버는 클라이언트와 통신할 수 없습니다. 그래서 일종의 차단이 있거나오해의 소지가 있는서버->클라이언트 방향으로 발생합니다.
어쩌면 클라이언트 방화벽일까요?

(강조는 내 것)

local 192.168.1.X내 해결책은 서버 구성 파일에 해당 행을 추가하는 것이었습니다 . OpenVPN 문서에 따르면:

--로컬 호스트

로컬 호스트 이름 또는 IP 주소. 지정된 경우 OpenVPN은 이 주소에만 바인딩됩니다. 지정하지 않으면 OpenVPN은 모든 인터페이스에 바인딩됩니다.

분명히 이는 네트워크 문제이지만 근본적인 문제를 해결하지 않고도 해결할 수 있는 문제입니다. 나에게 문제는 브리지 인터페이스와 탭 인터페이스를 구성하는 방법입니다. 제가 망쳤습니다. OpenVPN은 응답 패킷을 대상으로 라우팅할 수 없는 인터페이스를 통해 다시 라우팅하려고 했습니다. 따라서 바인딩할 특정 인터페이스를 지정하면 지정된 IP를 사용하여 해당 인터페이스에서만 패킷을 보낼 수 있습니다. 또한 bridge-start다중 탭 인터페이스(모든 추가 브리지는 라우팅할 수 없는 블랙홀임)가 생성되지 않도록 스크립트를 수정하여 이 문제를 해결할 수 있었습니다(더 이상 로컬 구성 플래그가 필요하지 않음) . 로컬 주소를 사용하더라도 내부 네트워크 외부/NAT를 통해 여전히 잘 작동합니다.

답변2

제 경우에는 클라이언트에는 tls-crypt가 구성되어 있지만 서버에는 구성되어 있지 않은 증상이었습니다. '패킷이 너무 짧음'으로 인해 고객이 취소했습니다. 해결책은 추가하는 것입니다.

  tls-crypt /path/to/my.tls.key

server.conf에서

관련 정보