Problem z OpenVPN - negocjacja klucza TLS nie nastąpiła w ciągu 60 sekund

Konfiguruję serwer OpenVPN (wersja 2.3.10) na serwerze z systemem Windows 2012, ale nie mogę go uruchomić.

Serwer znajduje się za routerem, a ja otworzyłem port 1194 i utworzyłem regułę przekierowującą ruch z tego portu do serwera.

Oto dziennik, który widzę na serwerze, gdy próbuję połączyć się z klientem:

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

Gdzie XX.XX.XX.XX to adres IP klienta. Rozumiem z tego, że przynajmniej klient może dotrzeć do serwera, więc nie ma problemów z routingiem ani zaporą ogniową.

Postępowałem zgodnie z opisem zamieszczonym tutaj. Przewodnik po systemie Windows Wszelkie pomysły?

Co ciekawe, numer portu zmienia się w połowie strumienia:

Pon Mar 21 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: Początkowy pakiet z [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Pon Mar 21 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: Początkowy pakiet z [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

To sprawia, że ​​myślę, że gdzieś pomiędzy klientem a serwerem znajduje się źle działające urządzenie NAT, urządzenie z bardzo krótkimi wpisami tabeli stanów, które zmienia numer portu źródłowego, który stosuje do ustalonego strumienia klienta, powodując, że serwer myślę, że trwają dwie krótkotrwałe połączenia zamiast jednego ciągłego.

Takie urządzenia generalnie robią to tylko z UDP, więc radziłem ci potwierdzić, że używasz UDP, i zamiast tego wypróbuj TCP. Zrobiłeś to i odkryłeś, że to rozwiązuje problem. Następnym krokiem jest zidentyfikowanie źle działającego urządzenia NAT, uderzenie go młotkiem kijowym i zastąpienie go takim, który nie popełnia głównego błędu, zakładając, że cała komunikacja UDP jest efemeryczna; ale wskazałeś, że jesteś zadowolony z przejścia na TCP jako obejście, więc sprawa jest zakończona.

Jest to jeden z najczęstszych błędów podczas konfigurowania Openvpn i jest tam wpis FAQ. Zacytuję to tutaj:

Błąd TLS: negocjacja klucza TLS nie nastąpiła w ciągu 60 sekund (sprawdź łączność sieciową)

Jednym z najczęstszych problemów z konfiguracją OpenVPN jest to, że dwa demony OpenVPN po obu stronach połączenia nie są w stanie nawiązać między sobą połączenia TCP lub UDP.

Jest to prawie wynik:

• Zapora obwodowa w sieci serwera odfiltrowuje przychodzące pakiety OpenVPN (domyślnie OpenVPN używa portu UDP lub TCP o numerze 1194).
• Zapora programowa działająca na samym serwerze OpenVPN filtruje połączenia przychodzące na porcie 1194. Należy pamiętać, że wiele systemów operacyjnych domyślnie blokuje połączenia przychodzące, chyba że skonfigurowano inaczej.
• Brama NAT w sieci serwera nie ma reguły przekierowania portów dla TCP / UDP 1194 na wewnętrzny adres maszyny serwerowej OpenVPN.
• Konfiguracja klienta OpenVPN nie ma poprawnego adresu serwera w pliku konfiguracyjnym. Zdalna dyrektywa w pliku konfiguracyjnym klienta musi wskazywać albo na sam serwer, albo na publiczny adres IP bramy sieci serwera.
• Inną możliwą przyczyną jest to, że zapora systemu Windows blokuje dostęp do pliku binarnego openvpn.exe. Może być konieczne dodanie białej listy (dodanie jej do listy „Wyjątków”), aby OpenVPN działał.

Jest wysoce prawdopodobne, że którykolwiek z nich powoduje ten sam problem również w twoim przypadku. Więc po prostu przejrzyj listę jeden po drugim, aby ją rozwiązać.

Ref: Błąd TLS: Negocjacja klucza TLS nie nastąpiła w ciągu 60 sekund (sprawdź łączność sieciową)

Otrzymywałem limity czasu negocjacji kluczy TLS w ten sposób. Ale w moim przypadku zdałem sobie sprawę, że zdalny link to lokalny adres IP.

VPN w naszej zaporze ogniowej pfSense został omyłkowo umieszczony na interfejsie LAN zamiast interfejsu WAN, więc wyeksportowana konfiguracja została skonfigurowana tak, aby próbowała połączyć się z adresem IP zapory sieci LAN - co nigdy nie będzie działać z klientem, który naturalnie jest włączony inna sieć LAN.

Myślę, że główne wnioski z tego są:

• Uzyskanie limitu czasu dla kluczowych negocjacji niekoniecznie oznacza, że ​​udało Ci się nawet nawiązać połączenie.

  Dlatego na tym etapie nadal warto sprawdzić, czy faktycznie łączysz się z właściwym miejscem, i nie ma reguł zapory blokujących połączenie itp. W szczególności, jeśli konfiguracja została wygenerowana automatycznie.

  Pamiętaj, że wyświetlenie monitu o zalogowanie się nie oznacza, że ​​masz połączenie , ponieważ OpenVPN prosi o podanie poświadczeń przed próbą nawiązania połączenia.

• Upewnij się, że serwer VPN nasłuchuje na odpowiednim interfejsie.

  (Oczywiście jest to jedna z wielu błędnych konfiguracji po stronie serwera, które mogą wystąpić, takich jak reguły zapory ogniowej, podanie niewłaściwego numeru portu, połączenie TCP i UDP itp.)

Miałem ten sam błąd i żadna rada nie pomogła, wszystko wydawało się w porządku: adresy IP, porty, zapora ogniowa, wszystko. Oszalałam na 2 godziny.

Rozwiązaniem była zmiana protokołu z UDP na TCP w konfiguracji klienta (najwyraźniej już dawno celowo wyłączyłem UDP).

Mam nadzieję, że to komuś pomoże :)

LE: to rozwiązało mój problem, ale nie jest to najlepsze podejście zgodnie z poniższymi komentarzami. Powinieneś użyć UDP zamiast TCP. Pomogło mi to, ponieważ miałem różne ustawienia między konfiguracjami klienta i serwera.

Pamiętaj, że możesz otrzymać błąd negocjacji klucza TLS, bez udanego połączenia z serwerem OpenVPN - lub nawet z pomyślnym nawiązaniem połączenia z czymkolwiek!

Zmodyfikowałem konfigurację VPN, aby połączyć się z hostem lokalnym na porcie, który niczego nie nasłuchuje:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] zbudowany 26 kwietnia 2018 r.
Windows wersja 6.2 (Windows 8 lub nowszy) 64bit
wersje bibliotek: OpenSSL 1.1.0h 27 marca 2018, LZO 2.10
TCP / UDP: Zachowanie ostatnio używanego zdalnego adresu: [AF_INET] 127.0.0.1:12345
Link UDP lokalny (związany): [AF_INET] [undef]: 0
Zdalne łącze UDP: [AF_INET] 127.0.0.1:12345 
Błąd TLS: Negocjacja klucza TLS nie nastąpiła w ciągu 60 sekund (sprawdź łączność sieciową)
Błąd TLS: Niepowodzenie uzgadniania TLS
Otrzymano SIGUSR1 [miękki, błąd tls], restartowanie procesu
...

Błąd może wprawić cię w fałszywe poczucie, że rozmawiasz z serwerem VPN.

Możesz nawet zostać poproszony o podanie poświadczeń w pierwszej kolejności, ale nic poza komputerem tak naprawdę o nie nie poprosiło.

Żadne z wyżej wymienionych rozwiązań nie zadziałało. W moim przypadku, mimo że dziennik klienta pokazywał ten sam błąd TLS Error: TLS key negotiation failed to occur within 60 seconds, dzienniki serwera pokazywały VERIFY ERROR: depth=0, error=CRL has expired.

Na serwerze następujące kroki rozwiązały problem z połączeniem:

# 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

Wystąpił ten błąd w AWS, gdzie OpenVPN został zainstalowany na serwerze z publicznym adresem IP, ale w instancji, która była w prywatnej podsieci, tj. Podsieci, która nie miała trasy do bramy internetowej.

Po wdrożeniu OpenVPN na serwerze w publicznej podsieci wszystko działało dobrze :)

W publicznych / prywatnych podsieciach w AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

Natknąłem się również na TLS key negotiation failed to occur within 60 secondsproblem.

Zgodnie z oficjalną sugestią, jak pisze post Diamant, w połączeniu sieciowym musi być coś nie tak. Jednak ani zapora sieciowa, ani NAT nie powodują problemu.

W moim przypadku najpierw sprawdziłem połączenie przez nc -uvz xxx.xxx.xxx.xxx 1194. Link jest OK.

Poza tym kilka innych klientów VPN w tej samej sieci LAN działa dobrze.

Gdzieś zauważyłem, że połączenie udp ma pewne problemy z odpowiedzią lub przekierowaniem portów.

Zatrzymuję więc działających klientów VPN od największego adresu IP do wiszącego klienta, np. Z „10.8.0.100” do „10.8.0.50”.

Następnie uruchom zatrzymane klienty VPN w odwrotnej kolejności.

Huk! Wszyscy klienci VPN działają proporcjonalnie.

Podsumowując, istnieje ryzyko, TLS key negotiation failed to occur within 60 secondsże wielu klientów VPN w sieci LAN uruchomi się w niewłaściwej kolejności.

Jednym z możliwych powodów jest to, że jeśli serwer wymaga nowszej wersji TLS, niż TLS obsługiwany przez klienta. tj. 1,2 vs 1,0.

Oczywistą rzeczą, którą należy wypróbować, jest aktualizacja klienta OpenVPN lub zmodyfikowanie strony serwera, aby zaakceptować TLS 1.0.