Я настраиваю 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)
tcpdump -ni eth0 udp and port 1194
на сервере, и убедитесь, что пакеты приходят. Если они есть, могут быть проблемы с отбрасыванием пакетов брандмауэром, если нет, то, скорее всего, есть проблема с переадресацией портов на маршрутизаторе. Вы также можете сделать это на маршрутизаторе. Попробуйте и попробуйте использовать какой-нибудь порт более высокого уровня, это не часто, но, возможно, ваш провайдер испортил что-то, например порт 11194 / UDP или 53 / UDP.Ответы:
У меня тоже была эта проблема.
Я использую провайдера digitalocean для моего сервера, и проблема была с плавающей функцией IP.
Чтобы это исправить, вы должны обновить конфигурационные настройки openvpn:
IP-привязка должна быть IP-адресом, полученным из
ip addr
команды, см. пример:Кредиты на этот пост
источник
local <ip address of VPN server>
записи в конфигурацию сервера исправило ее. Обратите внимание, что для TCP эта запись не нужна, это был только UDP, чтобы выдать ошибку.Как предложили Майкл Хэмптон и Михал Соколовски в комментариях к моему вопросу, это была проблема с правилом переадресации портов, которое я создал на своем шлюзе. OpenVPN настроен на использование UDP, и я забыл переключиться с TCP на UDP на шлюзе, поскольку я обычно не использую этот протокол. Правило пересылки теперь использует UDP, и мой VPN работает.
источник
Если он появляется после обновления ядра ОС. Или входящие пакеты отображаются в tcpdump на сервере, но все равно не работают. Попробуйте простой брандмауэр отключить / включить. Может быть, кто-нибудь поможет.
источник
Моя текущая конфигурация будет работать в некоторых странах, но не в других. Я подозреваю, что мой текущий провайдер блокирует пакет рукопожатия TLS. Решение? Поскольку я единственный, кто использует эту VPN, я переключился на аутентификацию с использованием статического ключа, которая - в моем случае - оказалась очень быстрой. Https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static -key мини-howto.html
источник
Я получил эту проблему из-за неправильно настроенного шлюза по умолчанию на стороне сервера. Сервер OpenVPN получал попытку подключения от клиента, но тогда ответ терялся, потому что он никогда не достигал нужного маршрутизатора.
источник
etc/openvpn/server.conf
?ip route
.У меня просто была эта проблема. При проверке моего файла .ovpn я увидел, что? .Ddns.net был изменен на IP-адрес, поэтому он не подключился. Я изменил IP обратно на адрес? .Ddns.net и он подключился.
источник