#################################################
# Sample OpenVPN 2.0 config file for #
# multi-client server. #
# #
# This file is for the server side #
# of a many-clients <-> one-server #
# OpenVPN configuration. #
# #
# OpenVPN also supports #
# single-machine <-> single-machine #
# configurations (See the Examples page #
# on the web site for more info). #
# #
# This config should work on Windows #
# or Linux/BSD systems. Remember on #
# Windows to quote pathnames and use #
# double backslashes, e.g.: #
# «C:\Program Files\OpenVPN\config\foo.key» #
# #
# Comments are preceded with ‘#’ or ‘;’ #
#################################################
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194
# TCP or UDP server?
;proto tcp
proto udp
# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tun
dev tap
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don’t need this.
dev-node Ethernet_7
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).
ca «C:\Program Files\OpenVPN\config\ca.crt»
cert «C:\Program Files\OpenVPN\config\server.crt»
key «C:\Program Files\OpenVPN\config\server.key» # This file should be kept secret
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh «C:\Program Files\OpenVPN\config\dh4096.pem»
# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
topology subnet
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
;server 192.168.1.225 255.255.0.0
# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
# Configure server mode for ethernet bridging.
# You must first use your OS’s bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 192.168.1.227/255.255.0.0. Finally we
# must set aside an IP range in this subnet
# (start=192.168.3.1 end=192.168.3.254) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
server-bridge 192.168.1.227 255.255.0.0 192.168.3.1 192.168.3.254
# Configure server mode for ethernet bridging
# using a DHCP-proxy, where clients talk
# to the OpenVPN server-side DHCP server
# to receive their IP address allocation
# and DNS server addresses. You must first use
# your OS’s bridging capability to bridge the TAP
# interface with the ethernet NIC interface.
# Note: this mode only works on clients (such as
# Windows), where the client-side TAP adapter is
# bound to a DHCP client.
;server-bridge
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push «route 192.168.10.0 255.255.255.0»
;push «route 192.168.20.0 255.255.255.0»
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory «ccd» for client-specific
# configuration files (see man page for more info).
# EXAMPLE: Suppose the client
# having the certificate common name «Thelonious»
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious’ private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using «dev tun» and «server» directives.
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push «redirect-gateway def1 bypass-dhcp»
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push «dhcp-option DNS 208.67.222.222»
;push «dhcp-option DNS 208.67.220.220»
# Uncomment this directive to allow different
# clients to be able to «see» each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
client-to-client
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE «COMMON NAME»,
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn —genkey —secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‘0’
# on the server and ‘1’ on the clients.
;tls-auth «C:\Program Files\OpenVPN\config\ta.key» 0 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC
# Enable compression on the VPN link and push the
# option to the client (v2.4+ only, for earlier
# versions see below)
;compress lz4-v2
;push «compress lz4-v2»
# For compression compatible with older clients use comp-lzo
# If you enable it here, you must also
# enable it in the client config file.
;comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the «Program FilesOpenVPNlog» directory).
# Use log or log-append to override this default.
# «log» will truncate the log file on OpenVPN startup,
# while «log-append» will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1
Модераторы: GRooVE, alexco
Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
-
Гость
- проходил мимо
OpenVPN не заводиться 
Доброго времени суток ВСЕМ
Можете мне подсказать что не так ?
У клиента в логах openvpn.log ругань:
Код: Выделить всё
##########################################################
event_wait : Interrupted system call (code=4)
TCP/UDP: Closing socket
SIGTERM[hard,] received, process exiting
OpenVPN 2.0.6 i386-portbld-freebsd4.8 [SSL] [LZO] built on Sep 17 2008
Control Channel Authentication: using '/usr/local/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Outgoing Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Incoming Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options hash (VER=V4): '03fa487d'
Expected Remote Options hash (VER=V4): '1056bce3'
UDPv4 link local (bound): [undef]:2000
UDPv4 link remote: xxx.xxx.xxx.xxx:2000
[b]TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed[/b]
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 2 second(s)
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options hash (VER=V4): '03fa487d'
Expected Remote Options hash (VER=V4): '1056bce3'
UDPv4 link local (bound): [undef]:2000
UDPv4 link remote: xxx.xxx.xxx.xxx:2000А в логах сервера вот такая ругань:
##########################################################
Код: Выделить всё
[b]xx.xx.xx.xx:2000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
xx.xx.xx.xx:2000 SIGUSR1[soft,tls-error] received, client-instance restarting
MULTI: multi_create_instance called[/b]
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
xx.xx.xx.xx:2000 Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
xx.xx.xx.xx:2000 Local Options hash (VER=V4): '1056bce3'
xx.xx.xx.xx:2000 Expected Remote Options hash (VER=V4): '03fa487d'
xx.xx.xx.xx:2000 TLS: Initial packet from 62.80.178.22:2000, sid=ede7e96a 84c81a85
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)ifconfig сервера:
Код: Выделить всё
##########################################################
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.10.200.1 --> 10.10.200.2 netmask 0xffffffff
Opened by PID 19690
##########################################################Сертификаты готовились на сервере, ось FreeBSD6.2 и OpenVPN 2.0.6
Клиент живет на FreeBSD4.8 и OpenVPN 2.0.6
Подскажите что не так.
Спасибо!
Последний раз редактировалось zingel 2008-09-19 12:45:26, всего редактировалось 1 раз.
Причина: юзай [code][/code]
-
Хостинг HostFood.ru
Услуги хостинговой компании Host-Food.ru
Хостинг HostFood.ru
Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2008-09-19 12:41:22
Код: Выделить всё
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
эти строчки мне не нравятся
фаервол?
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
BI_J
- сержант
- Сообщения: 154
- Зарегистрирован: 2008-09-19 12:21:10
Re: OpenVPN не заводиться
Непрочитанное сообщение
BI_J » 2008-09-19 12:52:58
Все делалось по статье уважаемого mak_v_.
http://www.lissyara.su/?id=1685&comment … mment_4718
После совета проверить firewal, в логах клиента ситуация немного изменилась:
У клиента в логах openvpn.log ругань:
##########################################################
OpenVPN 2.0.6 i386-portbld-freebsd4.8 [SSL] [LZO] built on Sep 17 2008
Control Channel Authentication: using ‘/usr/local/etc/openvpn/keys/ta.key’ as a OpenVPN static key file
Outgoing Control Channel Authentication: Using 128 bit message hash ‘MD5’ for HMAC authentication
Incoming Control Channel Authentication: Using 128 bit message hash ‘MD5’ for HMAC authentication
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options hash (VER=V4): ’03fa487d’
Expected Remote Options hash (VER=V4): ‘1056bce3’
UDPv4 link local (bound): [undef]:2000
UDPv4 link remote: ip.ser.ve.ra:2000
TLS Error: Unroutable control packet received from ip.ser.ve.ra:2000 (si=3 op=P_ACK_V1)
TLS Error: Unroutable control packet received from ip.ser.ve.ra:2000 (si=3 op=P_ACK_V1)
.
.
.
VERIFY nsCertType ERROR: /C=UA/ST=Kiev/L=Kiev/O=server/OU=server/CN=server/emailAddress=admin@domen.com.ua, require nsCertType=SERVER
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 2 second(s)
У сервера ругань почти не изменилась:
##########################################################
ip.cli.en.ta:2000 TLS: new session incoming connection from 62.80.178.22:2000
ip.cli.en.ta:2000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
ip.cli.en.ta:2000 TLS Error: TLS handshake failed
ip.cli.en.ta:2000 SIGUSR1[soft,tls-error] received, client-instance restarting
MULTI: multi_create_instance called
как я понимаю что то с сертификатами. Генерил как написано 
-
serge
- майор
- Сообщения: 2133
- Зарегистрирован: 2006-07-30 15:34:14
- Откуда: Саратов
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
serge » 2008-09-19 14:52:30
Случаем не в клетке OpenVPN сидит?
Вот это смущает…
Unroutable control packet received from ip.ser.ve.ra:2000
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2008-09-19 14:57:22
и всетаки попробуйте ище раз пегенерировать сертификаты
у вас тип сертификата не совпадает 
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
serge
- майор
- Сообщения: 2133
- Зарегистрирован: 2006-07-30 15:34:14
- Откуда: Саратов
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
serge » 2008-09-19 15:08:49
TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
дословно гуглом
TLS ключевые переговоры «не произойдет в течение 60 секунд (проверьте ваши сетевые подключения)
имхо, главная часть
проверьте ваши сетевые подключения
-
BI_J
- сержант
- Сообщения: 154
- Зарегистрирован: 2008-09-19 12:21:10
Re: OpenVPN не заводиться
Непрочитанное сообщение
BI_J » 2008-09-19 15:14:23
Спасибо за подсказки.
После очередной перегенирации сертификатов ситуация резко улучшилась 
Но VPN так и не поднялся.
Теперь проблема кажеться в маршрутах со стороны клиента.
У клиента в логах openvpn.log
##########################################################
Код: Выделить всё
[server] Peer Connection Initiated with ip.ser.ve.ra:2000
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.10.200.1,ping 10,ping-
restart 120,ifconfig 10.10.200.2 10.10.200.1'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route options modified
gw ip.pro.vay.da
TUN/TAP device /dev/tun1 opened
/sbin/ifconfig tun1 10.10.200.2 10.10.200.1 mtu 1500 netmask 255.255.255.255 up
/usr/local/etc/openvpn/openvpn_up.sh tun1 1500 1538 10.10.200.2 10.10.200.1 init
/usr/local/etc/openvpn/openvpn_up.sh: permission denied
script failed: shell command exited with error status: 126
Fri Sep 19 14:02:08 2008 Exiting##########################################################
Интернет удаленный клиент получает через модем провайдера через вот такое соединение:
ifconfig:
Код: Выделить всё
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet ip.cli.en.ta --> ip.pro.vay.da netmask 0xffffffff
Opened by PID 88нужно как то рулить это дело
-
zingel
- beastie
- Сообщения: 6204
- Зарегистрирован: 2007-10-30 3:56:49
- Откуда: Moscow
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
zingel » 2008-09-19 15:14:47
TLS ключевые переговоры «не произойдет в течение 60 секунд (проверьте ваши сетевые подключения)
Это гугловский переводчик такую ересь выдал? Я в шоке…
Z301171463546 — можно пожертвовать мне денег
-
BI_J
- сержант
- Сообщения: 154
- Зарегистрирован: 2008-09-19 12:21:10
Re: OpenVPN не заводиться
Непрочитанное сообщение
BI_J » 2008-09-19 17:03:49
Сижу, смотрю на ошибку и в упор не замечаю грабли (стыдно белое перо 
):
Код: Выделить всё
usr/local/etc/openvpn/openvpn_up.sh tun1 1500 1538 10.10.200.2 10.10.200.1 init
/usr/local/etc/openvpn/openvpn_up.sh: permission denied
script failed: shell command exited with error status: 126
после выполнения:
chmod 755 /usr/local/etc/openvpn/openvpn_up.sh
положение улучшилось
пинг пошол между 10.10.200.2 и 10.10.200.1
хух
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 14:23:37
Здрасти ребята. У меня такая вот проблема. Что делать? Подскажите пожалуйста.
Thu Feb 05 13:22:02 2009 Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Feb 05 13:22:02 2009 Local Options hash (VER=V4): ’03fa487d’
Thu Feb 05 13:22:02 2009 Expected Remote Options hash (VER=V4): ‘1056bce3’
Thu Feb 05 13:22:02 2009 UDPv4 link local (bound): [undef]:2000
Thu Feb 05 13:22:02 2009 UDPv4 link remote: 22.22.22.22:2000
Thu Feb 05 13:23:01 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Feb 05 13:23:01 2009 TLS Error: TLS handshake failed
Thu Feb 05 13:23:01 2009 TCP/UDP: Closing socket
Thu Feb 05 13:23:01 2009 SIGUSR1[soft,tls-error] received, process restarting
Thu Feb 05 13:23:01 2009 Restart pause, 2 second(s)
Thu Feb 05 13:23:03 2009 Re-using SSL/TLS context
Thu Feb 05 13:23:03 2009 LZO compression initialized
Thu Feb 05 13:23:03 2009 Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Thu Feb 05 13:23:03 2009 Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Feb 05 13:23:03 2009 Local Options hash (VER=V4): ’03fa487d’
Thu Feb 05 13:23:03 2009 Expected Remote Options hash (VER=V4): ‘1056bce3’
Thu Feb 05 13:23:03 2009 UDPv4 link local (bound): [undef]:2000
Thu Feb 05 13:23:03 2009 UDPv4 link remote: 22.22.22.22:2000
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 14:36:05
check your network connectivity
перевод требуется ?
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 14:42:50
фаервол прверить
tcpdump-ом посмотреть
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
Re: OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 14:44:35
tcpdump -om
tcpdump version 3.9.4
libpcap version 0.9.4
Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ]
[ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ]
[ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ] [ -y datalinktype ] [ -Z user ]
[ expression ]
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 14:46:45
где <int> интерфейс через который openvpn ломится в интернет
2000 порт и можно еще приписать
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
Re: OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 15:10:00
#tcpdump -i fxp0 -np port 2000 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 15:11:41
ну и при запущенном tcpdump рестартануть openvpn
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
Re: OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 15:40:25
Запустил tcpdump и сделал рестарт openvpn. Вот результат.
Код: Выделить всё
#tcpdump -i fxp0 -np port 2000 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
Код: Выделить всё
38 packets captured
4492 packets received by filter
0 packets dropped by kernel-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 15:47:18
у вас openvpn точно работает на 2000 порту udp?
если да то проверяйте фаервол
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
hz
- проходил мимо
- Сообщения: 4
- Зарегистрирован: 2009-03-24 9:59:09
Re: OpenVPN не заводиться
Непрочитанное сообщение
hz » 2009-03-24 10:27:16
День добрый.Помогите советом куда копать.Трабл в следующем:всё поднималось по описанию mac_v (отдельное спасибо).Туннель поднялся.Но проблема в следующем-внутрення сеть «филиала» видит внутреннее пространство за сервером впн.В обратную же сторону,т.е. то что находится внутри «головного офиса» не видит сетку «филиала».Выдаёт на ping ошибку ping: sendto: Invalid argument.Маршуты все прописаны.Руками прописывать пробывал маршрут до подсети «филиала» — ответ маршрут сущ-т.
-
zingel
- beastie
- Сообщения: 6204
- Зарегистрирован: 2007-10-30 3:56:49
- Откуда: Moscow
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
zingel » 2009-03-24 13:29:05
отдельную тему лучше
Z301171463546 — можно пожертвовать мне денег
-
Sanya0413
- проходил мимо
- Сообщения: 2
- Зарегистрирован: 2010-03-30 15:30:44
Re: OpenVPN не заводиться
Непрочитанное сообщение
Sanya0413 » 2010-03-30 16:31:46
# !/bin/sh
/bin/sh: Event not found.
# /sbin/route add -net 192.168.1.0 10.10.200.1
route: writing to routing socket: Network is unreachable
add net 193.168.1.0: gateway 10.10.200.1: Network is unreachable
при создании файла openvpn_up.sh пишет вот такую ругню.
все создал по статье, sockstat ‘ ом проверил openvpn поднялся на сервере и на клиенте, но пинги не идут((
I’m configuring an OpenVPN (version 2.3.10) server on a Windows 2012 server but I cannot make it to work.
The server is behind a router and I opened the 1194 port and created a rule to forward traffic on this port to the server.
Here is the log I see on the server when I try to connect from a client:
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
Where XX.XX.XX.XX is the ip of the client. So I understand from this that the client at least is able to arrive at the server, so there’s no routing or firewall issues.
I followed the description provided here Easy Windows Guide Any ideas?
MadHatter
79k20 gold badges183 silver badges231 bronze badges
asked Mar 23, 2016 at 7:04
6
What’s interesting is how the port number changes mid-stream:
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
This makes me think that, somewhere between client and server, there is a misbehaving NAT device, a device with very short-lived state table entries, which is changing the source port number that it applies to the client’s established stream, causing the server to think that two short-lived communications are in progress, instead of one continuous one.
Such devices generally only do this with UDP, so I have advised you to confirm that you are using UDP, and try TCP instead. This you have done, and found that it fixes the problem. The next step is to identify the misbehaving NAT device, hit it with a club hammer, and replace it with one that doesn’t make the cardinal mistake of assuming that all UDP communications are ephemeral; but you have indicated that you’re happy with changing to TCP as a workaround, and so the matter is concluded.
answered Mar 23, 2016 at 10:39
MadHatterMadHatter
79k20 gold badges183 silver badges231 bronze badges
6
This is one of the most common error in setting up Openvpn and there is a FAQ entry for this. I’m going to quote this here:
TLS Error: TLS key negotiation failed to occur within 60 seconds
(check your network connectivity)One of the most common problems in setting up OpenVPN is that the two
OpenVPN daemons on either side of the connection are unable to
establish a TCP or UDP connection with each other.This is almost a result of:
- A perimeter firewall on the server’s network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port
number 1194).- A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many
OSes will block incoming connections by default, unless configured
otherwise.- A NAT gateway on the server’s network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server
machine.- The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file
must point to either the server itself or the public IP address of the
server network’s gateway.- Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it
to the «Exceptions» list) it for OpenVPN to work.
It’s highly likely that any of these is causing the same problem in your case too. So just go through the list one by one to resolve it.
Ref: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
MadHatter
79k20 gold badges183 silver badges231 bronze badges
answered Mar 23, 2016 at 8:23
DiamondDiamond
8,9213 gold badges23 silver badges38 bronze badges
4
I was getting TLS key negotiation timeouts like this. But in my case I realised that the remote link was a local IP address.
The VPN on our pfSense firewall had mistakenly been put on the LAN interface instead of the WAN interface, and so the exported config was set to try and connect to the firewall’s LAN IP address — which was never going to work with the client naturally being on a different LAN.
I think the main takeaways from this are:
-
Getting a key negotiation timeout does not necessarily mean you’ve even managed to connect to anything.
So at this stage it may still be worth checking you’re actually connecting to the right place, and there are no firewall rules blocking the connection, etc. Particularly if your configuration has been automatically generated.
Note that getting a login prompt does not mean that you’re connected, since OpenVPN asks for your credentials before trying to connect.
-
Make sure your VPN server is listening on the right interface.
(Of course, this is one of a number of server-side misconfigurations that could occur, such as firewall rules, putting the wrong port number, intermixing TCP and UDP, etc.)
answered Mar 21, 2017 at 12:18
mwfearnleymwfearnley
7881 gold badge10 silver badges21 bronze badges
I had the same error and no advice helped, everything seemed to be fine: IPs, ports, firewall, everything. Gone insane for 2 hours.
Solution was to change the protocol from UDP to TCP in the client config (apparently I disabled UDP on purpose a long while ago).
Hope this helps someone 
LE: this solved my problem but it’s not the best approach as per below comments. You should use UDP instead of TCP. It helped me because I had different settings between the client and the server configs.
answered Jun 1, 2017 at 20:11
boschbosch
1856 bronze badges
5
None of the solutions mentioned earlier worked. In my case, even though the client log showed same error TLS Error: TLS key negotiation failed to occur within 60 seconds, the server logs showed VERIFY ERROR: depth=0, error=CRL has expired.
On the server, following steps resolved the connection issue:
# 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
answered Dec 5, 2018 at 3:49
mpprdevmpprdev
1511 gold badge1 silver badge5 bronze badges
Note that you can get a TLS key negotiation error, without successfully connecting to the OpenVPN server — or even successfully connecting to anything at all!
I modified a VPN config to connect to localhost, on a port that wasn’t listening on anything:
OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018 Windows version 6.2 (Windows 8 or greater) 64bit library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:12345 UDP link local (bound): [AF_INET][undef]:0 UDP link remote: [AF_INET]127.0.0.1:12345 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed SIGUSR1[soft,tls-error] received, process restarting ...
The error can lull you into a false sense that you’re talking to a VPN server.
You may even get prompted for credentials first, but nothing outside your computer has actually asked for them.
answered Aug 10, 2018 at 15:21
mwfearnleymwfearnley
7881 gold badge10 silver badges21 bronze badges
I ran into this error in AWS, where OpenVPN was installed on a server with a public IP, but on an instance which was in a private subnet, i.e. a subnet which didn’t have a route to an internet gateway.
Once I deployed OpenVPN on a server within a public subnet, it all worked nicely
On public/private subnets in AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html
answered Aug 29, 2018 at 15:15
ZoltánZoltán
2172 silver badges6 bronze badges
I also came across the TLS key negotiation failed to occur within 60 seconds problem.
From the official suggestion, as Diamant post, there must be something wrong in the network connection. However, neither the firewall nor the NAT cause the problem.
In my case, I first checked the connection by nc -uvz xxx.xxx.xxx.xxx 1194. The link is OK.
Besides, several other vpn clients within the same LAN work fine.
From somewhere I noticed that udp connection has some problems in response or port forward.
So I stop the running vpn clients from the largest ip to the hanging client, e.g, from «10.8.0.100» to «10.8.0.50».
Then start the stopped vpn clients in reverse.
Bang! All the vpn clients work propoerly.
In conclusion, there is a chance leads to TLS key negotiation failed to occur within 60 seconds problem that multiple vpn clients within a LAN starting in a wrong sequence.
answered May 30, 2019 at 6:18
1
One possible reason is if the server requires TLS version newer then the TLS supported by the client. i.e 1.2 vs 1.0.
The obvious thing to try is to update the OpenVPN client, or modify the server side to accept TLS 1.0.
kenlukas
2,9862 gold badges14 silver badges25 bronze badges
answered Mar 24, 2020 at 17:45
You should create a SSL/TLS certificate on OMV and then enable secure connection SSL/TLS and add the created certificate.
So simple!
answered May 28, 2020 at 3:50
Are there more than two NetCards on your OVPN-Server?
In UDP, the source IP is not checked when responding. OVPN-Server will use the default configuration to send UDP data, so we need to specify the NetCard in server.conf.
local the-IP-in-client.ovpn
answered Aug 21, 2020 at 4:03
There seems to be a lot of different causes for the error — I was seeing this on the server for one client, but successfully connecting with another (the latter client being an android device using the OpenVPN Connect App).
What it turned out to be in my case is that I’d neglected to include a CommonName value when creating the server certificate — the app was ignoring this mistake but the other clients (OpenVPN plugin for Network Manager and pfSense) were validating this and refusing to continue the connection. This could be found within the client logs, but all that was visible on the server-side logs was:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
answered Apr 29, 2021 at 5:03
цель соединить две сети. есть два сервера под ClearOS 6.3
основной офис с подсетью 192.168.0.0/24 и шлюзом с OpenVpn в роли сервера 192.168.0.250
Второй офис c подсетью 192.168.0.2/24 и шлюзом с Openvpn в роли клиента
Иногда коннект происходит и из сети за клиентом пингуется сеть основного офиса. при проблемах в подключении лог клиента выглядит так:
Tue Mar 26 12:31:37 2013 OpenVPN 2.2.1 i386-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Sep 12 2011
Tue Mar 26 12:31:37 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:31:37 2013 WARNING: file '/etc/openvpn/new/client-st1g-key.pem' is group or others accessible
Tue Mar 26 12:31:37 2013 LZO compression initialized
Tue Mar 26 12:31:37 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:31:37 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:31:37 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:31:37 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:31:37 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:31:37 2013 UDPv4 link local: [undef]
Tue Mar 26 12:31:37 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:31:37 2013 TLS: Initial packet from XX.XX.XX.XX:1194, sid=89a598f9 f7366aa5
Tue Mar 26 12:31:37 2013 VERIFY OK: depth=1, /C=RU/L=Krasnodar/O=ClearOS/OU=grand/CN=ca.clearos.grand.com/emailAddress=security@clearos.grand.com/O=grand/ST=Krasnodar
Tue Mar 26 12:31:37 2013 VERIFY OK: nsCertType=SERVER
Tue Mar 26 12:31:37 2013 VERIFY OK: depth=0, /C=RU/ST=Krasnodar/L=Krasnodar/O=ClearOS/O=grand/OU=grand/CN=clearos.grand.com/emailAddress=security@clearos.grand.com
Tue Mar 26 12:31:37 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:31:37 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:31:37 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:31:37 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:31:37 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar 26 12:31:37 2013 [clearos.grand.com] Peer Connection Initiated with XX.XX.XX.XX:1194
Tue Mar 26 12:31:40 2013 SENT CONTROL [clearos.grand.com]: 'PUSH_REQUEST' (status=1)
Tue Mar 26 12:31:40 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.0.250,dhcp-option WINS ,dhcp-option DOMAIN grand.com,route 192.168.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: route options modified
Tue Mar 26 12:31:40 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Mar 26 12:31:40 2013 ROUTE default_gateway=192.168.1.1
Tue Mar 26 12:31:40 2013 TUN/TAP device tun0 opened
Tue Mar 26 12:31:40 2013 TUN/TAP TX queue length set to 100
Tue Mar 26 12:31:40 2013 /sbin/ip link set dev tun0 up mtu 1500
Tue Mar 26 12:31:40 2013 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Tue Mar 26 12:31:40 2013 /sbin/ip route add 192.168.0.0/24 via 10.8.0.5
Tue Mar 26 12:31:40 2013 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Tue Mar 26 12:31:40 2013 Initialization Sequence Completed
Tue Mar 26 12:33:40 2013 [clearos.grand.com] Inactivity timeout (--ping-restart), restarting
Tue Mar 26 12:33:40 2013 TCP/UDP: Closing socket
Tue Mar 26 12:33:40 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Mar 26 12:33:40 2013 Restart pause, 2 second(s)
Tue Mar 26 12:33:42 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:33:42 2013 Re-using SSL/TLS context
Tue Mar 26 12:33:42 2013 LZO compression initialized
Tue Mar 26 12:33:42 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:33:42 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:33:42 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:33:42 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:33:42 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:33:42 2013 UDPv4 link local: [undef]
Tue Mar 26 12:33:42 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:34:42 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:34:42 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:34:42 2013 TCP/UDP: Closing socket
Tue Mar 26 12:34:42 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:34:42 2013 Restart pause, 2 second(s)
Tue Mar 26 12:34:44 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:34:44 2013 Re-using SSL/TLS context
Tue Mar 26 12:34:44 2013 LZO compression initialized
Tue Mar 26 12:34:44 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:34:44 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:34:44 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:34:44 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:34:44 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:34:44 2013 UDPv4 link local: [undef]
Tue Mar 26 12:34:44 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:35:45 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:35:45 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:35:45 2013 TCP/UDP: Closing socket
Tue Mar 26 12:35:45 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:35:45 2013 Restart pause, 2 second(s)
Tue Mar 26 12:35:47 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:35:47 2013 Re-using SSL/TLS context
Tue Mar 26 12:35:47 2013 LZO compression initialized
Tue Mar 26 12:35:47 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:35:47 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:35:47 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:35:47 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:35:47 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:35:47 2013 UDPv4 link local: [undef]
Tue Mar 26 12:35:47 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:36:47 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:36:47 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:36:47 2013 TCP/UDP: Closing socket
Tue Mar 26 12:36:47 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:36:47 2013 Restart pause, 2 second(s)
Tue Mar 26 12:36:49 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:36:49 2013 Re-using SSL/TLS context
Tue Mar 26 12:36:49 2013 LZO compression initialized
Tue Mar 26 12:36:49 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:36:49 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:36:49 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:36:49 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:36:49 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:36:49 2013 UDPv4 link local: [undef]
Tue Mar 26 12:36:49 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:36:49 2013 TLS: Initial packet from XX.XX.XX.XX:1194, sid=7444d74a 473b1a1f
Tue Mar 26 12:36:49 2013 VERIFY OK: depth=1, /C=RU/L=Krasnodar/O=ClearOS/OU=grand/CN=ca.clearos.grand.com/emailAddress=security@clearos.grand.com/O=grand/ST=Krasnodar
Tue Mar 26 12:36:49 2013 VERIFY OK: nsCertType=SERVER
Tue Mar 26 12:36:49 2013 VERIFY OK: depth=0, /C=RU/ST=Krasnodar/L=Krasnodar/O=ClearOS/O=grand/OU=grand/CN=clearos.grand.com/emailAddress=security@clearos.grand.com
Tue Mar 26 12:36:49 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:36:49 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:36:49 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:36:49 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:36:49 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar 26 12:36:49 2013 [clearos.grand.com] Peer Connection Initiated with XX.XX.XX.XX:1194
Tue Mar 26 12:36:52 2013 SENT CONTROL [clearos.grand.com]: 'PUSH_REQUEST' (status=1)
Tue Mar 26 12:36:52 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.0.250,dhcp-option WINS ,dhcp-option DOMAIN grand.com,route 192.168.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: route options modified
Tue Mar 26 12:36:52 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Mar 26 12:36:52 2013 Preserving previous TUN/TAP instance: tun0
Tue Mar 26 12:36:52 2013 Initialization Sequence Completed
Tue Mar 26 12:38:47 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:47 2013 TLS Error: reading acknowledgement record from packet
Tue Mar 26 12:38:47 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:47 2013 VERIFY OK: depth=1, /C=RU/L=Krasnodar/O=ClearOS/OU=grand/CN=ca.clearos.grand.com/emailAddress=security@clearos.grand.com/O=grand/ST=Krasnodar
Tue Mar 26 12:38:47 2013 VERIFY OK: nsCertType=SERVER
Tue Mar 26 12:38:47 2013 VERIFY OK: depth=0, /C=RU/ST=Krasnodar/L=Krasnodar/O=ClearOS/O=grand/OU=grand/CN=clearos.grand.com/emailAddress=security@clearos.grand.com
Tue Mar 26 12:38:47 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:38:47 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:38:47 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 26 12:38:47 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 26 12:38:47 2013 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Tue Mar 26 12:38:47 2013 TLS: tls_multi_process: untrusted session promoted to semi-trusted
Tue Mar 26 12:38:47 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar 26 12:38:49 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:49 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:38:54 2013 TLS: new session incoming connection from XX.XX.XX.XX:1194
Tue Mar 26 12:39:03 2013 TLS Error: reading acknowledgement record from packet
Tue Mar 26 12:39:04 2013 TLS Error: Unroutable control packet received from XX.XX.XX.XX:1194 (si=3 op=P_ACK_V1)
Tue Mar 26 12:39:49 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:39:49 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:41:14 2013 [clearos.grand.com] Inactivity timeout (--ping-restart), restarting
Tue Mar 26 12:41:14 2013 TCP/UDP: Closing socket
Tue Mar 26 12:41:14 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Mar 26 12:41:14 2013 Restart pause, 2 second(s)
Tue Mar 26 12:41:16 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:41:16 2013 Re-using SSL/TLS context
Tue Mar 26 12:41:16 2013 LZO compression initialized
Tue Mar 26 12:41:16 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:41:16 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:41:16 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:41:16 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:41:16 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:41:16 2013 UDPv4 link local: [undef]
Tue Mar 26 12:41:16 2013 UDPv4 link remote: XX.XX.XX.XX:1194
Tue Mar 26 12:42:16 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 26 12:42:16 2013 TLS Error: TLS handshake failed
Tue Mar 26 12:42:16 2013 TCP/UDP: Closing socket
Tue Mar 26 12:42:16 2013 SIGUSR1[soft,tls-error] received, process restarting
Tue Mar 26 12:42:16 2013 Restart pause, 2 second(s)
Tue Mar 26 12:42:18 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Tue Mar 26 12:42:18 2013 Re-using SSL/TLS context
Tue Mar 26 12:42:18 2013 LZO compression initialized
Tue Mar 26 12:42:18 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Mar 26 12:42:18 2013 Socket Buffers: R=[196608->131072] S=[196608->131072]
Tue Mar 26 12:42:18 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Mar 26 12:42:18 2013 Local Options hash (VER=V4): '41690919'
Tue Mar 26 12:42:18 2013 Expected Remote Options hash (VER=V4): '530fdded'
Tue Mar 26 12:42:18 2013 UDPv4 link local: [undef]
Tue Mar 26 12:42:18 2013 UDPv4 link remote: XX.XX.XX.XX:1194
port 1194
proto udp
dev tun
ca /etc/pki/CA/ca-cert.pem
cert /etc/pki/CA/sys-0-cert.pem
key /etc/pki/CA/private/sys-0-key.pem
dh /etc/openvpn/ssl/dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
ifconfig-pool-persist /var/lib/openvpn/ipp.txt
status /var/lib/openvpn/openvpn-status.log
verb 3
push "dhcp-option DNS 192.168.0.250"
push "dhcp-option WINS "
push "dhcp-option DOMAIN grand.com"
push "route 192.168.0.0 255.255.255.0"client
remote XX.XX.XX.XX 1194
dev tun
proto udp
nobind
keepalive 10 60
tls-timeout 15
persist-key
persist-tun
ca /etc/openvpn/new/ca-cert.pem
cert /etc/openvpn/new/client-st1g-cert.pem
key /etc/openvpn/new/client-st1g-key.pem
ns-cert-type server
comp-lzo
verb 3Содержание
- OpenServer Ошибки с обеих сторон.
- OpenVPN Support Forum
- TLS handshake failed
- TLS handshake failed
OpenServer Ошибки с обеих сторон.
Есть CentOS 6.5, на нём стоит OpenServer 2.3.2 в комплекте с Easy-RSA 2.0. Суть в том, что сервер запускается нормально, то есть в логе я вижу «Initialization Sequence Completed». Далее я на удалённой машине пытаюсь подключиться к серверу с клиента XP SP3 (через OpenVPN-GUI 2.0.9). Схема работы такая:
На сервере в IPTABLES открыт UDP 1194, SeLinux отключен. Конфиг сервера
openssl verify -CAfile ca.crt client.crt
Делал, показывает ОК.
Вообще для меня тёмным пятном осталась настройка IPTABLES. Достаточно только открыть порт или необходимы ещё какие-то действия?
Ещё попробуй временно убрать tls-auth, в конфиге клиента client заменить на pull, а в конфиге сервера server заменить на
mode server
ifconfig 10.70.80.1 255.255.255.0
push «route-gateway 10.70.80.1»
Роутер с NAT (1194->1194 сервера)
Это должен быть DNAT. На всякий случай покажи iptables. Судя по тому, что клиент с сервером начали общаться — сделано правильно
Сделав данные действия получил в логе сервера
Ситуация такова: и в сервере, и на клиенте закоментировал строчки
Ошибка с TLS_ERROR: BIO read tls_read_plaintext error: появляется через раз, но вот с
Это при текущей секции server
Ты таблицу filter показал, а нужна ещё nat. Это iptables на роутере или на сервере? Я про роутер спрашивал
Опять встречаю iptables, настроенные в стиле pf — POLICY ACCEPT, и последнее правило DROP или REJECT. Почему не делать DROP/REJECT в POLICY? Удобнее же — можно просто добавлять новые правила, не контролируя, чтобы они встаил перед последним.
Как я понимаю, ошибка возникает из-за использования TLS Auth. Надо его отключить и попробовать установить соединение без него, а потом уже пробовать включить обратно. За него отвечает опция tls-auth, а ещё client и server раскрываются в несколько других опций, в том числе tls-client и tls-server. Надо как-то их убрать
server надо заменить на ifconfig . и что-то там ещё, потому что он раскрывается в tls-server, а мы пока пробуем завестись без tls auth.
после строки
tls-auth «C:\OpenVPN\ssl\ta.key» 1
на клиенте попробуйте прописать
auth MD5
IPTABLES, кроме портов, остался в том виде, в котором он идёт по дэфолту в СэнтОСе. IPTABLES я еще не постиг. Это IPTABLES на самом сервере VPN, на роутере (Asus RT-12N) просто идёт проброс с 1194 внешки на 1194 сервера.
TLS я вроде бы везде убрал. Я много поменял, уже немного запутался, поэтому еще раз выкладываю всё происходящее. Сервер:
Источник
OpenVPN Support Forum
Community Support Forum
TLS handshake failed
TLS handshake failed
Post by Bransonb3 » Sat Jan 06, 2018 4:57 pm
When I try to connect to my openvpn server I get TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) and TLS Error: TLS handshake failed. It looks like the server sees the client try to connect (TLS: Initial packet from. ) but doesn’t respond.
I’m running openvpn 2.4.4 on Windows Server 2016 1607. I am trying to connect my Mac running OSX 10.13.2, using Tunnelblick 3.7.4b but have also tried connecting using the openvpn connect android app. I have port forwarded 1194 udp to my server, made an inbound and outbound windows firewall rule allowing openvpn.exe, allowed tunnelblick incoming connections on the mac firewall. I have also tried to run the server as admin.
#################################################
# Sample OpenVPN 2.0 config file for #
# multi-client server. #
# #
# This file is for the server side #
# of a many-clients one-server #
# OpenVPN configuration. #
# #
# OpenVPN also supports #
# single-machine single-machine #
# configurations (See the Examples page #
# on the web site for more info). #
# #
# This config should work on Windows #
# or Linux/BSD systems. Remember on #
# Windows to quote pathnames and use #
# double backslashes, e.g.: #
# «C:\Program Files\OpenVPN\config\foo.key» #
# #
# Comments are preceded with ‘#’ or ‘;’ #
#################################################
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194
# TCP or UDP server?
;proto tcp
proto udp
# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tun
dev tap
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don’t need this.
dev-node Ethernet_7
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).
ca «C:\Program Files\OpenVPN\config\ca.crt»
cert «C:\Program Files\OpenVPN\config\server.crt»
key «C:\Program Files\OpenVPN\config\server.key» # This file should be kept secret
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh «C:\Program Files\OpenVPN\config\dh4096.pem»
# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
topology subnet
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
;server 192.168.1.225 255.255.0.0
# Maintain a record of client virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
# Configure server mode for ethernet bridging.
# You must first use your OS’s bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 192.168.1.227/255.255.0.0. Finally we
# must set aside an IP range in this subnet
# (start=192.168.3.1 end=192.168.3.254) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
server-bridge 192.168.1.227 255.255.0.0 192.168.3.1 192.168.3.254
# Configure server mode for ethernet bridging
# using a DHCP-proxy, where clients talk
# to the OpenVPN server-side DHCP server
# to receive their IP address allocation
# and DNS server addresses. You must first use
# your OS’s bridging capability to bridge the TAP
# interface with the ethernet NIC interface.
# Note: this mode only works on clients (such as
# Windows), where the client-side TAP adapter is
# bound to a DHCP client.
;server-bridge
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push «route 192.168.10.0 255.255.255.0»
;push «route 192.168.20.0 255.255.255.0»
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory «ccd» for client-specific
# configuration files (see man page for more info).
# EXAMPLE: Suppose the client
# having the certificate common name «Thelonious»
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious’ private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using «dev tun» and «server» directives.
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push «redirect-gateway def1 bypass-dhcp»
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push «dhcp-option DNS 208.67.222.222»
;push «dhcp-option DNS 208.67.220.220»
# Uncomment this directive to allow different
# clients to be able to «see» each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
client-to-client
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE «COMMON NAME»,
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn —genkey —secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‘0’
# on the server and ‘1’ on the clients.
;tls-auth «C:\Program Files\OpenVPN\config\ta.key» 0 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC
# Enable compression on the VPN link and push the
# option to the client (v2.4+ only, for earlier
# versions see below)
;compress lz4-v2
;push «compress lz4-v2»
# For compression compatible with older clients use comp-lzo
# If you enable it here, you must also
# enable it in the client config file.
;comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the «Program FilesOpenVPNlog» directory).
# Use log or log-append to override this default.
# «log» will truncate the log file on OpenVPN startup,
# while «log-append» will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1
##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server. #
# #
# This configuration can be used by multiple #
# clients, however each client should have #
# its own cert and key files. #
# #
# On Windows, you might want to rename this #
# file so it has a .ovpn extension #
##############################################
# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client
# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one. On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap
# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
;proto tcp
proto udp
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote [Public IP] 1194
# Choose a random host from the remote
# list for load-balancing. Otherwise
# try hosts in the order specified.
;remote-random
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
# Most clients don’t need to bind to
# a specific local port number.
nobind
# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody
# Try to preserve some state across restarts.
persist-key
persist-tun
# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here. See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings
# SSL/TLS parms.
# See the server config file for more
# description. It’s best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
——BEGIN CERTIFICATE——
Redacted
——END CERTIFICATE——
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=NC, L=High Point, O= Redacted, OU= Redacted, CN=BT-MonCon-SRV/name=Certificate Authority/emailAddress= Redacted
Validity
Not Before: Jan 5 04:57:55 2018 GMT
Not After : Jan 3 04:57:55 2028 GMT
Subject: C=US, ST=NC, L=High Point, O= Redacted, OU= Redacted, CN=BransonMac/name=BransonMac/emailAddress= Redacted
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
Redacted
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
Redacted
X509v3 Authority Key Identifier:
keyid: Redacted
DirName:/C=US/ST=NC/L=High Point/O= Redacted/OU= Redacted/CN=BT-MonCon-SRV/name=Certificate Authority/emailAddress= Redacted
serial: Redacted
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha256WithRSAEncryption
Redacted
——BEGIN CERTIFICATE——
Redacted
——END CERTIFICATE——
——BEGIN PRIVATE KEY——
Redacted
——END PRIVATE KEY——
# Verify server certificate by checking that the
# certicate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the keyUsage set to
# digitalSignature, keyEncipherment
# and the extendedKeyUsage to
# serverAuth
# EasyRSA can do this for you.
;remote-cert-tls BT-MonCon-SRV
# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1
# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC
# Enable compression on the VPN link.
# Don’t enable this unless it is also
# enabled in the server config file.
#comp-lzo
# Set log file verbosity.
verb 4
# Silence repeating messages
;mute 20
Источник
Здравствуйте! Клиент openvpn не подключается к серверу. На сайте, где покупался сервер, всё проверили, с их стороны всё работает.
До сегодняшнего дня всё было в порядке. Нового ничего не происходило: ни установки программ, ни обновлений, ничего. Просто клиент перестал подключаться к серверу.
Fri Nov 12 16:57:58 2021 DEPRECATED OPTION: —cipher set to ‘AES-256-CBC’ but missing in —data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore —cipher for cipher negotiations. Add ‘AES-256-CBC’ to —data-ciphers or change —cipher ‘AES-256-CBC’ to —data-ciphers-fallback ‘AES-256-CBC’ to silence this warning.
Fri Nov 12 16:57:58 2021 OpenVPN 2.5.4 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 20 2021
Fri Nov 12 16:57:58 2021 Windows version 6.3 (Windows 8.1) 64bit
Fri Nov 12 16:57:58 2021 library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10
Fri Nov 12 16:57:58 2021 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Fri Nov 12 16:57:58 2021 Need hold release from management interface, waiting…
Fri Nov 12 16:57:58 2021 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Nov 12 16:57:58 2021 MANAGEMENT: CMD ‘state on’
Fri Nov 12 16:57:58 2021 MANAGEMENT: CMD ‘log all on’
Fri Nov 12 16:57:58 2021 MANAGEMENT: CMD ‘echo all on’
Fri Nov 12 16:57:58 2021 MANAGEMENT: CMD ‘bytecount 5’
Fri Nov 12 16:57:58 2021 MANAGEMENT: CMD ‘hold off’
Fri Nov 12 16:57:58 2021 MANAGEMENT: CMD ‘hold release’
Fri Nov 12 16:57:58 2021 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 16:57:58 2021 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 16:57:58 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]46.29.160.29:1194
Fri Nov 12 16:57:58 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Nov 12 16:57:58 2021 UDP link local: (not bound)
Fri Nov 12 16:57:58 2021 UDP link remote: [AF_INET]46.29.160.29:1194
Fri Nov 12 16:57:58 2021 MANAGEMENT: >STATE:1636725478,WAIT,,,,,,
Fri Nov 12 16:58:58 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 12 16:58:58 2021 TLS Error: TLS handshake failed
Fri Nov 12 16:58:58 2021 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 12 16:58:58 2021 MANAGEMENT: >STATE:1636725538,RECONNECTING,tls-error,,,,,
Fri Nov 12 16:58:58 2021 Restart pause, 5 second(s)
Fri Nov 12 16:59:03 2021 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 16:59:03 2021 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 16:59:03 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]46.29.160.29:1194
Fri Nov 12 16:59:03 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Nov 12 16:59:03 2021 UDP link local: (not bound)
Fri Nov 12 16:59:03 2021 UDP link remote: [AF_INET]46.29.160.29:1194
Fri Nov 12 16:59:03 2021 MANAGEMENT: >STATE:1636725543,WAIT,,,,,,
Fri Nov 12 17:00:03 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 12 17:00:03 2021 TLS Error: TLS handshake failed
Fri Nov 12 17:00:03 2021 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 12 17:00:03 2021 MANAGEMENT: >STATE:1636725603,RECONNECTING,tls-error,,,,,
Fri Nov 12 17:00:03 2021 Restart pause, 5 second(s)
Fri Nov 12 17:00:08 2021 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 17:00:08 2021 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 17:00:08 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]46.29.160.29:1194
Fri Nov 12 17:00:08 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Nov 12 17:00:08 2021 UDP link local: (not bound)
Fri Nov 12 17:00:08 2021 UDP link remote: [AF_INET]46.29.160.29:1194
Fri Nov 12 17:00:08 2021 MANAGEMENT: >STATE:1636725608,WAIT,,,,,,
Fri Nov 12 17:01:08 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Nov 12 17:01:08 2021 TLS Error: TLS handshake failed
Fri Nov 12 17:01:08 2021 SIGUSR1[soft,tls-error] received, process restarting
Fri Nov 12 17:01:08 2021 MANAGEMENT: >STATE:1636725668,RECONNECTING,tls-error,,,,,
Fri Nov 12 17:01:08 2021 Restart pause, 5 second(s)
Fri Nov 12 17:01:13 2021 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 17:01:13 2021 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Fri Nov 12 17:01:13 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]46.29.160.29:1194
Fri Nov 12 17:01:13 2021 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Nov 12 17:01:13 2021 UDP link local: (not bound)
Fri Nov 12 17:01:13 2021 UDP link remote: [AF_INET]46.29.160.29:1194
Fri Nov 12 17:01:13 2021 MANAGEMENT: >STATE:1636725673,WAIT,,,,,,
Помогите, пожалуйста!
Обычно довольно легко настроить VPN с использованием OpenVPN. Это одна из самых привлекательных функций OpenVPN по сравнению с другими решениями VPN. Однако иногда необходимо устранить неполадки в нерабочей настройке или настроить существующую настройку для повышения производительности.
Устранение неполадок и настройка OpenVPN часто игнорируются. Файлы журнала OpenVPN на стороне клиента и сервера предоставляют много информации, но вы должны знать как их читать. При настройке файлов конфигурации клиента и сервера также допускается довольно много ошибок. В этой главе вы узнаете, как интерпретировать файлы журнала OpenVPN и как обнаруживать и исправлять некоторые из этих распространенных ошибок.
Наконец, существует большая разница между рабочей установкой и установкой, которая работает хорошо. Возможно, ваша установка OpenVPN работает правильно, но пользователи все равно могут жаловаться на низкую производительность. Получение максимальной производительности от установки OpenVPN может показаться черной магией. В этой главе вы узнаете немного этой черной магии.
В этой главе будут рассмотрены следующие темы:
- Как читать файлы журнала
- Исправление распространенных ошибок конфигурации
- Устранение проблем с маршрутизацией
- Как оптимизировать производительность с помощью
pingиiperf - Анализ трафика OpenVPN с использованием
tcpdump
Как читать файлы журнала
Поначалу отладка нерабочих настроек может показаться сложной задачей. С чего начать? К счастью, OpenVPN предоставляет отличные средства ведения журналов и отладки. Однако с увеличением степени детализации журналов становится все труднее читать эти файлы журналов. Уровень детализации журнала OpenVPN по умолчанию равен 1, но рекомендуется установить степень детализации 3. Это часто дает администратору достаточно информации для обнаружения проблем с настройкой, в то же время сводя к минимуму потери производительности.
Установка детальности на 5 или выше рекомендуется только для целей отладки, так как это сильно повлияет на производительность.
Каждый пример в этой книге до сих пор включал устанку verb 3. Во-первых, мы рассмотрим файлы журнала клиента и сервера для рабочей настройки с такой детальностью. Важно понимать и, возможно, даже хранить файлы журналов работающего соединения. При попытке найти ошибку в нерабочей настройке, очень полезно сравнивать файлы журнала нерабочего случая с файлами рабочей настройки.
Запустите сервер, используя файл конфигурации по умолчанию basic-udp-server.conf:
[root@server]# openvpn --config basic-udp-server.conf
Пока не подключайтесь к клиенту. Файл журнала сервера теперь будет содержать следующее:
1 14:53:27 OpenVPN 2.3.6 x86_64-redhat-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
built on Dec 2 2014
2 14:53:27 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013,
LZO2.03
3 14:53:27 Diffie-Hellman initialized with 2048 bit key
4 14:53:31 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
5 14:53:31 Control Channel Authentication: using
'/etc/openvpn/movpn/ta.key' as a OpenVPN static key
file
6 14:53:31 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
7 14:53:31 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
8 14:53:31 Socket Buffers: R=[16777216->131072]
S=[16777216->131072]
9 14:53:31 TUN/TAP device tun0 opened
10 14:53:31 TUN/TAP TX queue length set to 100
11 14:53:31 do_ifconfig, tt->ipv6=0, tt-did_ifconfig_ipv6_setup=0
12 14:53:31 /sbin/ip link set dev tun0 up mtu 1500
13 14:53:31 /sbin/ip addr add dev tun0 10.200.0.1/24
broadcast 10.200.0.255
14 14:53:31 GID set to nobody
15 14:53:31 UID set to nobody
16 14:53:31 UDPv4 link local (bound): [undef]
17 14:53:31 UDPv4 link remote: [undef]
18 14:53:31 MULTI: multi_init called, r=256 v=256
19 14:53:31 IFCONFIG POOL: base=10.200.0.2 size=252, ipv6=0
20 14:53:31 Initialization Sequence Completed
Метки времени в начале каждой строки были сокращены для ясности.
Давайте посмотрим на этот файл журнала построчно:
- Строки 1 и 2 указывают версию и дату сборки самого OpenVPN, а также библиотеки, от которых зависит OpenVPN.
- Строка 3 говорит нам, что параметры Диффи-Хеллмана сервера были успешно инициализированы. Файл, указанный в строке конфигурации сервера
dh /etc/openvpn/movpn/dh2048.pemбыл использован для этого. - Строка 4 — это предупреждение, которое печатается почти всегда. Разработчики обсуждали, следует ли удалить эту строку или нет. В конце концов было решено, что по соображениям безопасности лучше всего распечатать это предупреждение. Если вы не слишком озабочены безопасностью, то можете игнорировать эту строку предупреждения.
- Строка 5 указывает, что канал управления защищен с использованием параметра конфигурации
tls-authи что OpenVPN смог успешно прочитать указанный файл. - Строки 6 и 7 сообщают нам, что два ключа SHA1 получены из файла
tls-authи теперь используются для подписи (хэширования) исходящего трафика и для проверки входящего трафика. - Строка 8 показывает размер буферов
Receive (R)иSend (S), которые использует OpenVPN. Эти параметры полезны только при доработке рабочей настройки, как мы увидим позже в этой главе. - Строки 9 и 10 показывают что OpenVPN смог успешно открыть устройство tun и установить глубину очереди пакетов для этого устройства равной
100. - Строки с 11 по 13 показывают настройки IPv4, которые используются для этой конфигурации сервера. Они также указывают что не были заданы параметры IPv6. Перечисленные здесь настройки являются переводом строки конфигурации сервера
server 10.200.0.0 255.255.255.0. - Строки 14 и 15 являются результатом указания
group nobodyиuser nobodyв файле конфигурации сервера соответственно. - Строки 16 и 17 показывают что OpenVPN прослушивает трафик UDP и привязан к неопределенному интерфейсу (0.0.0.0). Это результат указания
proto udpиbindв файле конфигурации сервера. - Строка 18 говорит нам, что это мультиклиентская установка с реальными и виртуальными размерами таблицы хешей
256. - В строке 19 указан диапазон адресов пула, доступных клиентам OpenVPN, которые могут подключаться к этому серверу. Это также часть перевода строки конфигурации сервера
server 10.200.0.0 255.255.255.0. - Строка 20 — это волшебная строка, которая сообщает нам, что сервер успешно запущен и инициализация завершена. Сервер теперь готов принимать соединения от входящих клиентов.
Далее мы запускаем клиент и смотрим файл журнала на стороне сервера:
[root@client]# openvpn --config basic-udp-client.conf
После этого мы также рассмотрим файл журнала на стороне клиента:
21 15:30:37 <CLIENT-IP>:39086 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:39086, sid=071ba589 7e9ff2a0
22 15:30:37 <CLIENT-IP>:39086 VERIFY OK: depth=1, C=ZA,
ST=Enlightenment, L=Overall, O=Mastering OpenVPN,
CN=Mastering OpenVPN, emailAddress=root@example.org
23 15:30:37 <CLIENT-IP>:39086 VERIFY OK: depth=0, C=ZA,
ST=Enlightenment, O=Mastering OpenVPN, CN=client3,
emailAddress=root@example.org
24 15:30:37 <CLIENT-IP>:39086 Data Channel Encrypt: Cipher
'BF-CBC' initialized with 128 bit key
25 15:30:37 <CLIENT-IP>:39086 Data Channel Encrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
26 15:30:37 <CLIENT-IP>:39086 Data Channel Decrypt: Cipher
'BF-CBC' initialized with 128 bit key
27 15:30:37 <CLIENT-IP>:39086 Data Channel Decrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
28 15:30:37 <CLIENT-IP>:39086 Control Channel: TLSv1, cipher
TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
29 15:30:37 <CLIENT-IP>:39086 [client3] Peer Connection Initiated
with [AF_INET]<CLIENT-IP>:39086
30 15:30:37 client3/<CLIENT-IP>:39086 MULTI_sva: pool returned
IPv4=10.200.0.2, IPv6=(Not enabled)
31 15:30:37 client3/<CLIENT-IP>:39086 MULTI: Learn: 10.200.0.2 →
client3/<CLIENT-IP>:39086
32 15:30:37 client3/<CLIENT-IP>:39086 MULTI: primary virtual IP
for client3/<CLIENT-IP>:39086: 10.200.0.2
33 15:30:39 client3/<CLIENT-IP>:39086 PUSH: Received control
message: 'PUSH_REQUEST'
34 15:30:39 client3/<CLIENT-IP>:39086 send_push_reply():
safe_cap=940
35 15:30:39 client3/<CLIENT-IP>:39086 SENT CONTROL [client3]:
'PUSH_REPLY,route-gateway 10.200.0.1,topology subnet,
ping 10,ping-restart 60,
ifconfig 10.200.0.2 255.255.255.0' (status=1)
Давайте пройдемся по новым записям журнала:
- Строка 21 указывает, что исходный пакет был получен от клиента с IP-адресом
<CLIENT-IP>. Обычно полный адрес IPv4 указан здесь. - Строки 22 и 23 показывают процесс проверки сертификата, предоставленного клиентом OpenVPN. Важной частью в этих строках журнала является
VERIFY-OK. - Строки с 24 по 27 перечисляют используемый шифр шифрования и дешифрования, а также хэши
SHA1, используемые для хеширования входящего и исходящего трафика в канале данных. BF-CBC (Blowfish Cipher Block Chaining) — текущий шифр по умолчанию для OpenVPN. - В строке 28 показан шифр TLS, используемый для защиты канала управления OpenVPN. Перечисленный здесь шифр очень похож на код шифрования, используемый защищенным веб-сервером.
- Строка 29 указывает, что клиент
client3с IP-адреса<CLIENT-IP>успешно прошел процесс аутентификации. - В строках с 30 по 32 указывается адрес пула, который будет назначен этому клиенту.
- Строки с 33 по 34 показывают что клиент запросил информацию о конфигурации (
PUSH REQUEST) и ответ от сервера — он отправляетpush_reply. - Строка 35 показывает содержимое сообщения
push_replyсо всей информацией о конфигурации для этого клиента. Эта строка чрезвычайно полезна при отладке установки OpenVPN, поскольку она показывает большую часть информации, которую сервер OpenVPN имеет для конкретного клиента, независимо от используемого файла конфигурации.
Аналогично, вот файл журнала клиента (запишите временные метки и сопоставьте их с временными метками из файла журнала сервера):
1 15:30:37 OpenVPN 2.3.6 x86_64-redhat-linux-gnu
[SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6]
built on Dec 2 2014
2 15:30:37 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013,
LZO 2.03
3 15:30:37 Control Channel Authentication: using
'/etc/openvpn/movpn/ta.key' as a OpenVPN static key
file
4 15:30:37 UDPv4 link local: [undef]
5 15:30:37 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
6 15:30:37 [Mastering OpenVPN Server] Peer Connection Initiated
with [AF_INET]<SERVER-IP>:1194
7 15:30:39 TUN/TAP device tun0 opened
8 15:30:39 do_ifconfig, tt->ipv6=0, tt-did_ifconfig_ipv6_setup=0
9 15:30:39 /sbin/ip link set dev tun0 up mtu 1500
10 15:30:39 /sbi/nip addr add dev tun0 10.200.0.2/24
broadcast 10.200.0.255
11 15:30:39 Initialization Sequence Completed
Давайте пройдемся по новым записям журнала:
- Строки 1 и 2 очень похожи на строки из журнала сервера.
- Строка 3 указывает, что канал управления защищен с помощью параметра конфигурации
tls-authи OpenVPN смог успешно прочитать указанный файл. - Строки 4 и 5 говорят нам что клиент не связывался с локальным IP-адресом и было установлено соединение UDP с сервером по IP-адресу
<SERVER-IP>и порту1194. - В строке 6 указано, что соединение с сервером OpenVPN, идентифицирующим себя как
Mastering OpenVPN Server, было успешно установлено. Имя сервера извлекается из общего имени (common name) сертификата на стороне сервера. - Строка 7 говорит нам, что OpenVPN смог открыть TUN-устройство
tun0. - Строки с 8 по 10 перечисляют информацию IPv4, которую сервер передал к этому клиенту и показывают, что IP-адрес и маска сети задаются с помощью стандартной команды Linux
/sbin/ip. - Строка 11 снова является волшебной строкой, которая сообщает нам, что VPN-соединение было успешно установлено и теперь мы можем безопасно общаться с сервером OpenVPN. Однако, как мы увидим позже, сообщения об ошибках могут еще не появиться.
Обнаружение неработающей установки
Установка OpenVPN может не работать по многим причинам. В следующем разделе мы рассмотрим список распространенных сбоев. Во-первых, давайте посмотрим, что отображается в файлах журналов при неудачной попытке подключения. Сбои могут возникать очень рано при попытке подключения или даже после строки Initialization Sequence Completed.
Если мы используем неправильный файл tls-auth, соединение очень рано оборвется. Это как раз и является причиной использования файла tls-auth, поскольку минимизирует нагрузку на наш сервер OpenVPN, когда мошеннические клиенты пытаются получить доступ. Клиент, который пытается подключиться без указания файла tls-auth, будет отображаться в журналах сервера следующим образом:
16:40:31 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:31 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:40:33 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:33 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:40:37 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:37 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:40:45 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:40:45 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
16:41:01 Authenticate/Decrypt packet error:
packet HMAC authentication failed
16:41:01 TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:49956
Об этом клиенте больше ничего не сообщается, поскольку сервер OpenVPN немедленно отклоняет попытку подключения. Из временных меток в файле журнала мы видим, что клиент увеличивает время задержки между попытками соединения с каждым неудачным соединением. Если в течение 60 секунд соединение не может быть установлено, клиент прервет:
TLS Error: TLS key negotiation failed to occur within 60 seconds
(check your network connectivity)
TLS Error: TLS handshake failed
Второй сбой соединения станет очевидным только после того, как соединение будет успешно инициализировано. Для этого мы указываем использование другого кодирующего шифра на одной стороне, но забываем сделать это на другой. В файле журнала клиента теперь будет отображаться следующее:
16:56:20 /sbin/ip link set dev tun0 up mtu 1500
16:56:20 /sbin/ip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
16:56:20 Initialization Sequence Completed
16:56:30 Authenticate/Decrypt packet error: cipher final failed
16:56:40 Authenticate/Decrypt packet error: cipher final failed
Таким образом, сначала соединение, кажется, было успешно установлено (строки с 1 по 3), но через 10 секунд шифрование и дешифрование канала данных не удается.
Заметка
Если бы в этом случае использовался графический интерфейс Windows, значок графического интерфейса стал бы зеленым, но сама VPN не работала бы!
Во время инициализации будет сообщено о большинстве проблем конфигурации на стороне сервера или клиента. О проблемах маршрутизации, которые встречаются гораздо чаще, OpenVPN обычно не сообщает. Следовательно, требуются различные методы устранения неполадок.
Исправление распространенных ошибок конфигурации
При настройке конфигурации OpenVPN есть несколько распространенных ошибок, которые легко допустить. Эти ошибки конфигурации можно условно разделить на четыре категории:
- Сертификат (PKI) ошибки и несоответствия
- Несоответствие опций, таких как
tunпо сравнению сtap, шифрование и сжатие - Недостаточно прав для запуска OpenVPN
- Ошибки маршрутизации
В этом разделе мы рассмотрим первые три из этих категорий. Ошибки маршрутизации будут обсуждаться позже в этой главе.
Неправильный сертификат CA в конфигурации клиента
Файл конфигурации клиента почти всегда будет содержать три строки, подобные этой:
ca ca.crt
cert client.crt
key client.key
Эти файлы сертификатов и секретных ключей были созданы в главе 3, PKI и сертификаты и широко используются в последующих главах.
Файл CA, однако, не должен указывать центр сертификации, который использовался для подписи файла сертификата клиента. Это должен быть публичный сертификат центра сертификации, который использовался для подписи сертификата сервера. Если сертификат сервера был подписан другим центром сертификации, клиент откажется подключиться к серверу. Это можно увидеть в файле журнала на стороне клиента:
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
VERIFY ERROR: depth=1, error=self signed certificate in certificate
chain: C=ZA, ST=Enlightenment, L=Overall, O=Mastering OpenVPN,
CN=Mastering OpenVPN, emailAddress=root@example.org
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
В этом случае ошибки не регистрируются на стороне сервера, так как сертификат клиента считается действительным на сервере.
Единственное, что зарегистрируется на сервере, это:
<CLIENT-IP>:42472 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:42472, sid=9a1e4a84 cdbb6926
<CLIENT-IP>:51441 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:51441, sid=17d3c89b 6999ae97
<CLIENT-IP>:43513 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:43513, sid=4609202f 4c91c23d
Это показывает последовательные попытки подключения, которые сделаны клиентом OpenVPN.
Как исправить
Убедитесь, что в файле конфигурации клиента указан правильный файл CA.
Сертификат клиента не распознан сервером
Если сертификат клиента не распознан сервером — сервер откажет в доступе к нему. Это может произойти, если используется неправильный (или мошеннический) клиентский сертификат или если клиентский сертификат был отозван, а опция crl-verify указана в файле конфигурации сервера.
Следующие записи будут отображаться в файле журнала сервера, если неизвестный клиент попытается подключиться к серверу OpenVPN:
<CLIENT-IP>:57072 TLS: Initial packet from
[AF_INET]<CLIENT-IP>:57072, sid=a175f1be 6faed111
<CLIENT-IP>:57072 VERIFY ERROR: depth=0, error=unable to get
local issuer certificate: C=NL, O=Cookbook, CN=client1,
name=Cookbook Client, emailAddress=janjust@nikhef.nl
<CLIENT-IP>:57072 TLS_ERROR: BIO read tls_read_plaintext error:
error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:
no certificate returned
<CLIENT-IP>:57072 TLS Error: TLS object -> incoming plaintext
read error
<CLIENT-IP>:57072 TLS Error: TLS handshake failed
Сервер не может проверить сертификат клиента, так как он не распознает сертификат CA, который использовался для его подписи. Поэтому отказывается разрешить этому клиенту подключаться.
На стороне клиента никакие сообщения не печатаются в файле журнала в течение 60 секунд, после чего первоначальное рукопожатие прекращается и делается новая попытка подключения:
13:24:23 UDPv4 link local: [undef]
13:24:23 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
13:25:23 TLS Error:
TLS key negotiation failed to occur within
60 seconds (check your network connectivity)
13:25:23 TLS Error: TLS handshake failed
13:25:23 SIGUSR1[soft,tls-error] received, process restarting
13:25:25 Control Channel Authentication: using
'/etc/openvpn/movpn/ta.key' as a OpenVPN static key file
13:25:25 UDPv4 link local: [undef]
13:25:25 UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
Как исправить
Убедитесь, что сертификат клиента распознается сервером. Это можно сделать либо указав соответствующий сертификат CA в файле конфигурации сервера, либо добавив сертификат CA в составленный файл сертификата CA в файле конфигурации сервера:
# cat CA1.crt CA2.crt > /etc/openvpn/movpn/ca-stack.pem
Далее используйте следующее в конфигурации сервера:
ca /etc/openvpn/movpn/ca-stack.pem
Таким образом, клиентские сертификаты, подписанные CA1.crt или CA2.crt будут приняты сервером.
Конечно, если это мошенник, пытающийся подключиться, то более подходящим решением может быть черный список IP-адресов, с которых клиент подключается.
Несоответствие сертификата клиента и приватного ключа
Если сертификат и закрытый ключ на клиенте не совпадают, то OpenVPN даже не будет пытаться подключиться к серверу. Вместо этого в файле журнала будет напечатана следующая ошибка:
Cannot load private key file /etc/openvpn/movpn/client1.key:
error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch
Error: private key password verification failed
Exiting due to fatal error
Эта проблема может возникнуть, особенно, когда сертификат и закрытый ключ обновляются; Распространенной ошибкой является использование старого приватного ключа с новым сертификатом.
Как исправить
Убедитесь, что сертификат клиента и приватный ключ совпадают. Удивительно, но для этого не существует простого в использовании инструмента. Чтобы выяснить, принадлежат ли сертификат и закрытый ключ друг другу — мы можем использовать следующие команды и искать разделы modulus:
$ openssl x509 -text -noout -in client1.crt
[…]
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b2:17:bd:31:6d:56:d9:eb:c9:09:98:e2:c1:48:
c9:6a:e4:4a:6b:54:52:ea:1e:60:94:6b:cb:5e:d5:
a1:ef:83:05:f8:cf:a4:06:df:06:ee:d6:c8:75:65:
de:a7:96:68:a1:41:d1:9d:f0:2c:84:3f:ca:b9:d2:
e8:07:af:37:48:24:69:57:4e:09:70:66:47:6c:47:
36:4d:c9:29:13:eb:ed:c1:aa:cd:36:84:3c:55:18:
bc:ce:01:34:b5:89:04:dc:09:c5:ea:f2:57:9f:c2:
f5:c1:05:dd:66:4d:11:13:05:47:46:26:1a:55:18:
51:bd:89:65:ba:0d:89:bd:ea:03:58:5e:d3:d9:96:
a5:5e:2f:5f:b9:c8:88:fc:48:95:cb:4a:b2:12:3b:
b5:ed:4c:40:4c:50:8d:1d:eb:a5:c9:c0:e6:2c:ec:
01:0a:56:ac:db:9e:e7:56:f0:06:f7:ba:b6:ac:de:
41:d4:fb:b3:d6:f5:fe:13:b4:03:81:d9:f7:7c:2e:
60:2f:9c:5a:81:eb:2e:3a:e1:c4:8b:f8:b6:8d:2d:
f7:ec:7a:f6:2c:ff:af:1c:d2:7b:58:ca:9e:d1:f4:
ed:8a:7a:35:00:97:a3:35:dd:79:02:b4:79:9a:66:
3c:5e:c8:4d:87:eb:68:5d:45:29:73:70:7f:61:28:
67:b1
$ openssl rsa -text -noout -in client1.key
Private-Key: (2048 bit)
modulus:
00:b2:17:bd:31:6d:56:d9:eb:c9:09:98:e2:c1:48:
c9:6a:e4:4a:6b:54:52:ea:1e:60:94:6b:cb:5e:d5:
a1:ef:83:05:f8:cf:a4:06:df:06:ee:d6:c8:75:65:
de:a7:96:68:a1:41:d1:9d:f0:2c:84:3f:ca:b9:d2:
e8:07:af:37:48:24:69:57:4e:09:70:66:47:6c:47:
36:4d:c9:29:13:eb:ed:c1:aa:cd:36:84:3c:55:18:
bc:ce:01:34:b5:89:04:dc:09:c5:ea:f2:57:9f:c2:
f5:c1:05:dd:66:4d:11:13:05:47:46:26:1a:55:18:
51:bd:89:65:ba:0d:89:bd:ea:03:58:5e:d3:d9:96:
a5:5e:2f:5f:b9:c8:88:fc:48:95:cb:4a:b2:12:3b:
b5:ed:4c:40:4c:50:8d:1d:eb:a5:c9:c0:e6:2c:ec:
01:0a:56:ac:db:9e:e7:56:f0:06:f7:ba:b6:ac:de:
41:d4:fb:b3:d6:f5:fe:13:b4:03:81:d9:f7:7c:2e:
60:2f:9c:5a:81:eb:2e:3a:e1:c4:8b:f8:b6:8d:2d:
f7:ec:7a:f6:2c:ff:af:1c:d2:7b:58:ca:9e:d1:f4:
ed:8a:7a:35:00:97:a3:35:dd:79:02:b4:79:9a:66:
3c:5e:c8:4d:87:eb:68:5d:45:29:73:70:7f:61:28:
67:b1
[…]
Если мы посмотрим на модуль с открытого ключа (сертификата) и приватного ключа, то увидим что они одинаковы. Таким образом, этот сертификат и приватный ключ принадлежат друг другу.
Подсказка
При сравнении модулей часто достаточно сравнить первые несколько байтов, а затем последние несколько байтов.
Несоответствие ключей auth и tls-auth
Параметры auth и tls-auth используются для аутентификации пакетов канала управления и канала данных с использованием алгоритма подписи HMAC. Значением по умолчанию для алгоритма аутентификации HMAC является SHA1, в котором используются 160-битные ключи. Для опции tls-auth нет значения по умолчанию, так как оно не требуется. Однако этот вариант рекомендуется, поскольку он обеспечивает дополнительный уровень защиты от DDoS-атак.
Если алгоритм аутентификации, указанный в конфигурации клиента и сервера, не совпадает, то сервер не позволит клиенту начать квитирование безопасности TLS. Аналогичным образом, если файлы tls-auth на клиенте и сервере не совпадают или если с обеих сторон указан неверный параметр direction — сервер также не позволит клиенту начать квитирование безопасности TLS.
Обычно в файле конфигурации сервера указывается следующая опция:
tls-auth /etc/openvpn/movpn/ta.key 0
Соответственно, на клиенте у нас есть следующая опция:
tls-auth /etc/openvpn/movpn/ta.key 1
Здесь второй параметр определяет direction из tls-auth для используемых ключей. Этот параметр не обязателен, но он позволяет OpenVPN использовать разные ключи хеширования (или HMAC) для входящего и исходящего трафика. Ключ, используемый на клиенте для подписи исходящего трафика, должен совпадать с ключом, используемым на сервере для проверки входящего трафика, и наоборот.
Если используется неверный файл ключей tls-auth или если направление опущено или указано неверно, в журнале сервера появятся следующие записи:
Authenticate/Decrypt packet error: packet HMAC
authentication failed
TLS Error: incoming packet authentication failed from
[AF_INET]<CLIENT-IP>:54377
В то же время, клиент просто попытается подключиться в течение 60 секунд, прежде чем произойдет тайм-аут.
Как исправить
Убедитесь, что используется один и тот же файл tls-auth в файлах конфигурации клиента и сервера. Также убедитесь, что параметр direction указан правильно на обоих концах (если используется вообще).
Если вы все еще не уверены, какие ключи HMAC используются для входящих и исходящих соединений, то можете увеличить детализацию файла журнала, чтобы увидеть фактические ключи, используемые как клиентом, так и сервером. Давайте добавим следующее в файлы конфигурации клиента и сервера:
Теперь обе стороны будут печатать большое количество информации о регистрации при запуске.
Строки для поиска в файле журнала на на стороне сервера:
Outgoing Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication:
HMAC KEY: 4660a714 7f4d33f9 d2f7c61a 9f1d5743 4bf9411e
Outgoing Control Channel Authentication:
HMAC size=20 block_size=20
Incoming Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication:
HMAC KEY: cd1f6d9c 88db5ec7 d7977322 e01d14f1 26ee4e22
Incoming Control Channel Authentication:
HMAC size=20 block_size=20
Строка HMAC size = 20 соответствует тому, что используется 160-битовое хеширование с помощью SHA1, так как 160 соответстуют как 20 байт.
Если на стороне клиента используются правильный файл tls-auth и параметр direction, мы найдем следующее:
Outgoing Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Outgoing Control Channel Authentication:
HMAC KEY: cd1f6d9c 88db5ec7 d7977322 e01d14f1 26ee4e22
Outgoing Control Channel Authentication:
HMAC size=20 block_size=20
Incoming Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication:
HMAC KEY: 4660a714 7f4d33f9 d2f7c61a 9f1d5743 4bf9411e
Incoming Control Channel Authentication:
HMAC size=20 block_size=20
Ключи аутентификации входящего и исходящего каналов управления зеркально отображаются на клиенте и на сервере, обеспечивая надлежащую аутентификацию TLS.
Несоответствие размера MTU
OpenVPN использует два размера максимальной единицы передачи (MTU):
tun-mtu: указывает настройку MTU адаптераtunи указывает максимальный размер каждого пакета внутри VPN-туннеля.link-mtu: указывает максимальный размер каждого пакета вне туннеля. Он включает в себя все биты заполнения, шифрования и аутентификации, но это не фактический размер пакета при передаче по сети. Фактический размер пакета не может быть определен заранее, так как размер каждого пакета может отличаться из-за алгоритмов сжатия и шифрования.
Значение по умолчанию для параметра tun-mtu составляет 1500 байт, что также является размером MTU по умолчанию для адаптера Ethernet. При нормальных обстоятельствах мы можем использовать следующую формулу для вычисления размера link-mtu из размера tun-mtu:
link-mtu = tun-mtu + constant
Здесь constant зависит от используемых параметров конфигурации. Среди параметров конфигурации, которые влияют на эту константу, мы имеем следующие:
- Варианты сжатия, такие как
comp-lzoиcomp-noadapt - Размер вектора инициализации (IV) параметра шифрования опции
cipher - Опция
fragment, добавляющая дополнительный байт - Опция
no-replay, которая удаляет байт.
Если мы видим несоответствие предупреждений link-mtu — это обычно указывает на неправильную конфигурацию в других местах наших файлов конфигурации клиента и сервера. Как вы увидите в последующих примерах, несоответствие в link-mtu между клиентом и сервером может происходить довольно часто. Обычно VPN-соединение не будет работать правильно, если имеется несоответствие link-mtu.
Подсказка
Не поддавайтесь искушению исправить само предупреждение link-mtu явно установив его. Сначала исправьте другие предупреждения, которые могли вызвать появление предупреждения link-mtu.
Параметр link-mtu также имеет большое значение при настройке VPN-соединения.
Чтобы получить максимальную производительность от VPN-соединения — нам нужно убедиться, что пакеты не фрагментируются операционной системой, поскольку это сильно повлияет на производительность. В частности, для спутниковых каналов это может привести к снижению производительности почти до полной остановки.
Если на стороне сервера указан другой размер MTU по сравнению со стороной клиента, в файлах журнала появится следующее предупреждение:
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1441', remote='link-mtu 1541'
WARNING: 'tun-mtu' is used inconsistently,
local='tun-mtu 1400', remote='tun-mtu 1500'
Это показывает, что для конфигурации default, издержки link-mtu на самом деле составляют 41 байт. Здесь мы добавили в файл конфигурации клиента:
На этом этапе VPN-соединение будет функционировать. Однако производительность будет ограничена, так как пакеты должны быть фрагментированы и повторно собраны. При такой настройке можно вызвать ошибку, отправив большие пакеты ICMP с установленным флагом not fragment . В Linux/FreeBSD это можно сделать с помощью следующей команды:
$ ping -M do -s 1450 10.200.0.2
В Windows мы используем следующее:
C:> ping -f -l 1450 10.200.0.2
Это приведет к 100-процентной потере пакета для команды ping, а также будет отображаться в файле журнала:
Authenticate/Decrypt packet error:
packet HMAC authentication failed
Это сообщение об ошибке может сначала показаться странным, но оно вызвано тем, что отправляющая сторона создала и подписала пакет, размер которого превышает 1400 байт. Клиент получает только первые 1400 байтов этого пакета и проверяет подпись, которая терпит неудачу. Затем он отклоняет пакет и распечатывает ошибку.
Как исправить
Убедитесь, что, если вы хотите использовать опцию tun-mtu — она указана в файлах конфигурации клиента и сервера.
Несоответствие шифра
Шифр кодирования, который используется для канала данных OpenVPN, можно указать, используя следующую опцию со значением по умолчанию BF-CBC:
Если в файле конфигурации клиента указан другой шифр, чем в файле конфигурации сервера, то в файлах журнала с обеих сторон будет напечатано предупреждающее сообщение, но VPN-соединение будет установлено. Однако, как только любой трафик проходит по нему, он не сможет расшифровать. Мы можем видеть это в следующем фрагменте из файла журнала на стороне клиента:
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1557', remote='link-mtu 1541'
WARNING: 'cipher' is used inconsistently,
local='cipher AES-256-CBC', remote='cipher BF-CBC'
WARNING: 'keysize' is used inconsistently,
local='keysize 256', remote='keysize 128'
[Mastering OpenVPN Server] Peer Connection Initiated
with [AF_INET]<SERVER-IP>:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
/sbi/nip link set dev tun0 up mtu 1500
/sbi/nip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
Authenticate/Decrypt packet error: cipher final failed
Три напечатанных предупреждения изначально показывают как другой тип, так и другой размер используемого шифра. Шифр Blowfish по умолчанию использует 128-битную стойкость, тогда как AES-256 — 256-битную стойкость, что приводит к немного большему зашифрованному пакету (link-mtu 1541 байт для Blowfish по сравнению с link-mtu 1557 байт для AES-256).
Как исправить
Убедитесь, что в файлах конфигурации клиента и сервера указан один и тот же шифр. Поскольку файлы журналов клиента и сервера выводят ожидаемый шифр, исправить эту ошибку довольно просто.
Заметка
В настоящее время невозможно передать шифр с сервера на клиент. Это в списке пожеланий разработчиков OpenVPN, но оно оказывает существенное влияние на код. Он не будет добавлено в OpenVPN до версии 2.4 или даже 2.5.
Несоответствие компрессии
OpenVPN имеет возможность сжимать весь VPN-трафик на лету. Для определенных типов трафика, таких как обычный веб-трафик, это может повысить производительность VPN, но добавляет дополнительные издержки к протоколу VPN. Для несжимаемого трафика эта опция фактически немного снижает производительность.
Параметр, используемый для указания сжатия в настоящее время, выглядит следующим образом:
comp-lzo [no|yes|adaptive]
Обратите внимание, что нам не нужно указывать второй параметр. Значение по умолчанию является адаптивным, если используется сжатие.
Как мы узнаем в Главе 10, Будущие направления , этот вариант будет заменен более общим вариантом compression, что позволит различные механизмы сжатия.
Можно передать опцию compression с сервера на клиент, но только если опция сжатия была указана в самом файле конфигурации клиента. Если файл конфигурации клиента не содержит такой опции, VPN-соединение не будет установлено. В файле журнала клиента будет показано следующее:
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1541', remote='link-mtu 1542'
WARNING: 'comp-lzo' is present in remote config but
missing in local config, remote='comp-lzo'
[Mastering OpenVPN Server] Peer Connection Initiated with
[AF_INET]<SERVER-IP>:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tun0 up mtu 1500
sbinip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
write to TUN/TAP : Invalid argument (code=22)
Файл журнала сервера будет содержать те же сообщения WARNING, а также будет отображать предупреждения распаковки:
client3/<CLIENT-IP>:45113 Bad LZO decompression header byte: 42
Заметка
Странно, но верно: если мы будем ждать достаточно долго, клиент будет перезагружен из-за ошибок сжатия и попытается восстановить соединение. На этот раз, однако, соединение будет успешным, так как опция comp-lzo все еще находится в памяти.
Как исправить
Убедитесь, что, если вы хотите использовать сжатие, опция comp-lzo указана в файлах конфигурации клиента и сервера. С опцией comp-lzo в файле конфигурации на стороне клиента мы теперь можем контролировать тип сжатия, используемый на стороне сервера, используя опцию push. Используйте следующее:
comp-lzo no
push "comp-lzo no"
Это отключит сжатие, но, к сожалению, это не то же самое, что вообще не указывать какой-либо метод сжатия. Надеемся, что это будет решено в будущем выпуске.
Несоответствие фрагмента
Одним из наиболее часто используемых параметров настройки является опция fragment. Подробнее об этой опции вы узнаете в разделе Как оптимизировать производительность с помощью ping и iperf далее в этой главе.
Как и параметр comp-lzo, параметр fragment указывать не нужно ни с одной стороны. Однако мы не можем указать его только с одной стороны; он должен быть настроен на обоих. Если он указан только с одной стороны, то также должен быть указан и с другой. Технически говоря, даже нет необходимости использовать одно и то же значение для параметра fragment с обеих сторон, но это рекомендуется.
Если опция fragment не указана на стороне клиента, но используется на стороне сервера, то VPN-соединение не будет работать должным образом, как видно из журнала клиента:
WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1541', remote='link-mtu 1545'
WARNING: 'mtu-dynamic' is present in remote config but
missing in local config, remote='mtu-dynamic'
[Mastering OpenVPN Server] Peer Connection Initiated with
[AF_INET]194.171.96.101:1194
TUN/TAP device tun0 opened
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
sbinip link set dev tun0 up mtu 1500
sbinip addr add dev tun0 10.200.0.2/24 broadcast 10.200.0.255
Initialization Sequence Completed
write to TUN/TAP : Invalid argument (code=22)
Опять же, это будет выглядеть так, как будто VPN подключился (Initialization sequence completed), но файл журнала заполнится сообщениями об ошибках с code=22 .
Обратите внимание, что в предупреждении фактически указан mtu-dynamic, который является устаревшим названием этой функции.
Как исправить
Убедитесь, что, если вы хотите использовать параметр fragment — он указывается в файлах конфигурации клиента и сервера.
Обратите внимание, что, в отличие от опции comp-lzo, эту функцию нельзя передать с сервера на клиент.
Несоответствие tun и tap
Наиболее распространенный вариант использования сети в стиле tap — это мостовая установка, как мы узнали из Главы 6 , Режим клиент /сервер с помощью tap-устройств. Однако не все устройства поддерживают сеть в стиле tap. В частности, все устройства Android и iOS не имеют этой возможности. Следовательно, если мы подключим такое устройство к серверу OpenVPN в стиле tap, в файле журнала сервера будут перечислены предупреждения от этих клиентов:
<CLIENT-IP>:39959 WARNING: 'dev-type' is used inconsistently,
local='dev-type tap', remote='dev-type tun'
<CLIENT-IP>:39959 WARNING: 'link-mtu' is used inconsistently,
local='link-mtu 1573', remote='link-mtu 1541'
<CLIENT-IP>:39959 WARNING: 'tun-mtu' is used inconsistently,
local='tun-mtu 1532', remote='tun-mtu 1500'
Помимо этих предупреждений сервер не обнаружит ничего о подключающихся клиентах. На клиенте аналогичные предупреждения будут перечислены вместе с этим:
WARNING: Since you are using --dev tun with a point-to-point
topology, the second argument to --ifconfig must be an IP address.
You are using something (255.255.255.0) that looks more like a
netmask. (silence this warning with --ifconfig-nowarn)
Так как мы не можем передать топологию подсети в настройке стиля tap, клиент возвращается к сети по умолчанию в стиле Net30. Этот тип сети по своей сути несовместим с сетью в стиле tap, но, кроме этого, клиент не выдает никаких предупреждений или ошибок.
Даже если бы мы (ошибочно) добавили topology subnet для подавления этого предупреждения на клиенте, VPN все равно не работал бы правильно.
Как исправить
Убедитесь, что с обеих сторон используется один и тот же тип сети (tun или tap). Если вам необходимо использовать устройства Android или iOS — вы должны настроить конфигурацию сервера в стиле tun, так как эти операционные системы не поддерживают сеть в стиле tap.
Проблемы с client-config-dir
В Главе 4, Режим клиент/сервер с TUN устройствами, мы узнали о CCD-файлах и их использование в разделе Специфичная для клиента конфигурация — файлы CCD. Файлы CCD обычно используются для подключения клиентской локальной сети к сети сервера с помощью оператора iroute.
Опыт работы со списками рассылки и форумами OpenVPN показал, что опция client-config-dir подвержена ошибкам и неправильной настройке. Вот три основные причины этого:
- Файл CCD или каталог, в котором он находится, не может быть прочитан OpenVPN после переключения на
safeпользователя, такого какnobody. - Опция
client-config-dirуказана без абсолютного пути. - Имя файла CCD указано неверно. Обычно имя файла CCD совпадает с именем из поля
/CN=сертификата клиента, без части/CN=и без какого-либо расширения!
При нормальном уровне журнала OpenVPN не жалуется, если не может найти или прочитать файл CCD. Он просто обрабатывает входящее соединение как стандартное соединение, и, таким образом, требуемый оператор iroute никогда не достигается.
Самый простой способ отладки — это временно добавить дополнительную опцию в конфигурацию сервера:
Перезагрузите сервер и клиент попытается восстановить соединение. Если сервер не может прочитать соответствующий файл CCD для подключающегося клиента — он откажет в доступе. Если это произойдет — мы знаем, что файл CCD не был прочитан. Если клиент может подключиться, то возникает другая проблема — скорее всего, проблема маршрутизации.
Другой способ увидеть что сервер OpenVPN делает с файлами CCD — это повысить уровень журнала до 4 и повторно подключить клиента, для которого указан файл CCD. Содержимое этого CCD-файла для клиента с сертификатом /CN=client1 выглядит следующим образом:
ifconfig-push 10.200.0.99 255.255.255.0
iroute 192.168.4.0 255.255.255.0
Это дает команду серверу OpenVPN назначить IP-адрес VPN 10.200.0.99 для этого клиента и для маршрутизации подсети 192.168.4.0./24 через него. Файл журнала сервера теперь содержит следующее:
<CLIENT-IP>:38876 [client1] Peer Connection Initiated with
[AF_INET]<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 OPTIONS IMPORT: reading client specific
options from: /etc/openvpn/movpn/clients/client1
client1/<CLIENT-IP>:38876 MULTI: Learn: 10.200.0.99 ->
client1/<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 MULTI: primary virtual IP for
client1/<CLIENT-IP>:38876: 10.200.0.99
client1/<CLIENT-IP>:38876 MULTI: internal route 192.168.4.0/24 ->
client1/<CLIENT-IP>:38876
client1/<CLIENT-IP>:38876 MULTI: Learn: 192.168.4.0/24 ->
client1/<CLIENT-IP>:38876
Если выделенная строка отсутствует, то файл CCD не читается. Также следующие строки, начинающиеся с MULTI: показывают как сервер OpenVPN интерпретирует строки, найденные в файле CCD. Это может быть важно для дальнейшей отладки любых вопросов iroute.
Как исправить
Если процесс сервера не может прочитать файл CCD — проверьте права доступа к полному пути к файлу, включая все подкаталоги, ведущие к нему. Убедитесь, что пользователь, указанный в параметре user, имеет разрешение на чтение всех каталогов и самого файла CCD.
Убедитесь, что в опции client-config-dir указан абсолютный путь вместо относительного. Кроме того, если мы используем опцию chroot (подробности см. в man), убедитесь, что директория client-config-dir видна внутри chroot-jail.
Используйте опцию ccd-exclusive чтобы быстро определить, может ли OpenVPN читать файл CCD. Если это возможно, то увеличьте уровень журнала на стороне сервера, чтобы увидеть, как OpenVPN интерпретирует операторы, найденные в файле CCD.
Нет доступа к устройству tun в Linux
Если OpenVPN запускается с недостаточными привилегиями или если OpenVPN настроен на удаление привилегий root и переключение на другой userid (например, nobody), то доступ к устройству tun может быть потерян. Это также может произойти, если OpenVPN используется в виртуализированной среде, такой как OpenVZ или Virtual Private Server (VPS).
Если OpenVPN запущен с недостаточными привилегиями — VPN-соединение вообще не будет установлено:
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]<SERVER-IP>:1194
[Mastering OpenVPN Server] Peer Connection Initiated with
[AF_INET]<SERVER-IP>:1194
ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted
(errno=1)
Exiting due to fatal error
Проверьте userid или используйте sudo для переключения на привилегированного пользователя перед запуском OpenVPN.
Наиболее распространенный сценарий, когда доступны недостаточные привилегии, происходит после автоматического перезапуска VPN-подключения. Рассмотрим следующий файл конфигурации клиента:
client
proto udp
remote openvpnserver.example.com
port 1194
dev tun
nobind
remote-cert-tls server
tls-auth /etc/openvpn/movpn/ta.key 1
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/client3.crt
key /etc/openvpn/movpn/client3.key
user nobody
group nobody
Это базовый файл конфигурации с двумя строками внизу. Когда мы запускаем VPN-соединение с помощью этого файла конфигурации, соединение устанавливается правильно, но выводится предупреждение:
WARNING: you are using user/group/chroot/setcon without persist-tun
-- this may cause restarts to fail
Действительно, после перезапуска VPN-соединения (например, из-за плохого сетевого соединения) перезапуск не удастся:
[Mastering OpenVPN Server] Inactivity timeout (--ping-restart), restarting
Mon Jun 1 16:51:50 2015 sbinip addr del dev tun0 10.200.0.2/24
RTNETLINK answers: Operation not permitted
Linux ip addr del failed: external program exited with error status: 2
SIGUSR1[soft,ping-restart] received, process restarting
WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Error: private key password verification failed
Exiting due to fatal error
Здесь мы видим, что OpenVPN не удалось перезапустить, так как пользователю nobody не разрешили прочитать приватный ключ, который использовался для этого соединения. Если бы мы указали пользователя с правами доступа, мы бы увидели другую ошибку:
ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted
(errno=1)
Exiting due to fatal error
Обратите внимание, что во время перезапуска OpenVPN не может завершить работу существующего устройства tun или удалить любые системные маршруты. Это также будет иметь место, если используется persist-tun, но в этом случае он будет безвредным.
Как исправить
Добавьте следующие параметры в файл конфигурации клиента, если вы также используете параметры user и/или group:
Убедитесь, что вы запускаете OpenVPN с достаточными привилегиями.
Также убедитесь, что OpenVPN имеет правильный контекст безопасности SELinux, или попробуйте запустить OpenVPN с SELinux, установленным в разрешающий или отключенный режим:
# setenforcing permissive
Отсутствие повышенных привилегий в Windows
В некоторых старых версиях программы установки OpenVPN для Windows не были заданы правильные привилегии для приложения OpenVPN GUI.
В этом конкретном примере один сервер был передан с сервера OpenVPN всем клиентам:
push "route 192.168.122.0 255.255.255.0"
В Windows Vista и выше OpenVPN требуются повышенные привилегии чтобы иметь возможность добавлять или удалять системные маршруты. Если эти привилегии отсутствуют, VPN обычно инициализируется правильно, а значок GUI становится зеленым:
Мы даже можем пропинговать сервер OpenVPN по IP-адресу его VPN-сервера. Тем не менее, файл журнала в OpenVPN GUI покажет некоторые ошибки:
Первая строка на самом деле хитрая:
Warning: cannot open -log file: .....: Access is denied
Сложность в том, что как только мы нажимаем кнопку Disconnect — журнал исчезает, так как он не может быть записан на диск! Это вызвано тем, что каталог журналов по умолчанию C:\Program FilesOpenVPNlog доступен только пользователю с повышенными привилегиями.
Последние несколько строк в файле журнала говорят нам, что OpenVPN не удалось добавить маршрут, который был передан сервером. Опять же, это связано с тем, что программа OpenVPN была запущена с недостаточными привилегиями.
Как исправить
После перезапуска OpenVPN GUI с повышенными правами (включите Запуск от имени администратора) маршрут будет добавлен правильно. Это видно из таблицы маршрутизации:
Переданный маршрут — 192.168.122.0/24 , теперь присутствует в таблице маршрутизации, используя IP-адрес VPN сервера 10.200.0.1 в качестве шлюза.
Устранение проблем с маршрутизацией
Большинство вопросов, задаваемых в списках рассылки OpenVPN и форумах пользователей, на самом деле являются вопросами маршрутизации. Настройка VPN-соединения — это одно, а интеграция в существующую сеть — совсем другое. Для новичка трудная часть состоит в том, чтобы видеть, где заканчивается OpenVPN и где начинается маршрутизация. Этот раздел предназначен в качестве пошагового руководства по устранению неполадок маршрутизации в довольно простой настройке OpenVPN.
Рассмотрим следующий план сети:
- Сеть в главном офисе должна быть доступна для дополнительного офиса и для людей, работающих из дома
- Серверы в дополнительном офисе должны быть доступны для IT-отдела главного офиса
- Люди, работающие из дома, должны иметь доступ только к компьютерным ресурсам в главном офисе
Для этого в главном офисе устанавливается сервер OpenVPN, сотрудники которого подключаются как обычные клиенты VPN, а дополнительный офис подключается как специальный клиент, раскрывая свою собственную сеть.
Рисование детальной картины
Перед созданием файлов конфигурации для OpenVPN нарисуйте подробное изображение схемы сети, включая все подсети, IP-адреса, IP-адреса шлюза, имена интерфейсов и многое другое.
Используемые публичные IP-адреса не перечислены на этом рисунке, но это рекомендуется сделать. Кроме того, подключения от людей, работающих из дома, не включены, но они будут подключаться к общедоступному IP-адресу gateway1 на предыдущем рисунке.
На gateway1 добавлено правило переадресации портов, поэтому входящий и исходящий трафик UDP через порт 1194 перенаправляется на сервер OpenVPN в 172.31.1.2:1194.
Поскольку нам необходимо раскрыть сеть в дополнительном офисе, нам также потребуется использовать файл client-config-dir с соответствующим оператором iroute.
Файлы конфигурации сервера и клиента для этой настройки уже перечислены в Главе 4, Режим клиент/сервер с tun-устройствами, с некоторыми незначительными изменениями IP-адреса. Новый набор файлов конфигурации выглядит следующим образом:
proto udp
port 1194
dev tun
server 10.200.0.0 255.255.255.0
tls-auth /etc/openvpn/movpn/ta.key 0
dh /etc/openvpn/movpn/dh2048.pem
ca /etc/openvpn/movpn/movpn-ca.crt
cert /etc/openvpn/movpn/server.crt
key /etc/openvpn/movpn/server.key
persist-key
persist-tun
keepalive 10 60
topology subnet
user nobody
group nobody
verb 3
daemon
log-append /var/log/openvpn.log
push "route 172.31.1.0 255.255.255.0"
client-config-dir /etc/openvpn/movpn/clients
route 192.168.3.0 255.255.255.0 10.200.0.1
Этот файл сохраняется как movpn-09-01-server.conf. Для клиента OpenVPN в дополнительном офисе создается специальный сертификат с именем /CN=SecondaryOffice. Соответствующий файл CCD, следовательно, имеет имя /etc/openvpn/movpn/clients/SecondaryOffice. Его содержание таково:
ifconfig-push 10.200.0.200 255.255.255.0
iroute 192.168.3.0 255.255.255.0
Для всех клиентов может быть использован конфигурационный файл basic-udp-client.conf или basic-udp-client.ovpn. Это, кстати, показывает гибкость конфигурационных файлов OpenVPN. В большинстве случаев нет необходимости изменять файлы конфигурации клиента, даже если макет сети на стороне сервера был изменен или в VPN была добавлена вторичная сеть.
Затем мы запускаем сервер OpenVPN и клиент вторичного офиса и проверяем что файл CCD выбран. Клиент VPN на вторичном офисе может пинговать сервер OpenVPN на его VPN IP-адрес и поэтому может тест пользователь дома.
Заметка
На данный момент VPN работает, а маршрутизация — нет.
Начните с середины и двигайтесь наружу
Наиболее эффективный способ устранения неполадок в этой настройке состоит в том, чтобы рассматривать канал VPN как середину, а затем постепенно выполнять пошаговую работу до тех пор, пока все части сети не будут подключены. Во-первых, есть несколько тестов для выполнения на клиенте OpenVPN в дополнительном офисе. Почти для всех тестов достаточно простой команды ping.
Обратите внимание, что нет смысла переходить ко второму тесту, если первый не пройден, и, аналогично к третьему, если второй еще не работает:
-
Может ли клиент достичь IP-адреса VPN сервера?
Это должно функционировать; в противном случае существует проблема с нашим VPN. Это может быть очень ограниченная настройка брандмауэра/iptables на сервере. IP-адрес VPN-сервера должен быть приватным (как правило RFC1918) и, следовательно, не будет маршрутизируемым через общий Интернет. -
Может ли клиент получить доступ к IP-адресу сервера в локальной сети?
Если это не работает, то, скорее всего, существует правило брандмауэра или iptables, которое блокирует доступ. Проверьте входящие правила или попробуйте отключить правила брандмауэра для отладки. -
Может ли клиент достичь IP-адреса шлюза на стороне сервера?
Если нет, то проверьте ответы на следующие вопросы:
- На сервере включена переадресация IP?
- Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа к серверу с определенного диапазона IP-адресов?
- Существует ли на межсетевом шлюзе правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо настроить на разрешение трафика, поступающего с VPN IP 10.200.0.0/24.
- Есть ли обратный маршрут на шлюзе, куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом назначения в диапазоне 10.200.0.0/24 следует пересылать на сервер OpenVPN по IP
172.31.1.2на маршрутизатореgateway1. Обратите внимание, что это обычно не так. Фактический синтаксис для добавления такого маршрута к шлюзу зависит от модели и встроенного программного обеспечения используемого маршрутизатора. - Может ли клиент связаться с другим сервером в локальной сети на стороне сервера?
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли этот сервер в локальной сети на стороне сервера правильный шлюз в качестве шлюза по умолчанию?
- Существует ли на сервере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)
Убедившись, что клиент может получить доступ ко всем машинам в локальной сети на стороне сервера — пришло время убедиться что обратное также верно. Убедитесь, что сервер OpenVPN может получить доступ ко всем машинам в локальной сети за вторичным клиентом. Тесты для выполнения очень похожи:
- Может ли сервер достичь IP-адреса VPN клиента?
Это должно функционировать; в противном случае существует проблема с нашим VPN. Это может быть очень ограниченная настройка брандмауэра/iptables на клиенте. Тем не менее, на данный момент это вряд ли будет проблемой. Но лучше перестраховаться, чем потом жалеть, так что давайте проверим это.
- Может ли сервер получить доступ к IP-адресу локальной сети клиента?
Если это не работает, то, скорее всего, существует правило брандмауэра/iptables, которое блокирует доступ. Проверьте входящие правила.
- Может ли сервер достичь IP-адреса шлюза на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Включена ли переадресация IP на клиенте вторичного офиса?
Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа на клиенте из определенного диапазона IP-адресов? - Есть ли на клиентском шлюзе правило брандмауэра, блокирующее доступ с IP-адресов не из локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо отрегулировать так, чтобы трафик приходил с VPN IP
10.200.0.1. -
Есть ли обратный маршрут на шлюзе во вторичном офисе, чтобы сообщить ему, куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом источника
10.200.0.1должны быть перенаправлены клиенту OpenVPN по IP192.168.3.17на маршрутизатореgateway2. Обратите внимание, что это обычно не так. Фактический синтаксис для добавления такого маршрута к шлюзу зависит от модели и встроенного программного обеспечения используемого маршрутизатора. Также обратите внимание, что мы разрешаем проходить только пакетам с самого сервера OpenVPN, так как все остальные клиенты не требуют доступа к его сети. - Может ли сервер OpenVPN подключиться к другому компьютеру в локальной сети на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли этот сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
- Существует ли на сервере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)
На этом этапе клиент OpenVPN в дополнительном офисе должен иметь доступ ко всем машинам в локальной сети на стороне сервера, а сервер OpenVPN в главном офисе должен иметь доступ ко всем машинам в локальной сети на стороне клиента. Есть только еще один шаг: убедитесь, что серверы в локальной сети на стороне сервера могут обращаться к серверам в локальной сети на стороне клиента и наоборот. Опять же, нужно выполнить четыре теста, начиная с компьютера в локальной сети на стороне сервера:
- Может ли эта машина достичь IP-адреса VPN клиента OpenVPN?
Это должно сработать, так как клиент может добраться до этой машины в результате четвертого теста. Однако лучше перестраховаться, чем сожалеть, так что давайте проверим это.
- Может ли эта машина получить доступ к IP-адресу локальной сети клиента?
Если это не работает, то, скорее всего, существует правило брандмауэра или iptables, которое блокирует доступ. Проверьте входящие правила на клиенте OpenVPN. Может ли сервер локальной сети достичь IP-адреса шлюза на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Включена ли переадресация IP на клиенте вторичного офиса? Существует ли правило брандмауэра/iptables, блокирующее перенаправление доступа на клиенте для определенного диапазона IP-адресов? Обратите внимание, что пакеты, поступающие с компьютера в локальной сети на стороне сервера, будут иметь адрес источника (
172.31.1.X), отличный от адреса самого сервера OpenVPN (10.200.0.1). - Есть ли на клиентском шлюзе правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (Это было бы хорошей политикой безопасности.) Если это так, то ее необходимо настроить, чтобы разрешить трафик, поступающий из диапазона IP-адресов локальной сети
172.31.1.0/24. Точно так же может потребоваться добавить правило брандмауэра на шлюзе на стороне сервера, чтобы разрешить трафик, поступающий из диапазона IP-адресов локальной сети192.168.3.0/24на стороне клиента. -
Есть ли обратный маршрут на шлюзе во вторичном офисе, для сообщения ему куда должны возвращаться пакеты, исходящие из VPN? Пакеты с адресом источника
172.31.1.0/24должен быть перенаправлен клиенту OpenVPN по IP192.168.3.17на маршрутизатореgateway2. Обратите внимание, что это обычно не так. - Может ли сервер на стороне сервера подключиться к другому компьютеру на стороне клиента?
Если нет, то проверьте ответы на следующие вопросы:
- Имеет ли сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
- Существует ли на клиентском компьютере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)
Методично прорабатывая все эти шаги, мы можем решить практически все проблемы маршрутизации. В некоторых случаях могут потребоваться более продвинутые методы отладки. Это может потребовать от нас временно отключить правила брандмауэра, поэтому перед попыткой сделать это следует соблюдать особую осторожность.
Найдите время, чтобы временно отключить брандмауэр
В списках рассылки OpenVPN было слишком много случаев, когда люди не могли заставить маршрутизацию работать, и это оказалось слишком ограничительным правилом брандмауэра или iptables. Нет необходимости отключать все правила брандмауэра, но если вы застряли на одном из двенадцати шагов, перечисленных ранее, то попробуйте отключить брандмауэр, связанный с устройством, которое вы не можете достичь или с которого вы отправляете трафик.
Заметка
Если вам нужно использовать настройку NATted, убедитесь, что вы не отключаете правила NATting.
Если ничего не помогает, используйте tcpdump
Низкоуровневый сетевой инструмент tcpdump — отличный инструмент для проверки подключения. Для устранения проблем с маршрутизацией мы можем использовать tcpdump, чтобы увидеть, поступает ли какой-либо трафик в конкретный сетевой интерфейс или покидает его, и мы можем проверить адреса источника и назначения этого трафика. На клиенте или сервере Windows может быть проще запустить Wireshark (http://www.wireshark.org), который предоставляет аналогичные функции, включая графический интерфейс.
В двенадцати шагах, перечисленных ранее, могут помочь следующие операторы tcpdump:
- Запустите
tcpdump -nnel -i tun0на сервере, чтобы увидеть, поступает ли вообще какой-либо трафик через VPN. - Запустите
tcpdump -nnel -i eth0на сервере (гдеeth0— интерфейс локальной сети используемого сервера), чтобы увидеть, поступает ли вообще какой-либо трафик на интерфейс локальной сети. Если нет, то, скорее всего, правило брандмауэра отбрасывает входящий трафик на туннельном интерфейсе. - Запустите
tcpdump -nnel -i eth0на сервере, чтобы проверить, покидает ли трафик интерфейс LAN с помощью следующего:
source address = 10.200.0.200
destination address = 172.31.1.254
Также проверьте, видим ли мы обратный трафик от серверного шлюза с обратными адресами отправителя и получателя.
- Снова запустите
tcpdump -nnel -i eth0на сервере, чтобы проверить, покидает ли трафик интерфейс локальной сети со следующими заголовками пакетов:
source address = 10.200.0.200
destination address = 172.31.1.XXX
Здесь 172.31.1.XXX — это IP-адрес компьютера, к которому мы пытаемся подключиться в локальной сети на стороне сервера. Есть ли обратный трафик?
И так далее и так далее для оставшихся шагов!
Как оптимизировать производительность с помощью ping и iperf
Получить максимальную производительность из установки OpenVPN может быть сложно. В чистой сети Ethernet стандартные настройки OpenVPN довольно хороши. Однако в гигабитных сетях требуется некоторая настройка.
Когда используется ADSL или кабельное модемное соединение, производительность также обычно довольно хорошая. Однако при определенных обстоятельствах производительность нашего туннеля OpenVPN может значительно отставать от производительности обычной сети. Эти обстоятельства почти всегда зависят от интернет-провайдера, но, тем не менее, стоит изучить как повысить производительность.
Ключом к оптимизации производительности является наличие хороших инструментов для измерения производительности. Два основных, но бесценных инструмента для измерения производительности сети — это ping и iperf. Инструмент iperf легко доступен в Linux, FreeBSD и Mac OS. Есть порты, доступные для Windows и даже Android.
Использование ping
Используя ping мы можем определить оптимальный размер MTU для нашей сети. Большинство сетевых операторов сейчас предоставляют своим клиентам MTU для Ethernet размером 1500 байт. Это приводит к полезной нагрузке пакета в 1472 байта. Остальные 28 байтов являются издержками TCP/IP для таких вещей, как адрес источника и назначения.
Однако если между клиентом и сервером существует сеть с более низким MTU, то это может значительно повысить производительность, уменьшив размер пакетов OpenVPN чуть ниже этого размера. Чтобы определить максимальный размер передачи для нашей сети, мы используем следующее:
$ ping -M do -s 1472 www.example.org
В Windows мы используем следующее:
C:> ping -f -l 1472 www.example.org
Она будет отправлять ICMP-пакеты на удаленный сервер по нашему выбору с установленным флагом not fragment, инструктируя сетевые маршрутизаторы не разбивать этот пакет на более мелкие биты. Если между клиентом и сервером есть сеть с меньшим MTU, то команда ping завершится неудачно:
$ ping -M do -s 1472 www.example.org
PING www.example.org (IP) 1472(1500) bytes of data.
ping: local error: Message too long, mtu=1480
Это говорит нам о том, что производительность будет, скорее всего, лучше, если мы используем либо фрагмент размером 1480, либо размер MTU 1480 байт вместо значения по умолчанию 1500. Обратите внимание, что это не является гарантией — только измерив фактическую производительность VPN, мы узнаем, каково влияние на самом деле.
Использование iperf
Используя iperf мы можем измерить производительность сети как внутри, так и вне VPN-туннеля. Это даст нам ценную информацию о том, сколько пропускной способности мы тратим, используя VPN-туннель.
Прежде чем измерять производительность самого VPN-туннеля, всегда пытайтесь измерить производительность нормальной сети. Будет довольно сложно заставить VPN работать лучше чем базовая сеть.
Сначала запустите iperf на сервере с помощью следующей команды:
Затем запустите iperf на клиенте с помощью следующей команды:
$ iperf -c openvpn.example.org
В кабельной сети, которая использовалась для тестирования, результат выглядит следующим образом:
Это на самом деле скорость загрузки используемого кабельного соединения. Теперь мы можем проверить производительность VPN-туннеля в той же сети:
[ 3] 0.0-10.8 sec 5.25 MBytes 4.09 Mbits/sec
Повторение измерения дает очень похожие цифры, поэтому справедливо утверждать, что производительность VPN-туннеля на несколько процентов ниже производительности базовой сети. Это на самом деле имеет смысл, так как использование VPN действительно создает некоторые накладные расходы для инкапсуляции, шифрования и аутентификации (подписи) исходных данных. Это будет трудно для дальнейшей оптимизации этой сети.
Аналогично, для скорости загрузки используемого кабельного соединения мы обнаруживаем, что производительность VPN-туннеля на несколько процентов ниже:
Производительность базовой сети показана следующим образом:
[ 4] 0.0-10.6 sec 51.6 MBytes 40.7 Mbits/sec
Теперь сравните это с VPN-туннелем:
[ 4] 0.0-10.7 sec 49.5 MBytes 39.0 Mbits/sec
Опять же, мы видим снижение производительности на 4,5 процента.
Теперь мы можем использовать параметры fragment и mssfix, чтобы посмотреть сможем ли мы повысить производительность. Там будет немного проб и ошибок для поиска подходящего места для конкретной установки. Неизвестно, какое именно место будет заранее, но метод его определения всегда один и тот же. Теперь добавьте параметры в файлы конфигурации клиента и сервера:
Делая это и изменяя X, мы получаем следующие результаты:
| X (bytes) | Download (Mbps) | Upload (Mbps) |
|---|---|---|
| 1200 | 37.9 | 3.94 |
| 1300 | 38.1 | 4.01 |
| 1400 | 38.4 | 4.04 |
| 1472 | 38.8 | 4.06 |
| 1500 | 37.6 | 3.98 |
| 39.0 | 4.09 |
Мы можем заключить, что настройки OpenVPN по умолчанию — самое приятное место для этой сети. Мы могли бы повторить это упражнение, изменив параметр tun-mtu но мы получили бы тот же результат. Однако рекомендуется сначала настроить производительность с помощью параметра fragment, поскольку этот параметр меньше влияет на пересылку пакетов.
Гигабитная сеть
Теперь мы выполним ту же процедуру в неиспользуемой сети Gigabit Ethernet. Производительность iperf базовой сети составляет 950 Мбит/с вверх и вниз.
Когда мы запускаем сервер OpenVPN с помощью конфигурации basic-udp-server.conf и подключаем к нему клиента с помощью файла конфигурации basic-udp-client.conf, мы достигаем следующей производительности iperf:
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 193 MBytes 161 Mbits/sec
[ 4] 0.0-10.0 sec 242 MBytes 203 Mbits/sec
Сейчас наблюдается явное падение производительности. К сожалению, снижение параметра fragment нам здесь не поможет. С fragment 1200 мы достигаем 149 Мбит/с и 115 Мбит/с соответственно.
В высокоскоростных сетях также имеет смысл поэкспериментировать с шифром кодирования. Оба сервера, используемые в этом примере, способны выполнять быстрые инструкции AES благодаря расширению AES-NI, которое присутствует в процессорах (Xeon E5 2620 с тактовой частотой 2 ГГц и Xeon E5 2643 с тактовой частотой 3,5 ГГц, соответственно). Давайте добавим следующее:
Теперь мы получаем следующий результат:
[ 5] 0.0-10.0 sec 316 MBytes 265 Mbits/sec
[ 4] 0.0-10.0 sec 266 MBytes 223 Mbits/sec
На способном процессоре шифр оказывает большое влияние на производительность. Поскольку OpenVPN является монолитной программой — большое количество ядер не помогает вообще. Тактовая частота процессора является доминирующим фактором. Подключив ноутбук Core i7 с тактовой частотой 3,8 ГГц к серверу Xeon E5-2643 с частотой 3,5 ГГц, мы получаем гораздо более высокую пропускную способность, используя точно такую же конфигурацию:
[ 5] 0.0-10.0 sec 707 MBytes 593 Mbits/sec
[ 4] 0.0-10.0 sec 529 MBytes 443 Mbits/sec
Таким образом, если вы хотите настроить туннель OpenVPN через высокоскоростную сеть, то лучший совет — использовать высокопроизводительные ЦП, которые поддерживают набор инструкций AES-NI. С такой настройкой можно достичь скорости сети более 500 Мбит/с в обоих направлениях.
Анализ трафика OpenVPN с помощью tcpdump
Низкоуровневый сетевой инструмент tcpdump или его аналог Wireshark с графическим интерфейсом является последним средством для устранения неполадок и производительности сети. В этом разделе мы рассмотрим процесс захвата и анализа зашифрованного сетевого трафика, создаваемого OpenVPN.
Сначала мы настраиваем нашу стандартную сеть OpenVPN, используя конфигурационные файлы basic-udp. На клиенте также работает веб-сервер. Мы будем использовать команду wget на стороне сервера, чтобы извлечь файл с веб-сервера, чтобы мы могли посмотреть на полученный сетевой трафик.
Мы запускаем tcpdump на интерфейсе Ethernet и собираем сетевой трафик, выполняя wget вне туннеля:
wget -O /dev/null https://CLIENT-IP/test1
Результирующий вывод tcpdump выглядит следующим образом (для ясности изменен):
Как мы видим, существует 13 пакетов для передачи текстового файла размером 5 КБ. Большинство из этих пакетов были использованы для установки и разрыва соединения, но есть четыре больших пакета, которые были использованы для фактической передачи данных. Первые три из четырех пакетов имеют размер 1514 байт, что является максимальным размером пакета Ethernet.
Далее мы запускаем ту же команду wget внутри туннеля. Теперь мы наблюдаем зашифрованный трафик на адаптере Ethernet:
Здесь мы видим 22 захваченных пакета. Первый и последний два пакета являются heartbeat пакетами OpenVPN и могут игнорироваться. Оставшиеся 18 пакетов являются зашифрованным эквивалентом пакетов, показанных в первом выводе tcpdump. Как мы видим здесь, длина пакета немного меньше, и особенно payload каждого пакета немного меньше: самый большой пакет payload UDP составляет 1445 байтов. Эти 1445 байт содержат зашифрованные и подписанные данные из команды wget. В нашей настройке мы не указали параметр fragment — это означает, что OpenVPN 2.3 по умолчанию будет иметь внутреннюю фрагментацию 1450 байт.
Общий размер каждого пакета никогда не превышает 1487 байтов, что довольно близко к оптимальному: обычно пакеты не должны превышать размер MTU, который составляет 1500 байтов.
Этот дамп экрана tcpdump также показывает что фрагментации не происходит, кроме как внутри OpenVPN. Это хорошо, поскольку мы хотим избежать фрагментации пакетов операционной системой или сетью для максимальной производительности. Если бы мы видели здесь фрагментацию пакетов, то это было бы отличным признаком того, что нам нужно было добавить дополнительную фрагментацию в нашу конфигурацию OpenVPN.
Давайте посмотрим, что произойдет, если мы добавим fragment 1400 в нашу настройку. Мы перезапускаем сервер и клиент и снова запускаем команду wget:
С добавленным в нашу настройку fragment 1400 мы можем видеть в выводе tcpdump что полезная нагрузка пакета теперь составляет 1397 байт, что очень близко к пределу 1400. Мы также видим, что теперь требуется больше пакетов для передачи текстового файла размером 5 КБ по туннелю, что означает снижение производительности. Из этого снимка экрана мы можем сделать вывод, что нам следует снова удалить параметр.
Из предыдущего скриншота и предыдущего мы также можем сделать вывод, что каждый пакет OpenVPN несет 42-байтовые издержки. Эти издержки частично способствуют накладным расходам, возникающим при использовании любого решения VPN. Он включает в себя всю служебную информацию, поскольку все сетевые пакеты должны содержать служебную информацию об адресе источника, адресе назначения, типе пакета, контрольные суммы, флаги и многое другое.
Наконец, давайте посмотрим на содержимое реального зашифрованного пакета OpenVPN. Для этого удобно использовать инструмент Wireshark (http://www.wireshark.org). Wireshark в основном предоставляет графический интерфейс поверх низкоуровневого инструмента tcpdump. Он может декодировать содержимое большинства типов сетевого трафика, как мы можем видеть на следующем снимке экрана (снимок экрана был анонимным по соображениям конфиденциальности):
Этот скриншот говорит нам следующее:
- Фактический размер пакета составляет 1487 байт.
- Он содержит заголовки Ethernet и IPv4, как и любой сетевой пакет в сети Ethernet.
- Это пакет OpenVPN с исходным портом 35400 и портом назначения 1194 — это означает, что он перемещается от клиента к серверу. На самом деле это один из зашифрованных пакетов при передаче файла размером 5 КБ с клиента на сервер.
- Полезной нагрузкой пакета является пакет данных OpenVPN (формат версии 1) с размером полезной нагрузки 1487 байт. Обратите внимание, что tcpdump сообщил о 1488 байтах ранее, но Wireshark может декодировать полезную нагрузку и увидеть, что первый байт является кодом операции OpenVPN.
Этот пакет будет получен OpenVPN, проверен на аутентификацию, расшифрован и распакован (если мы указали). Полученный незашифрованный пакет затем перенаправляется в таблицы маршрутизации операционной системы, которые решают, куда направить пакет. В нашем случае пакет останется на сервере и будет передан процессу wget.
Резюме
В этой главе вы познакомились с некоторыми основными приемами устранения неполадок и настройки OpenVPN. Вы также получили представление о чтении файлов журналов клиента и сервера. Вы узнали как обнаружить и исправить некоторые из наиболее часто совершаемых ошибок. Большинство вопросов в списке рассылки OpenVPN касаются проблем маршрутизации — поэтому мы обсудили обнаружение и устранение проблем маршрутизации. Наконец, существует большая разница между работающей установкой и хорошо работающей установкой, поэтому мы рассмотрели примеры того, как обнаруживать и решать проблемы с производительностью.
Конечно, OpenVPN не идеален и поэтому ваша нерабочая настройка также может быть вызвана ошибкой в самом OpenVPN. Существует несколько каналов для сообщения об ошибках, включая список электронной почты (openvpn-users@lists.sourceforge.net), канал IRC (#openvpn на freenode.net IRC) и веб-сайт форума (https://forums.openvpn.net). Вы также можете отправлять запросы на функции или списки пожеланий на эти каналы, некоторые из которых могут появиться в будущей версии OpenVPN.
В следующей главе вы узнаете, что нового можно ожидать в следующих выпусках OpenVPN. Вы также узнаете, какие в настоящее время известны проблемы с базой кодов OpenVPN, и узнаете о планах по устранению этих проблем.
I have an openvpn connection that I’m creating on a linux host to another linux host. I believe that there may be a config error or misunderstanding here. I have my client keys and server keys generated, and the CA in place, but I can’t seem to connect at all to the server. the server logs are this:
Mon Jun 29 15:38:28 2020 tls-crypt unwrap error: packet authentication failed
Mon Jun 29 15:38:28 2020 TLS Error: tls-crypt unwrapping failed from [AF_INET]70.15.128.216:55352
On the client, this is what I see:
Mon Jun 29 11:40:18 2020 TLS Error: TLS handshake failed
Mon Jun 29 11:40:18 2020 SIGUSR1[soft,tls-error] received, process restarting
Mon Jun 29 11:40:18 2020 Restart pause, 5 second(s)
Mon Jun 29 11:40:23 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Mon Jun 29 11:40:23 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Jun 29 11:40:23 2020 UDP link local: (not bound)
Mon Jun 29 11:40:23 2020 UDP link remote: [AF_INET]*.*.*.*:1194
Mon Jun 29 11:41:23 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jun 29 11:41:23 2020 TLS Error: TLS handshake failed
Mon Jun 29 11:41:23 2020 SIGUSR1[soft,tls-error] received, process restarting
Mon Jun 29 11:41:23 2020 Restart pause, 5 second(s)
Mon Jun 29 11:41:28 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Mon Jun 29 11:41:28 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Jun 29 11:41:28 2020 UDP link local: (not bound)
Mon Jun 29 11:41:28 2020 UDP link remote: [AF_INET]*.*.*.*:1194
Here is my client config file:
client
proto udp
remote *.*.*.* 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
dhcp-option DNS 8.8.8.8
verb 3
and my server config:
local *.*.*.*
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt ta.key 0
topology subnet
server 10.1.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route *.*.*.* 255.255.255.255" #api
push "route *.*.*.* 255.255.255.255" #rabbitMQ
push "route *.*.*.* 255.255.255.255" #ui
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify
client-config-dir ccd
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log
I just want to confirm that the server is running and is accepting connections. I’m pretty sure my connection request is just malformed. The question is, what is malformed? just an FYI, I’ve used this tutorial to get me going thus far: Install OpenVPN on Debian 10
I’ve also ensured that the client.key file is 400 for permissions.