OpenVPN 문제-60 초 내에 TLS 키 협상이 실패했습니다

14

Windows 2012 서버에서 OpenVPN (버전 2.3.10) 서버를 구성하고 있지만 작동시킬 수 없습니다.

서버는 라우터 뒤에 있으며 1194 포트를 열고이 포트의 트래픽을 서버로 전달하는 규칙을 만들었습니다.

클라이언트에서 연결을 시도 할 때 서버에 표시되는 로그는 다음과 같습니다.

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

여기서 XX.XX.XX.XX는 클라이언트의 IP입니다. 따라서 클라이언트가 적어도 서버에 도착할 수 있으므로 라우팅 또는 방화벽 문제가 없음을 이해합니다.

나는 여기에 제공된 설명을 따랐다. 쉬운 Windows 가이드 어떤 아이디어?

openvpn

— vmasanas
소스

1

두 로트가 XX.XX.XX.XX동일한 주소 를 나타내는 것으로 가정하면 ( 그런 것을 난독 화하지 말고 고려 하십시오 ) 소스 포트 번호 (57804, 55938)의 변경에 관심이 있습니다. 그것은 나에게 신뢰할 수없는 NAT가 있다는 것을 제안합니다. 이는 UDP의 경우가 가장 흔합니다. UDP 또는 TCP 전송을 사용하고 있으며 전자의 경우 후자를 시도하여 문제가 해결되는지 확인할 수 있습니까?

— MadHatter

적어도 클라이언트가 도착할 수 있다는 것을 서버 콘솔에서 확인하십시오. 따라서 NAT가 문제가 아니라고 가정했습니다. 내가 틀렸어?

— vmasanas

1

모든 NAT가 동일하게 생성되는 것은 아닙니다. 일부는 특히 UDP의 수명이 짧은 상태 테이블 항목을 가지고 있으며 OpenVPN은 소스 포트의 변경 사항에 적합하지 않습니다. 내가 요청한 질문에 대답하고 적절한 경우 제안한 변경을 시도하십시오.

— MadHatter

나는 여기에 경험이 없으므로 UDP 또는 TCP를 사용하고 있는지 확인하는 방법을 알려 줄 수 있습니까?

— vmasanas

글쎄, 당신은 시도 man openvpn하고 프로토콜을 제어하는 것을 찾을 수 있습니다. 테스트를하기로 결정한 경우 클라이언트와 서버 모두에서 변경하는 것을 잊지 마십시오.

— MadHatter

21

흥미로운 점은 포트 번호가 중간 스트림에서 어떻게 변경되는지입니다.

월요일 3 월 21 일 11:11:47 2016 XX.XX.XX.XX : 57804 TLS : [AF_INET] XX.XX.XX.XX : 57804의 초기 패킷 : sid = fdf7a7ac 0264c7f3

월요일 3 월 21 일 11:12:38 2016 XX.XX.XX.XX : 55938 TLS : [AF_INET] XX.XX.XX.XX : 55938, sid = 1f242a3f e454a525의 초기 패킷

이로 인해 클라이언트와 서버 사이에 매우 짧은 상태 테이블 항목이있는 장치 인 NAT 장치가 잘못 작동하여 클라이언트의 설정된 스트림에 적용되는 소스 포트 번호가 변경되어 서버가 하나의 연속적인 통신이 아닌 두 개의 단기 통신이 진행되고 있다고 생각하십시오.

이러한 장치는 일반적으로 UDP로만 수행하므로 UDP를 사용하고 있는지 확인하고 대신 TCP를 시도하는 것이 좋습니다. 이것으로 문제가 해결되었습니다. 다음 단계는 오작동하는 NAT 장치를 식별하고이를 클럽 해머로 치고 모든 UDP 통신이 일시적이라고 가정하는 실수를하지 않는 장치로 교체하는 것입니다. 그러나 해결 방법으로 TCP로 변경하는 것에 만족한다고 표시 했으므로 문제가 끝났습니다.

— 매드 해 터
소스

2

독수리 눈에 +1!

— Diamond

@ bangal 왜, 감사합니다! 이 사업에서 많은 악마가 세부 사항에 있습니다.

— MadHatter

네, 알아요.하지만보고 싶을 때만 봤습니다. 방화벽 문제인지 확인했습니다.

— Diamond

글쎄, 네 말이 맞아 그리고 자신을 두들겨하지 마십시오, 당신은 다음에 더 열심히 보일 것입니다!

— MadHatter

TCP 대신 UDP를 사용하면 어떤 이점이 있습니까? 내가 괜찮은 단점이 없다면 TCP는 지금 나를 위해 일하고있다.

— vmasanas

3

이것은 Openvpn 설정에서 가장 일반적인 오류 중 하나이며 FAQ 항목이 있습니다. 나는 이것을 이것을 인용 할 것이다 :

TLS 오류 : 60 초 내에 TLS 키 협상이 실패했습니다 (네트워크 연결 확인)

OpenVPN 설정에서 가장 일반적인 문제 중 하나는 연결 양쪽에있는 두 개의 OpenVPN 데몬이 서로 TCP 또는 UDP 연결을 설정할 수 없다는 것입니다.

이것은 거의 다음과 같은 결과입니다.

서버 네트워크의 경계 방화벽이 들어오는 OpenVPN 패킷을 필터링하고 있습니다 (기본적으로 OpenVPN은 UDP 또는 TCP 포트 번호 1194를 사용합니다).

OpenVPN 서버 시스템 자체에서 실행되는 소프트웨어 방화벽은 포트 1194에서 들어오는 연결을 필터링하고 있습니다. 달리 구성하지 않는 한 많은 OS가 기본적으로 들어오는 연결을 차단합니다.

서버 네트워크의 NAT 게이트웨이에는 OpenVPN 서버 시스템의 내부 주소에 대한 TCP / UDP 1194에 대한 포트 전달 규칙이 없습니다.

OpenVPN 클라이언트 구성의 구성 파일에 올바른 서버 주소가 없습니다. 클라이언트 구성 파일의 원격 지시문은 서버 자체 또는 서버 네트워크 게이트웨이의 공용 IP 주소를 가리켜 야합니다.

또 다른 가능한 원인은 Windows 방화벽이 openvpn.exe 바이너리에 대한 액세스를 차단하고 있기 때문입니다. OpenVPN이 작동하려면 화이트리스트에 추가 ( "예외"목록에 추가)해야 할 수도 있습니다.

이 중 하나라도 귀하의 경우에도 동일한 문제를 일으킬 가능성이 큽니다. 목록을 하나씩 살펴보고 해결하십시오.

참조 : TLS 오류 : 60 초 내에 TLS 키 협상이 실패했습니다 (네트워크 연결 확인)

— 다이아몬드
소스

나는이 점들을 겪었지만 뭔가 빠졌는지 확실하지 않습니다 : 1. 클라이언트와 서버에서 방화벽이 해제 된 순간 2. 동일, 3. 라우터가 서버에 전달 규칙을 가지고 있으며 서버 콘솔에 나타나는 트래픽, 4.client에는 올바른 IP 주소가 있습니다. 5. 방화벽이 없습니다.

— vmasanas

글쎄, 솔직히 나는 지금 다른 어떤 것도 생각할 수 없습니다. 확실히, Windows 서버의 네트워크 구성은 어떻습니까? 우연히 여러 게이트웨이가 있습니까? 기본 게이트웨이가 라우터를 가리 킵니까? 그렇다면 MadHatter가 제안한대로 tcp로 테스트 할 수 있습니다.

— Diamond

사람이 손을 빌려 같은 느낌, 내가 (또 다른) TLS 핸드 셰이크 실패 질문 여기에 게시했습니다 serverfault.com/questions/867599/...

— 올라 Tuvesson

주의해야 할 또 다른 사항 은 두 호스트 간의 대기 시간이 길다는 것 입니다. 나는 방금 이것에 광범위하게 머리를 긁고 있었고, 어떤 신이 든 이유로 인해 한 방향 (클라이언트에서 서버로)으로 6000ms 이상의 핑 왕복을 얻었지만 다른 방법은 아닙니다. 이로 인해 키 협상에 60 초 이상이 소요되었습니다. ISP에서 제공 한 라우터를 재부팅하면 문제가 해결되었습니다. 아마도 드문 경우이지만 누군가를 도울 수 있기를 바랍니다.

— s.co.tt

3

이와 같은 TLS 키 협상 시간 초과가 발생했습니다. 그러나 제 경우에는 원격 링크가 로컬 IP 주소라는 것을 깨달았습니다.

pfSense 방화벽의 VPN이 실수로 WAN 인터페이스 대신 LAN 인터페이스에 배치되었으므로 내 보낸 구성이 방화벽의 LAN IP 주소에 연결하도록 설정되었습니다. 다른 LAN.

나는 이것의 주요 테이크 아웃이 다음과 같다고 생각한다.

주요 협상 시간 초과가 발생한다고해서 어떤 것도 연결할 수 있다는 의미는 아닙니다.

따라서이 단계에서 실제로 올바른 위치에 연결하고 있는지 확인해야하며 연결을 차단하는 방화벽 규칙 등이 없습니다. 특히 구성이 자동으로 생성 된 경우.

OpenVPN 이 연결 을 시도하기 전에 자격 증명을 요청하기 때문에 로그인 프롬프트 가 표시되는 것은 아닙니다 .
VPN 서버가 올바른 인터페이스에서 수신 대기하는지 확인하십시오.

(물론 이것은 방화벽 규칙, 잘못된 포트 번호 입력, TCP와 UDP의 혼합 등과 같이 발생할 수있는 여러 서버 측 잘못된 구성 중 하나입니다.)

— mwfearnley
소스

1

나는 같은 오류가 있었고 아무런 도움도받지 못했습니다 .IP, 포트, 방화벽, 모든 것이 괜찮은 것처럼 보였습니다. 2 시간 동안 미쳤다.

해결책은 클라이언트 구성에서 프로토콜을 UDP에서 TCP로 변경하는 것입니다 (분명 오래 전에 의도적으로 UDP를 비활성화했습니다).

희망이 누군가에게 도움이되기를 바랍니다 :)

LE : 이것은 내 문제를 해결했지만 아래 의견에 따라 최선의 방법은 아닙니다. TCP 대신 UDP를 사용해야합니다. 클라이언트와 서버 구성간에 다른 설정이 있었기 때문에 도움이되었습니다.

— 보쉬
소스

TCP 내부에 TCP를 캡슐화하면 두 TCP 스택이 서로 경쟁하려고 시도하기 때문에 성능 문제가 발생할 가능성이 매우 높습니다.

— EEAA 2016 년

실제로, 그것은 쓰레기처럼 작동합니다. 나는 당신이 말한 것을 이해하지 못하지만 성능은 매우 좋지 않습니다. 그런 다음 UDP로 전환해야합니까?

— 보쉬

2

예. UDP는 정당한 이유로 VPN 구현의 표준입니다. TCP에는 오류 수정 기능이 있습니다. 손실 된 패킷 등을 다시 전송하는 기능입니다. TCP 내부에서 TCP를 캡슐화하고 패킷 손실이 발생하면 TCP 스택 ( "내부"트래픽 및 암호화 된 OpenVPN 트래픽)이 모두 발생합니다. 손실 된 패킷을 확인하십시오. TCP를 UDP로 캡슐화 할 때는 문제가되지 않으며 내부 트래픽 만 다시 시도합니다.

— EEAA 2016 년

힌트와 설명에 감사드립니다. 나는 UDP로 전환하고 연결을 주시합니다. 또한 스택에 대해 좀 더 읽어야합니다.

— bosch

TCP를 통한 TCP 나쁜 생각입니다 이유를 설명하는 유용한 페이지 : sites.inka.de/bigred/devel/tcp-tcp.html

— mwfearnley

1

OpenVPN 서버에 성공적으로 연결하지 않고도 TLS 키 협상 오류가 발생 하거나 전혀 연결되지 않을 수 있습니다!

아무것도 듣지 않는 포트에서 localhost에 연결하도록 VPN 구성을 수정했습니다.

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] 2018 년 4 월 26 일에 구축
Windows 버전 6.2 (Windows 8 이상) 64 비트
라이브러리 버전 : OpenSSL 1.1.0h 2018 년 3 월 27 일, LZO 2.10
TCP / UDP : 최근에 사용한 원격 주소 유지 : [AF_INET] 127.0.0.1:12345
UDP 링크 로컬 (바운드) : [AF_INET] [undef] : 0
UDP 링크 원격 : [AF_INET] 127.0.0.1:12345 
TLS 오류 : 60 초 내에 TLS 키 협상이 실패했습니다 (네트워크 연결 확인)
TLS 오류 : TLS 핸드 셰이크 실패
SIGUSR1 [soft, tls-error] 수신, 프로세스 재시작
...

이 오류는 VPN 서버와 통신하고 있다는 잘못된 의미로 당신을 유혹 할 수 있습니다.

먼저 자격 증명을 입력하라는 메시지가 표시 될 수도 있지만 실제로 컴퓨터 외부에서는 자격 증명을 요구하지 않습니다.

— mwfearnley
소스

1

앞서 언급 한 솔루션 중 어느 것도 효과가 없었습니다. 필자의 경우 클라이언트 로그에 동일한 오류가 표시되었지만 TLS Error: TLS key negotiation failed to occur within 60 seconds서버 로그에 표시되었습니다 VERIFY ERROR: depth=0, error=CRL has expired.

서버에서 다음 단계로 연결 문제가 해결되었습니다.

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

— mpprdev
소스

0

AWS에서 OpenVPN이 퍼블릭 IP가있는 서버에 설치되었지만 프라이빗 서브넷에있는 인스턴스 (예 : 인터넷 게이트웨이에 대한 경로가없는 서브넷)에 설치된이 오류가 발생했습니다.

퍼블릭 서브넷 내의 서버에 OpenVPN을 배포 한 후에는 모두 잘 작동했습니다. :)

AWS의 퍼블릭 / 프라이빗 서브넷 : https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

— 졸탄
소스

0

나는 또한 TLS key negotiation failed to occur within 60 seconds문제를 만났다.

공식 제안에서 Diamant 게시물로서 네트워크 연결에 문제가 있어야합니다. 그러나 방화벽이나 NAT가 문제를 일으키지 않습니다.

필자의 경우 먼저로 연결을 확인했습니다 nc -uvz xxx.xxx.xxx.xxx 1194. 링크는 정상입니다.

또한 동일한 LAN 내의 다른 여러 VPN 클라이언트가 정상적으로 작동합니다.

어딘가에서 udp 연결에 응답 또는 포트 전달에 문제가 있음을 알았습니다.

따라서 "10.8.0.100"에서 "10.8.0.50"과 같이 가장 큰 IP에서 정지 클라이언트까지 실행중인 vpn 클라이언트를 중지합니다.

그런 다음 중지 된 VPN 클라이언트를 반대로 시작하십시오.

쾅! 모든 VPN 클라이언트는 적절하게 작동합니다.

결론적 TLS key negotiation failed to occur within 60 seconds으로 LAN 내의 여러 VPN 클라이언트가 잘못된 순서로 시작될 수 있습니다.

— samson.wang
소스

1

이것이 원래 질문의 문제와 어떤 관련이 있는지 확실하지 않습니다.

— Ward-Monica Monica 복원

0

한 가지 가능한 이유는 서버에 클라이언트에서 지원하는 TLS보다 최신 버전의 TLS가 필요한 경우입니다. 즉 1.2 대 1.0.

명백한 시도는 OpenVPN 클라이언트를 업데이트하거나 TLS 1.0을 수락하도록 서버 측을 수정하는 것입니다.

— ozk
소스