Napraw „Błąd TLS: Uścisk dłoni TLS nie powiódł się” na kliencie OpenVPN

Konfiguruję OpenVPN 2.3.6-1 na moim serwerze Arch Linux, aby szyfrować ruch SMB w publicznym Internecie. Kiedy testować ustawienia na jednym z moich klientów Linux maszyn wirtualnych, pojawia się błąd: TLS Error: TLS handshake failed.

Szybko przeczytałem ( OpenVPN na OpenVZ Błąd błędu TLS: Uzgodnienie TLS nie powiodło się (sugerowane przez Google rozwiązania nie pomagają) ) i próbowałem przełączyć się z domyślnego UDP na TCP, ale to tylko powodowało, że klient wielokrotnie zgłaszał przekroczenie limitu czasu połączenia. Próbowałem także wyłączyć szyfrowanie i uwierzytelnianie TLS, ale spowodowało to awarię serwera Assertion failed at crypto_openssl.c:523. W obu przypadkach wprowadzono wymagane zmiany zarówno w konfiguracji klienta, jak i serwera.

Postępowałem zgodnie z instrukcjami na ( https://wiki.archlinux.org/index.php/OpenVPN ), aby skonfigurować OpenVPN i instrukcjami na ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ), aby utworzyć klucze i certyfikaty. Jedyne odstępstwa, które wprowadziłem w tych instrukcjach, to określenie nazw własnych komputerów i odpowiadających im nazw plików kluczy / certyfikatów.

Zobacz także moje pierwotne pytanie dotyczące zabezpieczania ruchu SMB przez Internet: ( Proste szyfrowanie udziałów Samby )

Czy ktoś może wyjaśnić, jak mogę rozwiązać ten problem?

Detale:

Serwer: Arch Linux (aktualny) podłączony bezpośrednio do bramy za pomocą kabla Ethernet. Brak iptables.

Klient: Arch maszyna wirtualna Linux (aktualna) na VirtualBox 4.3.28r100309 Host systemu Windows 8.1, zmostkowana karta sieciowa. Brak iptables. Zapora systemu Windows wyłączona.

Brama: Przekazywanie portów dla portu 1194 włączone, bez ograniczeń zapory.

Oto pliki konfiguracyjne odpowiednio na serwerze i kliencie. Stworzyłem je zgodnie z instrukcjami na Arch Wiki.

/etc/openvpn/server.conf (Tylko wiersze bez komentarzy):

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server-name.crt
key /etc/openvpn/server-name.key
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

/etc/openvpn/client.conf (Tylko wiersze bez komentarzy):

client
dev tun
proto udp
remote [my public IP here] 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client-name.crt
key /etc/openvpn/client-name.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3

Oto wyniki działania openvpn na maszynach z powyższymi konfiguracjami. Najpierw uruchomiłem serwer, a potem klienta.

Dane wyjściowe openvpn /etc/openvpn/server.confna serwerze:

Thu Jul 30 17:02:53 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 17:02:53 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 17:02:53 2015 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 30 17:02:53 2015 Diffie-Hellman initialized with 2048 bit key
Thu Jul 30 17:02:53 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 17:02:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 17:02:53 2015 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=##:##:##:##:##:##
Thu Jul 30 17:02:53 2015 TUN/TAP device tun0 opened
Thu Jul 30 17:02:53 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 17:02:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 17:02:53 2015 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Jul 30 17:02:53 2015 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Thu Jul 30 17:02:53 2015 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2
Thu Jul 30 17:02:53 2015 GID set to nobody
Thu Jul 30 17:02:53 2015 UID set to nobody
Thu Jul 30 17:02:53 2015 UDPv4 link local (bound): [undef]
Thu Jul 30 17:02:53 2015 UDPv4 link remote: [undef]
Thu Jul 30 17:02:53 2015 MULTI: multi_init called, r=256 v=256
Thu Jul 30 17:02:53 2015 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Thu Jul 30 17:02:53 2015 IFCONFIG POOL LIST
Thu Jul 30 17:02:53 2015 Initialization Sequence Completed

Dane wyjściowe openvpn /etc/openvpn/client.confna kliencie:

Thu Jul 30 21:03:02 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 21:03:02 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/client-name.key' is group or others accessible
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
Thu Jul 30 21:03:02 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 21:03:02 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 21:03:02 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Jul 30 21:03:02 2015 UDPv4 link local: [undef]
Thu Jul 30 21:03:02 2015 UDPv4 link remote: [AF_INET][my public IP here]:1194
Thu Jul 30 21:04:02 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 30 21:04:02 2015 TLS Error: TLS handshake failed
Thu Jul 30 21:04:02 2015 SIGUSR1[soft,tls-error] received, process restarting
Thu Jul 30 21:04:02 2015 Restart pause, 2 second(s)

Też miałem ten problem.

Używam dostawcy digitalocean dla mojego serwera, a problem dotyczył ruchomej funkcji ip.

Aby to naprawić, musisz zaktualizować ustawienie konfiguracji openvpn:

local <ip anchor>

ip anchor powinien być adresem ip zebranym z ip addrpolecenia, patrz przykład:

Podziękowania dla tego postu

Jak sugerowali Michael Hampton i Michał Sokołowski w komentarzach do mojego pytania, był to problem z regułą przekierowania portów, którą stworzyłem na mojej bramie. OpenVPN jest skonfigurowany do używania UDP i zapomniałem przełączyć się z TCP na UDP na bramie, ponieważ zwykle nie używam tego protokołu. Reguła przekazywania używa teraz UDP, a moja sieć VPN działa.

Jeśli pojawia się po aktualizacji rdzenia systemu operacyjnego. Lub przychodzące pakiety pojawiają się w tcpdump na serwerze, ale nadal nie działają. Wypróbuj proste wyłączenie / włączenie zapory ogniowej. Może ktoś pomoże.

sudo ufw disable
sudo ufw enable

Moja obecna konfiguracja będzie działać w niektórych krajach, ale w innych nie. Podejrzewam, że mój obecny dostawca blokuje pakiet uzgadniania TLS. Rozwiązanie? Ponieważ jestem jedynym, który korzysta z tej sieci VPN, przerzuciłem się na uwierzytelnianie za pomocą klucza statycznego, które - w moim przypadku - okazało się bardzo szybkie https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static -key-mini-howto.html

Otrzymałem ten problem z powodu źle skonfigurowanej bramy domyślnej po stronie serwera. Serwer OpenVPN pobierał próbę połączenia od klienta, ale odpowiedź została utracona, ponieważ nigdy nie osiągnęła właściwego routera.

Właśnie miałem ten problem. Podczas sprawdzania mojego pliku .ovpn zobaczyłem, że? .Ddns.net został zmieniony na adres IP, dlatego się nie łączył. Zmieniłem adres IP z powrotem na adres? .Ddns.net i połączyłem się.