Tls openvpn error: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
OpenVPN: TLS key negotiation failed to occur within 60 seconds
Как ни странно, причина не связана с конфигами самого OpenVPN сервера или клиентов, а кроется в сети, что и написано в логе.
Прослушка трафика показала, что нет обратного коннекта от сервера до клиента при рукопожатии:
14:01:59.465502 IP ServerIP.openvpn > ClientIP.54954: UDP, length 42 14:02:00.272635 IP ClientIP.54961 > ServerIP.openvpn: UDP, length 42 14:02:00.272889 IP ServerIP.openvpn > ClientIP.54961: UDP, length 54 14:02:03.568343 IP ClientIP.54961 > ServerIP.openvpn: UDP, length 42 14:02:03.568536 IP ServerIP.openvpn > ClientIP.54961: UDP, length 50 14:02:03.612846 IP ClientIP > ServerIP: ICMP host ClientIP unreachable - admin prohibited filter, length 36
При подробном режиме (verbose) такая картина:
14:08:14.154062 IP (tos 0x0, ttl 64, id 21182, offset 0, flags [DF], proto UDP (17), length 70)
ServerIP.openvpn > ClientIP.57304: [bad udp cksum 0xd2f6 -> 0xb107!] UDP, length 42
14:08:20.193700 IP (tos 0x0, ttl 122, id 29713, offset 0, flags [none], proto UDP (17), length 70)
ClientIP.62614 > ServerIP.openvpn: [udp sum ok] UDP, length 42
14:08:20.194123 IP (tos 0x0, ttl 64, id 21620, offset 0, flags [DF], proto UDP (17), length 82)
ServerIP.openvpn > ClientIP.62614: [bad udp cksum 0xd302 -> 0x6091!] UDP, length 54
14:08:20.238329 IP (tos 0x0, ttl 250, id 27288, offset 0, flags [none], proto ICMP (1), length 56)
ClientIP > ServerIP: ICMP host ClientIP unreachable - admin prohibited filter, length 36
IP (tos 0x0, ttl 58, id 21620, offset 0, flags [DF], proto UDP (17), length 82)
ServerIP.openvpn > ClientIP.62614: UDP, length 54
14:08:21.400665 IP (tos 0x0, ttl 122, id 29742, offset 0, flags [none], proto UDP (17), length 70)
ClientIP.62614 > ServerIP.openvpn: [udp sum ok] UDP, length 42
14:08:21.400811 IP (tos 0x0, ttl 64, id 21703, offset 0, flags [DF], proto UDP (17), length 78)
ServerIP.openvpn > ClientIP.62614: [bad udp cksum 0xd2fe -> 0x80f0!] UDP, length 50Причина крылась в запрете форварда входящих UDP подключений на циске роутере со стороны клиента. При этом исходящие работали, т.к. подключение и общение до рукопожатия происходило.
Как только разрешили проходить UDP трафик — коннект до OpenVPN сервера поднялся.
Если нет возможности открыть UDP трафик, то стоит перейти на TCP соединение.
OVPN TLS Error: TLS key negotiation failed.
OVPN сервер — микротик, OVPN клиент — венда
конфиг сервера:
[ziptar@MikroTik] > interface ovpn-server server print
enabled: yes
port: 1194
mode: ip
netmask: 24
mac-address: FE:9F:0B:F7:CB:D9
max-mtu: 1500
keepalive-timeout: 60
default-profile: PPP_Server
certificate: cert4
require-client-certificate: yes
auth: sha1
cipher: blowfish228конфиг клиента:
client
dev tun
proto tcp
remote ovpn.ml.ziptar.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
verb 4
--connect-retry 60Sun Oct 11 23:39:31 2015 us=376834 Current Parameter Settings:
список текущих параметров вырезан - больше 10000 букаф тостер ниасилил
Sun Oct 11 23:39:32 2015 us=17340 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 4 2015
Sun Oct 11 23:39:32 2015 us=19342 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Enter Private Key Password:
Sun Oct 11 23:39:38 2015 us=627780 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Oct 11 23:39:38 2015 us=633773 Control Channel MTU parms [ L:1543 D:140 EF:40 EB:0 ET:0 EL:3 ]
Sun Oct 11 23:39:38 2015 us=633773 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Oct 11 23:39:38 2015 us=637778 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:12 ET:0 EL:3 ]
Sun Oct 11 23:39:38 2015 us=637778 Local Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_CLIENT,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sun Oct 11 23:39:38 2015 us=638782 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1543,tun-mtu 1500,proto TCPv4_SERVER,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sun Oct 11 23:39:38 2015 us=655792 Local Options hash (VER=V4): 'db02a8f8'
Sun Oct 11 23:39:38 2015 us=656788 Expected Remote Options hash (VER=V4): '7e068940'
Sun Oct 11 23:39:38 2015 us=656788 Attempting to establish TCP connection with [AF_INET]95.31.27.23:1194 [nonblock]
Sun Oct 11 23:39:39 2015 us=663222 TCP connection established with [AF_INET]95.31.27.23:1194
Sun Oct 11 23:39:39 2015 us=663222 TCPv4_CLIENT link local: [undef]
Sun Oct 11 23:39:39 2015 us=663222 TCPv4_CLIENT link remote: [AF_INET]95.31.27.23:1194
Sun Oct 11 23:39:39 2015 us=666219 TLS: Initial packet from [AF_INET]95.31.27.23:1194, sid=0fc9eb4e dea8cee0
Sun Oct 11 23:39:39 2015 us=751116 VERIFY OK: depth=1, C=RU, O=Ziptar.Net, OU=Ziptar.Net Main Lair CA, CN=Ziptar.Net Main Lair Certification Authority
Sun Oct 11 23:39:39 2015 us=752117 Validating certificate key usage
Sun Oct 11 23:39:39 2015 us=752117 ++ Certificate has key usage 00a0, expects 00a0
Sun Oct 11 23:39:39 2015 us=755119 VERIFY KU OK
Sun Oct 11 23:39:39 2015 us=757282 Validating certificate extended key usage
Sun Oct 11 23:39:39 2015 us=759447 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Oct 11 23:39:39 2015 us=762598 VERIFY EKU OK
Sun Oct 11 23:39:39 2015 us=764603 VERIFY OK: depth=0, C=RU, O=Ziptar.Net, OU=Ziptar.Net Main Lair, CN=Ziptar.Net Main Lair OVPN Server Certificate
Sun Oct 11 23:40:40 2015 us=242140 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Oct 11 23:40:40 2015 us=242140 TLS Error: TLS handshake failed
Sun Oct 11 23:40:40 2015 us=243132 Fatal TLS error (check_tls_errors_co), restarting
Sun Oct 11 23:40:40 2015 us=247138 TCP/UDP: Closing socket
Sun Oct 11 23:40:40 2015 us=250137 SIGUSR1[soft,tls-error] received, process restarting
Sun Oct 11 23:40:40 2015 us=252138 Restart pause, 60 second(s)на микротике-сервере коннект client-ip(внешний):1194->server-ip:1194 в состоянии established
на роутере, за которым находится венда — аналогично
netstat на венде кажет:
TCP 172.16.12.13:51360 95-31-27-23:1194 ESTABLISHED
единственно не понимаю почему через дефисы
в логе сервера идёт обмен пакетами, и оканчивается строчкой::using encoding BF-128-CBC/SHA1
Key usage сертификата сервера
KU 0xa0: Digital Signature, Key Encipherment
EKU TLS Web Server Authentication
то есть ровнёхонько то, что желает сам ovpn
сертификата клиента
KU Digital Signature, Key Encipherment, Data Encipherment
EKU TLS Web Client Authentication
так что же он от меня желает? 🙁
Ошибки VPN соединений
Иногда случаются проблемы с VPN подключением или VPN не работает. На данной странице вы можете найти описание возникающей ошибки впн и самостоятельно исправить ее.
Ошибки OpenVPN
Если вы не знаете как узнать ошибку, возникшую в ходе подключения, нажмите на следующую ссылку:
Ниже представлен список возможных ошибок и методы их устранения. Нажмите на ошибку, чтобы узнать как ее устранить. Названия ошибок соответствуют записям в окне лога.
Как узнать какая OpenVPN ошибка возникла?
Программа OpenVPN имеет лог подключения. При подключении к OpenVPN серверу программа записывает данные подключения. Эта информация никуда не передается и остается на вашем компьютере, чтобы вы могли понять из-за чего возникла ошибка впн. Чтобы вызвать окно лога, нажмите дважды левой кнопкой мыши на иконку OpenVPN в системном трее.
Когда соединение прошло успешно, и вы подключены к VPN серверу, то окно лога должно выглядеть так:
наверх
Не могу выбрать «Connect» при нажатии на иконку в системном трее
В списке есть только «Proxy Settings», «About» и «Exit», но нет пункта «Connect».
Это означает, что вы не скачали и/или не скопировали конфигурационный файл «client.ovpn» в «C:/Program Files/OpenVPN/config». Откройте еще раз Инструкцию по настройке OpenVPN соединения для вашей ОС и проверьте все шаги установки и настройки.
наверх
Connect to IP:Port failed, will try again in 5 seconds; No Route to Host
Данная ошибка означает, что у вас нет подключения к Интернету, либо его блокирует ваш Firewall или Антивирус.
Проверьте активно ли ваше Интернет подключение, отключите Firewall, Антивирус и подключитесь еще раз.
наверх
Cannot load certificate file client.crt
Данная ошибка связана с отсутствием сертификационных файлов в папке «C:Program FilesOpenVPNconfig».
В процессе установки было необходимо скачать архив с сертификатами и распаковать его в папку с программой. Откройте еще раз Инструкцию по настройке OpenVPN соединения для вашей ОС и проверьте все шаги установки и настройки.
наверх
All TAP-Win32 adapters on this system are currently in use
Эта впн ошибка связана с некорректной работой Windows и программы OpenVPN. Также эта OpenVPN ошибка может возникнуть вследствие отключения Интернета без отключения сначала OpenVPN соединения. Всегда отключайте сначала OpenVPN соединение и только затем Интернет.
Для устранения ошибки, зайдите в «Пуск -> Сетевые подключения». Найдите «Подключение по локальной сети. TAP-Win32 Adapter» и правой кнопкой мышки щелкните на ярлыке. Выберите «Отключить».
Затем, таким же образом, «Включите» данное подключение. После выполнения данных действий проблемы с VPN подключением должны исчезнуть.
наверх
ERROR: Windows route add command failed: returned error code 1
Данная ошибка связана с ограничением прав в Windows Vista, Seven.
Для устранения ошибки, необходимо выйти из OpenVPN GUI. Правой кнопкой мышки нажать на иконку OpenVPN GUI на рабочем столе и выбрать пункт меню «Свойства»
На вкладке «Совместимость» поставьте галочку «Выполнять эту программу от имени администратора».
Теперь запустите OpenVPN GUI еще раз и подключитесь к VPN серверу.
наверх
Initialization Sequence Completed With Errors
Данная ошибка связана с неправильной работой службы DHCP из-за антивирусов или фаерволов.
Ошибка наблюдалась постоянно у фаервола Outpost Firewall версии 2009 и ранее, наблюдается также у антивируса Касперского. Ниже представлено решение для антивируса Касперского. Сам алгоритм ничем не отличается от решения проблемы для других антивирусов и фаерволов.
Для устранения ошибки, необходимо зайти в «Пуск -> Панель Управления -> Сетевые подключения» и зайти в «Свойства» виртуального адаптера «TAP-Win 32 Adapter». На вкладке «Общие» в списке отключить Kaspersky Anti-Virus NDIS Filter и затем нажать «ОК».
Теперь подключитесь к VPN и подключение должно пройти успешно.
наверх
Проблема с подключением к OpenVPN — Хабр Q&A
Тестирую OpenVPN на удаленном VPS, не могу подключиться. Настраивал по этому туториалу . Подскажите, в чем может быть проблема?
log подключения
Fri Mar 28 12:48:47 2014 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Fri Mar 28 12:48:50 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Mar 28 12:48:50 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Mar 28 12:48:50 2014 LZO compression initialized
Fri Mar 28 12:48:50 2014 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Mar 28 12:48:50 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Mar 28 12:48:50 2014 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Mar 28 12:48:50 2014 Local Options hash (VER=V4): 'd3a7571a'
Fri Mar 28 12:48:50 2014 Expected Remote Options hash (VER=V4): '5b1533a2'
Fri Mar 28 12:48:50 2014 UDPv4 link local: [undef]
Fri Mar 28 12:48:50 2014 UDPv4 link remote: *ip*:1194
Fri Mar 28 12:49:04 2014 TLS: Initial packet from *ip*:1194, sid=dc12be0a 9daee0c4
Fri Mar 28 12:49:04 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Mar 28 12:49:37 2014 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=changeme/name=changeme/[email protected]
Fri Mar 28 12:49:37 2014 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=server/name=changeme/[email protected]
Fri Mar 28 12:49:50 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Mar 28 12:49:50 2014 TLS Error: TLS handshake failed
Fri Mar 28 12:49:50 2014 TCP/UDP: Closing socket
Fri Mar 28 12:49:50 2014 SIGUSR1[soft,tls-error] received, process restartingvar/log/messages
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS object -> incoming plaintext read error
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:23:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=6ee022fb cf324eca
Mar 28 12:24:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 28 12:24:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:24:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:32:43 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=b95a9146 f3028138
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS object -> incoming plaintext read error
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:33:44 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=6db967fe 9f5adbd3
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS object -> incoming plaintext read error
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:34:46 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=90e5468a 0d86403bserver.conf
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2024.pem
server 10.8.0.0 255.255.255.0
fconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3server.ovpn
client
dev tun
proto udp
remote *IP* 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ca ca.crt
auth-user-pass
comp-lzo
reneg-sec 0
verb 3Не подключается OpenVPN | Losst
OpenVPN — очень популярная программа для организации виртуальных сетей и VPN-серверов. Это очень удобно, так как вы можете объединить несколько компьютеров, находящихся в разных концах мира в одну виртуальную локальную сеть и для операционной системы всё будет выглядеть так, как будто эти компьютеры действительно находятся в одной локальной сети.
Но иногда сеть перестает работать или не получается её настроить. В этой статье мы разберём несколько причин, почему не подключается OpenVPN, с которыми лично сталкивался я и которые мне приходилось исправлять. Возможно, одна из них и привела к вашей поломке.
Содержание статьи:
1. Сервис запущен?
Если вы только что установили и настроили OpenVPN, убедитесь, что его сервис запущен и работает. Если сервер не запущен, то, как правило, при попытке подключения вы будете получать ошибку «Connection refused». Для проверки выполните:
sudo systemctl status openvpn
В некоторых случаях сервис запускается с определённым конфигом. Тогда для проверки нужно указать этот конфигурационный файл:
sudo systemctl status openvpn@имя_конфига
Также вы можете посмотреть, слушает ли сервис подключения на порту OpenVPN:
ss -tlpn | grep openvpn
2. Открыт порт?
Если сервис запущен и слушает подключения на 1194 порту, а вы всё ещё не можете подключится, убедитесь, что этот порт не защищён брандмауэром на сервере. Для этого просто пробуем подключится к нему с помощью telnet:
telnet ip_сервера 1194
Когда всё хорошо, утилита сообщит об успешном подключении:
Если вы получаете такую же ошибку — «Connection refused» — или просто долго идёт подключение, но сервис запущен, значит порт закрыт. Открыть порт в Ubuntu можно с помощью команды:
sudo ufw allow 1194
А в CentOS:
sudo firewall-cmd --zone=trusted --add-service openvpnsudo firewall-cmd --zone=trusted --add-service openvpn --permanent
Теперь можете снова попробовать подключаться к вашему OpenVPN-серверу и теперь всё должно заработать.
3. Соответствуют ли настройки?
Если сервер запущен и доступен извне, но вы всё ещё не можете подключится, то проверьте, соответствуют ли клиентская сторона настройкам сервера. Обратите внимание на тип подключения — tcp это или udp? Также обратите внимание на настройки шифрования и сжатия, особенно tls и comp-lzo. Все настройки, касающиеся подключения, должны быть одинаковыми как в конфигурационном файле клиента, так и сервера.
4. Используете ли правильные ключи?
Если вы подписывали ключи вручную, без использования какого-либо автоматического скрипта настройки OpenVPN, и поэтому они находятся в отдельных файлах от клиентского конфигурационного файла, тогда проверьте, используете ли вы правильные ключи и правильно ли они подписаны. Обычно при проблемах с ключами всё это очень хорошо видно в лог-файле OpenVPN. Но об этом позже. Попробуйте подписать ключи ещё раз.
5. Стабильная сеть?
Если OpenVPN подключается, но подключение постоянно разрывается, причиной этому может стать нестабильная сеть. Если вы знаете, что сеть у вас не очень стабильная или сильно загружена, уберите эти опции из конфигурационного файла клиента:
sudo vi /etc/openvpn/server.conf
#ping 5
#ping-restart 10
Как правило, это решает проблему с сетью и программа может нормально работать даже в сети, которая постоянно разрывается. Также можно не удалять эти строки полностью, а просто увеличить их значения.
6. Проанализируйте лог файл
Если вам всё ещё не удалось выяснить, почему не работает подключение, значит это что-то более серьёзное и без анализа лог-файла вам не обойтись. При подключении в терминале клиента вы обычно будете получать примерно одну и ту же ошибку:
SIGUSR1[soft,connection-reset] received, process restarting
Более подробную информацию можно взять из лог-файла сервера. Лог-файл настраивается директивой log-append в конфигурационном файле сервера, обычно это /var/log/openvpn.log.
По умолчанию уровень логирования равен трём. На этом уровне вы мало что сможете понять. Вам нужен уровень 9, максимальный. Поэтому откройте конфигурационный файл и приведите настройки логирования к такому виду:
log-append /var/log/openvpn.log
verb 9
Теперь перезапустите OpenVPN:
sudo systemctl restart openvpn@имя_конфига
Откройте лог-файл и попробуйте снова подключится:
tail -f /var/log/openvpn.log
Здесь вы увидите очень много информации, просмотрите её внимательно и найдите, где именно находится проблема. Обычно программа сама говорит где проблема и как её решить. Главное, потом не забудьте вернуть значение параметра verb по умолчанию (3) иначе лог-файл очень быстро займёт всё свободное место на жёстком диске.
7. Два пользователя одновременно
Если по одному и тому же конфигурационному файлу пытаются подключится два или больше пользователей одновременно, то OpenVPN примет только одно подключение, а все остальные будет сбрасывать. Это поведение можно изменить, добавив к конфигурации сервера строчку:
duplicate-cn
Но лучше так не делать и создавать для каждого пользователя или устройства отдельный конфигурационный файл, тогда можно будет просто отследить, кто и когда подключался.
8. Истек срок действия crl
CRL — это список отозванных сертификатов. Этот файл имеет свой срок действия, и он может истекать. Если это произойдёт, то в логе вы найдёте ошибку «CRL has expired». Для быстрого её решения можно просто закомментировать строчку:
crl-verify crl.pem
Но тогда отозванные сертификаты перестанут быть отозванными. Другой вариант — это создать этот файл заново. Если у вас установлен пакет скриптов EasyRSA, который, обычно, автоматически устанавливается вместе с OpenVPN, то сделать это очень просто. Перейдите в папку со скриптами:
cd /etc/openvpn/easyrsa/
И выполните:
./easyrsa gen-crl
Затем скопируйте полученный файл в папку с файлами OpenVPN:
cp /etc/openvpn/easy-rsa/pki/crl.pem /etc/openvpn/crl.pem
Готово, теперь у вас всё будет работать.
9. Сервер перегружен
Если вы не можете подключится или подключение разрывается, причиной этому может стать недостаточное количество ресурсов на сервере. Убедитесь, что сервер ничем не перегружен, а на жёстком диске есть свободное место.
Выводы
Сегодня мы разобрали несколько причин, почему может возникнуть ошибка «не удалось подключиться к OpenVPN». Конечно, это только самые простые проблемы, и при более серьёзном использовании программы можно столкнутся с более крупными проблемами. Какие казусы с подключением к OpenVPN вам приходилось решать? Напишите свои варианты решений в комментариях!
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
Оцените статью:
Загрузка…
Ошибки OpenVPN — CRL has expired и CRL signature failure
В то время как все нормальные люди отдыхают, системные администраторы переносят сервисы в дни минимальных нагрузок. В очередной раз мне пришлось перенести работающий шлюз на старой версии freebsd на современную centos 7. Так как я переносил шлюзы уже много раз, предполагал, что возникнут непредвиденные трудности. Они и возникли с openvpn.
Если у вас есть желание освоить Linux с нуля, не имея базовых знаний, рекомендую познакомиться с онлайн-курсом Administrator Linux.Basic в OTUS. Курс для новичков, для тех, кто хочет войти в профессию администратора Linux. Подробности по .
Мои предположения оправдались. Теоретически все выглядело понятно и достаточно просто. Шлюзы я много раз переносил и уже приноровился. Последовательность действий всегда примерно одинаковая:
- Берем свободный внешний ip и настраиваем на нем новый сервер.
- Переносим настройки фаервола, переносим таблицу маршрутов, делаем заготовки для переноса сетевых настроек.
- Запускаем на новом сервере идентичные сервисы, отлаживаем их работу.
- Цепляемся какой-нибудь виртуалкой к новому шлюзу и все проверяем.
- Выключаем старый шлюз, убираем его из автозагрузки, если он на виртуалке, и переносим его сетевые настройки на новый шлюз.
- Вместо пятого пункта, можно просто на dhcp поменять для клиентов дефолтный шлюз и ждать, когда они обновят свои сетевые настройки.
Правильнее и удобнее делать все по 6-му пункту, так как так проще откатиться назад в случае нештатной ситуации. Можно оставить два шлюза одновременно работающими и отлаживать их одновременно. К сожалению, чаще всего так сделать не получается по разным причинам (много клиентов с ручными настройками сети, dhcp сервер на этом же шлюзе и т.д.)
В общем, ситуации бывают разные, но план всегда примерно такой. Более подробный план я всегда стараюсь составить отдельно, где прописываю все шаги, чтобы в ключевой момент, когда ты приезжаешь в нерабочее время, не тратить лишних сил на те вещи, которые можно сделать заранее.
В этот раз я поленился все проверить заранее. Даже не то, что поленился. Просто праздники и у меня много времени в запасе. Решил сразу все делать на месте, прикинув простой план в голове.
Сложность возникла с переносом настроек и сертификатов openvpn сервера. Было много разных туннелей под разные задачи с разными настройками. Но не в этом суть, перенести их дело техники. Первой проявилась следующая проблема.
Я перенес настройки и сертификаты openvpn первого тоннеля, запустил его. На вид все в порядке, тоннель запустился без ошибок. Стал подключаться клиентом — он не подключается. В логе сервера ошибка:
TLS: Initial packet from [AF_INET]77.37.227.11:52871, sid=ba15g8a4 4d8aew18 VERIFY ERROR: depth=0, error=CRL has expired: CN=user10 OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Я сразу уловил суть ошибки и стал гуглить. Проблема была в файле отозванных сертификатов. Если его не использовать, то все работало нормально и клиенты openvpn подключались. Но я не мог от него отказаться, отзывов было очень много, я не мог допустить возможности подключиться отозванным сертификатам.
Решение проблемы нашлось достаточно быстро, ошибка весьма популярная. Не буду на ней останавливаться подробно, я воспользовался вот этой статьей — https://bozza.ru/art-287.html, там есть вся необходимая информация.
Я проверил свой файл, оказалось, он действительно был просрочен.
openssl crl -inform PEM -in crl.pem -text -noout
Отредактировал конфиг openssl.cnf, увеличил срок жизни файла и пересоздал его.
openssl ca -gencrl -keyfile keys/server/ca.key -cert keys/server/ca.crt -out keys/server/crl.pem -config openssl.cnf
Закинул новый файл в директорию с openvpn и перезапустил тоннель. Еще порадовался, что быстро решил проблему. Но как оказалось, мои проблемы только начались. При подключении клиента к новому openvpn серверу, снова выскакивала ошибка, но уже принципиально другая:
TLS: Initial packet from [AF_INET]77.37.227.11:52871, sid=ba15g8a4 4d8aew18 VERIFY ERROR: depth=0, error=CRL signature failure: CN=user10 OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Тут наскоком решить вопрос не получилось. Стал опять шерстить англоязычный поиск на релевантную тему. Похожих запросов именно с crl почти не было, а там где были, не было решений. И вообще было не очень понятно, в чем тут дело. Но худо бедно картинка началась складываться. Я так же не мог добавить новый сертификат к списку отзыва со старыми настройками openssl, получал ошибку.
Дело оказалось вот в чем. Я переносил сертификаты openvpn с очень старого сервера freebsd 8.2, который настраивали примерно в 2010 году. Для генерации файла отзывов сертификатов (Certificate Revocation List (CRL) использовался алгоритм вычисления хэша md5, который не поддерживается в Centos 7, так как считается небезопасным.
В моих планах не было экстренного перевыпуска клиентских сертификатов, а как собрать полный новый список отзывов, на основе существующего, я не знаю. Думаю, это возможно, но я пошел по другому пути. Пришлось искать временное решение проблемы, которое даст время для плановой смены всего устаревшего.
Для того, чтобы в CentOS 7 можно было работать с md5, нужно добавить в окружение следующие переменные:
NSS_HASH_ALG_SUPPORT=+MD5 OPENSSL_ENABLE_MD5_VERIFY=1
Для этого достаточно просто в консоли ввести:
export OPENSSL_ENABLE_MD5_VERIFY=1 export NSS_HASH_ALG_SUPPORT=+MD5
Можно добавить эти переменные в easy-rsa/vars. Это позволит вам продолжать вести старый список отзывов для openvpn. Для того, что служба openvpn применила эти переменные и начала нормально работать с md5, необходимо привести конфиг systemd к следующему виду:
# cat /usr/lib/systemd/system/[email protected]
[Unit] Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I After=network.target [Service] Type=notify PrivateTmp=true ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/ --config %i.conf Environment="OPENSSL_ENABLE_MD5_VERIFY=1 NSS_HASH_ALG_SUPPORT=+MD5" [Install] WantedBy=multi-user.target
После этого все запускаемые тоннели или добавленные в автозагрузку скрипты запуска для openvpn в systemd (в /etc/systemd/system/multi-user.target.wants), будут созданы с этими значениями окружения.
После этих изменений мои клиенты openvpn стали нормально подключаться к серверу. К счастью, сертификаты клиентов были сгенерированы c применением хэша sha1, который пока еще не запретили.
Если у вас еще нет своего vpn сервера, рекомендую мою подробную статью на эту тему — настройка openvpn сервера.
Онлайн курс по Linux
Если у вас есть желание освоить операционную систему Linux, не имея подходящего опыта, рекомендую познакомиться с онлайн-курсом Administrator Linux. Basic в OTUS. Курс для новичков, адаптирован для тех, кто только начинает изучение Linux. Обучение длится 4 месяца.
Что даст вам этот курс:
- Вы получите навыки администрирования Linux (структура Linux, основные команды, работа с файлами и ПО).
- Вы рассмотрите следующий стек технологий: Zabbix, Prometheus, TCP/IP, nginx, Apache, MySQL, Bash, Docker, Git, nosql, grfana, ELK.
- Умение настраивать веб-сервера, базы данных (mysql и nosql) и работа с сетью.
- Мониторинг и логирование на базе Zabbix, Prometheus, Grafana и ELK.
- Научитесь командной работе с помощью Git и Docker.
Смотрите подробнее программу по .
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.
Ошибка OpenVPN CRL has expired (просрочен список CRL)
главная
— Статьи — Удаленный доступ (VPN)
Теги: Linux OpenVPN VPN VPN сервер
Сразу после обновления OpenVPN до версии 2.4.1(и, соответственно, после рестарта службы), клиенты не смогли подключиться к серверу, а на сервере в логе было что-то вроде:
TLS: Initial packet from [AF_INET]19.10.5.11:51849, sid=ba13f8a4 4c4aec28
VERIFY ERROR: depth=0, error=CRL has expired: CN=client1
OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting
Это ошибка проверки списка отзывов сертификатов (CRL — certificate revoke list).
Возможно, это и не связано с версией 2.4, просто очень долго не нужно было перезапускать сервис OpenVPN, а тут при обновлении пришлось.
В конфиге сервера список CRL указан директивой:
crl-verify crl.pem
Убедиться, что проблема в этом списке, можно закомментировав эту строку в конфиге сервера и перезапустив сервер. Если дело только в списке отозванных сертификатов, клиенты спокойно начнут подключаться.
Для решения проблемы со списком CRL надо этот список обновить. В зависимости от того, каким образом вы управляете ключами OpenVN, это может быть по-разному.
Перед любыми действиями с CA рекомендую сделать архив:
# tar -cvzf /backup/openvpn.tar.gz /etc/openvpn
1) OpenSSL (общий случай):
# openssl ca -gencrl -keyfile ca.key -cert ca.crt -out crl.pem -config openssl.cnf
далее файл crl.pem скопировать в рабочее расположение OpenVPN и рестарт OpenVPN-сервера.
2) EasyRSA (версия 3):
# cd /etc/openvpn/easy-rsa
# ./easyrsa gen-crl
далее файл crl.pem скопировать в рабочее расположение OpenVPN:
# mv pki/crl.pem /etc/openvpn/
Рестарт сервера OpenVPN:
# systemctl restart openvpn@server
3) EasyRSA (версия 2) + OpenSSL
Не нашел специальной команды на обновление CRL с помощью EasyRSA 2, пришлось использовать openssl.
# cd /etc/openvpn/easy-rsa/2.0/
# . /etc/openvpn/easy-rsa/2.0/vars
# echo $KEY_CONFIG
/etc/openvpn/easy-rsa/2.0/openssl-1.0.0.cnf
По-умолчанию, обновление списка отозванных сертификатов производится раз в 30 дней. Это указано в конфиге в секции [ CA_default ]:
default_crl_days= 30
Можно увеличить этот интервал, например:
default_crl_days= 365
# openssl ca -gencrl -keyfile keys/ca.key -cert keys/ca.crt -out keys/crl.pem -config openssl-1.0.0.cnf
[ спойлер ] На этом этапе может возникнуть ошибка вроде configuration file routines:STR_COPY:variable has no value:conf_def.c
error on line 145 of /etc/openvpn/easy-rsa/openssl-1.0.0.cnf
4352345234545:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:618:line 145
Это из-за того, что скрипт vars не экспортировал переменную, которую использует конфиг openssl-1.0.0.cnf. В скрипте vars раскомментировал директиву export KEY_CN="CommonName" (была в самом конце файла). Еще раз выполнил экспорт:
# . /etc/openvpn/easy-rsa/2.0/vars
Теперь команда:
# openssl ca -gencrl -keyfile keys/ca.key -cert keys/ca.crt -out keys/crl.pem -config openssl-1.0.0.cnf
выполнилась успешно.
Можно просмотреть выпущенный сертификат CRL:
# openssl crl -inform PEM -in keys/crl.pem -text -noout
В информации будет указан список отозванных ключей (серийные номера), дата обновления и ближайшая необходимая дата регенерации CRL.
Далее файл crl.pem скопируем в рабочее расположение OpenVPN и рестартуем OpenVPN-сервер:
# service openvpn restart
Дополнительно
Открытым остался вопрос: все дело в просроченном сроке обновления сертификата CRL (default_crl_days) или только из-за обновления OpenVPN, не знаю. Проблема решена, дальше будет видно.
Все вышеописанное говорит о том, что в основе всех «easyrsa» скриптов лежит обычный openssl, поэтому 1) при возможности тренируйтесь в понимании «чистого» openssl, 2) имейте ввиду, что сертификаты openvpn могут быть частью общей инфраструктуры (например, у вас может быть свой корпоративный CA, чей сертификат установлен как корневой доверенный везде, а подписанные им сертификаты используются и в OpenVPN, и в веб-интерфейсах оргтехники, и в контроле доступа к локальноум веб-сайту и при шифровании или подписи почты и в других областях.
Авторизуйтесь для добавления комментариев!
! | |||||||
.
! | |||||||
.
! | |||||||
.
! | |||||||
.