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

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 가이드 어떤 아이디어?

답변

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

월요일 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로 변경하는 것에 만족한다고 표시 했으므로 문제가 끝났습니다.

답변

이것은 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 키 협상이 실패했습니다 (네트워크 연결 확인)

답변

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

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

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

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

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

    OpenVPN 이 연결 을 시도하기 전에 자격 증명을 요청하기 때문에 로그인 프롬프트 가 표시되는 것은 아닙니다 .

  • VPN 서버가 올바른 인터페이스에서 수신 대기하는지 확인하십시오.

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

답변

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

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

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

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

답변

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 서버와 통신하고 있다는 잘못된 의미로 당신을 유혹 할 수 있습니다.

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

답변

앞서 언급 한 솔루션 중 어느 것도 효과가 없었습니다. 필자의 경우 클라이언트 로그에 동일한 오류가 표시되었지만 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

답변

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

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

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