Виправити помилку TLS: помилка передачі TLS не вдалася 'на клієнті OpenVPN

Я налаштовую OpenVPN 2.3.6-1 на своєму сервері Arch Linux для шифрування трафіку SMB через загальнодоступний Інтернет. Коли я перевірити установку на одному з моїх віртуальних машин клієнтів Linux, я отримую помилку: TLS Error: TLS handshake failed.

Я швидко прочитав ( OpenVPN на OpenVZ TLS Помилка: TLS рукостискання не вдалося (рішення, пропоновані Google не допомагають) ) і спробував переключитися з UDP за замовчуванням на TCP, але це лише змусило клієнта неодноразово повідомляти про те, що з'єднання вичерпано. Я також спробував відключити шифрування та аутентифікацію TLS, але це призвело до відмови сервера Assertion failed at crypto_openssl.c:523. В обох випадках були внесені необхідні зміни як в конфігурацію клієнта, так і на сервер.

Я дотримуюся вказівок ( https://wiki.archlinux.org/index.php/OpenVPN ) для налаштування OpenVPN та інструкцій за адресою ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ) для створення ключів та сертифікатів. Єдині відхилення, які я зробив від цих інструкцій, - це зазначення імен моїх власних комп'ютерів та відповідних імен файлів ключів / сертифікатів.

Дивіться також моє оригінальне запитання щодо забезпечення трафіку SMB через Інтернет: ( просте шифрування для акцій Samba )

Хтось може пояснити, як я можу вирішити це питання?

Деталі:

Сервер: Arch Linux (сучасний), підключений безпосередньо до шлюзу через Ethernet-кабель. Немає iptables.

Клієнт: Віртуальна машина Arch Linux (до цього часу) на VirtualBox 4.3.28r100309 Хост Windows 8.1, мостовий мережевий адаптер. Немає iptables. Брандмауер Windows відключений.

Шлюз: Увімкнено переадресацію портів на порт 1194, обмеження брандмауера відсутні.

Ось файли конфігурації відповідно на сервері та клієнті. Я створив їх згідно з інструкціями в Arch Wiki.

/etc/openvpn/server.conf (Тільки рядки без коментарів):

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 (Тільки рядки без коментарів):

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

Ось результати запуску openvpn на машинах із зазначеними вище конфігураціями. Я запустив спочатку сервер, потім клієнт.

Вихід openvpn /etc/openvpn/server.confна сервер:

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

Вихід openvpn /etc/openvpn/client.confклієнта:

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)

У мене була і ця проблема.

Я використовую digitalocean провайдера для мого сервера, і проблема була з плаваючою функцією ip.

Щоб виправити це, вам потрібно оновити налаштування configv openvpn:

local <ip anchor>

ip anchor має бути адресою ip, зібраною з ip addrкоманди, див. приклад:

Подяки на цю посаду

Як запропонували Майкл Хемптон та Міхал Соколовський у коментарях до мого питання, це була проблема з правилом переадресації портів, який я створив на своєму шлюзі. OpenVPN налаштований на використання UDP, і я забув перейти з TCP на UDP на шлюзі, оскільки я зазвичай не використовую цей протокол. Правило переадресації тепер використовує UDP, і мій VPN функціональний.

Якщо вона з’являється після оновлення ядра ОС. Або вхідні пакети відображаються в tcpdump на сервері, але все ще не працює. Спробуйте просте відключення / включення брандмауера. Можливо, хтось допоможе.

sudo ufw disable
sudo ufw enable

Моя поточна конфігурація буде працювати в деяких країнах, але не в інших. Я підозрюю, що мій поточний постачальник блокує пакет рукостискання TLS. Рішення? Оскільки я єдиний, хто використовує цю VPN, я перейшов на статичну автентифікацію ключів, яка - у моєму випадку - виявилася дуже швидкою https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static -key-mini-howto.html

У мене виникла ця проблема через неправильно налаштований шлюз за замовчуванням на стороні сервера. Сервер OpenVPN отримує спробу підключення від клієнта, але відповідь тоді втрачається, оскільки він ніколи не досягав потрібного маршрутизатора.

У мене просто була ця проблема. Перевіряючи мій файл .ovpn, я побачив, що? .Ddns.net було змінено на IP-адресу, через що він не підключився. Я змінив IP-адресу на адресу? .Ddns.net і він підключився.