Меню

Ошибка tls error tls handshake failed

I am configuring OpenVPN 2.3.6-1 on my Arch Linux server in order to encrypt SMB traffic over the public Internet. When I test the setup on one of my Linux virtual machine clients, I get the error: TLS Error: TLS handshake failed.

I quickly read (OpenVPN on OpenVZ TLS Error: TLS handshake failed (google suggested solutions not helping)) and tried to switch from the default UDP to TCP, but that only caused the client to repeatedly report that the connection timed out. I also tried disabling the cipher and TLS authentication, but that caused the server to fail with Assertion failed at crypto_openssl.c:523. In both instances, the required changes were made to both the client and server configurations.

I have been following the instructions at (https://wiki.archlinux.org/index.php/OpenVPN) to set up OpenVPN and the instructions at (https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts) to create the keys and certificates. The only deviations I have made from these instructions have been specifying my own computers’ names and their corresponding key/certificate file names.

See also my original question about securing SMB traffic over the Internet: (Simple encryption for Samba shares)

Can anybody explain how I can solve this issue?

Details:

Server: Arch Linux (up to date) connected directly to gateway via ethernet cable. No iptables.

Client: Arch Linux (up to date) virtual machine on VirtualBox 4.3.28r100309 Windows 8.1 host, bridged network adapter. No iptables. Windows Firewall disabled.

Gateway: Port forwarding for port 1194 enabled, no firewall restrictions.

Here are the configuration files on the server and client, respectively. I created these according to the instructions on the Arch Wiki.

/etc/openvpn/server.conf (Non-comment lines only):

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

/etc/openvpn/client.conf (Non-comment lines only):

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

Here are the outputs of running openvpn on the machines with the above configurations. I started the server first, then the client.

The output of openvpn /etc/openvpn/server.conf on the server:

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

The output of openvpn /etc/openvpn/client.conf on the client:

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

Источник

#################################################
# 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

Источник


0

1

Достался мне роутер под ubuntu 14.04.

Копирую на него 100% рабочий конфиг с серверов под CentOS.
Пытаюсь подключиться — не хочет «TLS handshake failed».
Причём в логе на сервере нет записей о том, что я пытался к нему подключиться.

Время на серверах совпадает. Сертификаты, ключи правильные — созданы сегодня утром. Порт на бубунте открыт. В CentOS контекст у файлов выставлен корректный.

Куда ещё посмотреть, что ещё проверить — не могу сообразить. Посоветуйте, пожалуйста. Может глаз замылился, проблема на поверхности?

server.log: 

Sat Jul 23 21:31:11 2016 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec  1 2014
Sat Jul 23 21:31:11 2016 Diffie-Hellman initialized with 2048 bit key
Sat Jul 23 21:31:11 2016 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Sat Jul 23 21:31:11 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jul 23 21:31:11 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jul 23 21:31:11 2016 Socket Buffers: R=[212992->131072] S=[212992->131072]
Sat Jul 23 21:31:11 2016 TUN/TAP device tun1 opened
Sat Jul 23 21:31:11 2016 TUN/TAP TX queue length set to 100
Sat Jul 23 21:31:11 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jul 23 21:31:11 2016 /sbin/ip link set dev tun1 up mtu 1500
Sat Jul 23 21:31:11 2016 /sbin/ip addr add dev tun1 10.0.1.1/24 broadcast 10.0.1.255
Sat Jul 23 21:31:11 2016 GID set to nogroup
Sat Jul 23 21:31:11 2016 UID set to nobody
Sat Jul 23 21:31:11 2016 UDPv4 link local (bound): [undef]
Sat Jul 23 21:31:11 2016 UDPv4 link remote: [undef]
Sat Jul 23 21:31:11 2016 MULTI: multi_init called, r=256 v=256
Sat Jul 23 21:31:11 2016 IFCONFIG POOL: base=10.0.1.1 size=252, ipv6=0
Sat Jul 23 21:31:11 2016 IFCONFIG POOL LIST
Sat Jul 23 21:31:11 2016 Initialization Sequence Completed

client.log:

Sat Jul 23 22:31:51 2016 OpenVPN 2.3.11 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on May 10 2016
Sat Jul 23 22:31:51 2016 library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
Sat Jul 23 22:31:51 2016 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Sat Jul 23 22:31:51 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jul 23 22:31:51 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jul 23 22:31:51 2016 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Jul 23 22:31:51 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Sat Jul 23 22:31:51 2016 UDPv4 link local: [undef]
Sat Jul 23 22:31:51 2016 UDPv4 link remote: [AF_INET]8.8.8.8:1194
Sat Jul 23 22:32:51 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Jul 23 22:32:51 2016 TLS Error: TLS handshake failed
Sat Jul 23 22:32:51 2016 SIGUSR1[soft,tls-error] received, process restarting
Sat Jul 23 22:32:51 2016 Restart pause, 2 second(s)
Sat Jul 23 22:32:53 2016 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Jul 23 22:32:53 2016 UDPv4 link local: [undef]
Sat Jul 23 22:32:53 2016 UDPv4 link remote: [AF_INET]8.8.8.8:1194
Sat Jul 23 22:33:53 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Jul 23 22:33:53 2016 TLS Error: TLS handshake failed
Sat Jul 23 22:33:53 2016 SIGUSR1[soft,tls-error] received, process restarting

server.conf

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0
crl-verify crl.pem
tls-server
tls-timeout 120
cipher AES-256-CBC
server 10.0.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
ccd-exclusive
client-to-client
topology subnet
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/server-status.log 1
status-version 3
log-append /var/log/openvpn/server.log
verb 3
mute 20

client.conf

client
dev tun
proto udp
remote 8.8.8.8 1194
resolv-retry infinite
float
nobind
keepalive 10 120
persist-key
persist-tun
comp-lzo
cipher AES-254-CBC
ca ca.crt
dh dh.pem
cert client.crt
key client.key
tls-client
tls-auth ta.key 1
remote-cert-tls server
user nobody
group nobody
status /var/log/openvpn/client-status.log 1
status-version 3
log-append /var/log/openvpn/client.log
verb 3
Источник

Fixes for the SSL/TLS handshake failed error for both internet users and site owners

It’s time for another technical article. Today, we’re going to discuss the SSL/TLS handshake failed error and the ways to fix it. Like many SSL error messages, the SSL handshake error can be triggered from both the client-side and the server-side, so sometimes it can be fixed by regular internet users and other times it’s indicative of a configuration issue on the website’s part.

Regardless of its origins, this can be a frustrating SSL error because it prevents you from making a secure connection with the website you’re attempting to access. This is bad for users and site owners alike — for the site owners because it drives away business (potentially straight into the arms of your competitors).

We’ll get into what the SSL/TLS handshake is, then we’ll cover the reasons for the SSL/TLS handshake failed error and what you can do to fix it.

Let’s hash it out.

At the beginning of every HTTPS connection, the client (the internet user’s web browser) and the server (hosting the website) must go through a series of checks — for lack of a better term — to authenticate one another and determine the parameters of the encrypted connection. This is known as the TLS handshake, although some within the industry still refer to it as an SSL handshake.

(SSL is no longer technically accurate since it’s a deprecated protocol. However, we’ll still refer to it as such throughout the article because people still commonly use the term. So, you’ll see “SSL handshake” and “TLS handshake” used interchangeably throughout the content, but just know that we’re still talking about the TLS handshake.)

The TLS handshake process accomplishes three things:

  • Authenticates the server as the rightful owner of the asymmetric public/private key pair.
  • Determines the TLS version and cipher suite that will be used for the connection.
  • Exchanges the symmetric session key that will be used for communication.
TLS handshake failed

If you simplify public key infrastructure (PKI) —which serves as the infrastructure for the entire SSL/TLS ecosystem — it’s really about secure key exchange. During an HTTPS connection, the communication is actually done with symmetric session keys — generally 256-bit advanced encryption standard (AES) keys — that are generated on the client side of things. When a symmetric key is generated, both parties get a copy. They can use it to encrypt and decrypt the data that transmits between them.

While 256-bit encryption is still sufficiently robust, the real security is at the gate where a much larger, much stronger private key (generally a 2048-bit RSA key) helps handle the authentication portion of the connection. Authentication is important because the client wants to make sure it’s connecting with the correct party. That’s essentially what the SSL/TLS handshake is for — it’s a set of checks where:

  • The client and server authenticate one another,
  • They determine the parameters of the HTTPS connections (what cipher suite will be used), and then
  • The client encrypts a copy of the session key and sends it to the server for use during the connection.

Historically, the SSL/TLS handshake has added a small bit of latency to a connection, which is what led to the claim that HTTPS slows down your website. That latency has been addressed in more recent versions of the TLS protocol though, so that’s almost entirely untrue today — especially with HTTP/2 and HTTP/3.

Currently, there are two different versions of the TLS handshake in use: TLS 1.2 and TLS 1.3.

The SSL/TLS Handshake Process in TLS 1.2 vs TLS 1.3

TLS 1.2 uses a handshake that makes multiple roundtrips between the client and the server.

TLS 1.2 Handshake; TLS 1.3 handshake

Wondering how the TLS handshake process works? We’re not going to go step-by-step, but essentially:

  • The client and server ping one another.
  • The server presents its SSL/TLS certificate.
  • The client authenticates the certificate authority (CA)-signed certificate.
  • They exchange a list of supported cipher suites and agree on one, then key exchange occurs.

This process involves a lot of steps — all of which occur in a short amount of time.

TLS 1.3, on the other hand, has refined the TLS handshake to a single round-trip.

TLS 1.3 Handshake

Obviously, this cuts down on the time that it takes for a connection to start — we’re talking milliseconds here so maybe not noticeably (except at scale) — and makes everything more efficient. TLS 1.3 also allows 0-RTT resumption, which streamlines subsequent connections to a TLS 1.3-enabled website even more.

But, given the number of moving parts in a TLS handshake, there’s plenty that can go wrong if a website or a device are misconfigured. A couple years ago we wrote about fixing TLS handshakes failed errors on Firefox, but these errors are far more universal than that. So now let’s talk about what can go wrong with the TLS handshake and what need to be done to fix it.

Taking a Closer Look at the SSL/TLS Handshake


In Everything Encryption
By Patrick Nohe

There’s a lot going on underneath the hood when you connect to a website via HTTPS. First and foremost, everyone needs to… shake hands?!

Read more

An Overview of SSL/TLS Handshake Failed Errors

To make this article a little bit easier to follow, we’re going to put all of the possible causes for SSL/TLS handshake failed errors (SSL handshake errors) and who can fix them. After that, we’ll have a dedicated section for each where we’ll cover how to fix them.

CAUSE DESCRIPTION OF THE TLS HANDSHAKE ERROR FIX
Incorrect System Time Client device has the incorrect time & date. Client
Browser Error A browser configuration is causing the error. Client
Man-in-the-Middle A third party is intercepting/manipulating connection. Client
Protocol Mismatch The protocol used by client is not supported by server. Server
Cipher Suite Mismatch Cipher suite used by client is not supported by server. Server
Incorrect Certificate
  • URL host name doesn’t match host name on server certificate.
  • Incomplete/invalid certificate chain presented to client.
  • Revoked/expired SSL/TLS certificate sent to the client or server.
  • Replacement of self-signed certificates in internal networks has caused a path-building error.
 Server
SNI-Enabled Server Client can’t communicate with SNI-enabled server. Server

Now, let’s dive into fixing these SSL handshake failed errors. Then we’ll finish with a couple of things you should definitely not do from the client-side to try and fix this mistake.

TLS handshake failedSSL/TLS Handshake Failed — Client Errors

When a handshake fails, it’s usually something going on with the website/server and its SSL/TLS configuration. This results in that pesky SSL/TLS handshake error.

Really, it’s just TLS configuration at this point as support for SSL 3.0 has been almost entirely deprecated. (SSL Labs reports that only 4.6% of sites still support the SSL 3.0. protocol as of August 2020.)

However, there are a few contexts in which a client-side error can cause the SSL/TLS handshake failed error. And a lot of them may seem pretty trivial — things like making sure your system time is correct and your browser is current.

But, as we discussed, there are a lot of moving parts with the TLS handshake, and sometimes even the tiniest hiccup can cause the whole thing to go kaput.

So, let’s go over a few of the client-side fixes for this issue.

Incorrect System Time

TLS handshake failed

I’m really not sure why anyone would take their system clock off of the universal time option, but apparently it happens. Maybe you want to abide your own personal clock like some kind of psychopath or maybe the setting just got accidentally changed — it’s none of my business, really — but if your system time is wrong it can cause problems with TLS handshake. As a result, this can cause the SSL/TLS handshake failed error.

That’s largely owing to the fact that SSL/TLS certificates have finite lifespans, so time is important. In fact, in some rather high profile cases of certificate expiration — like with the Oculus Rift VR system — internet users have even purposely set their system times back to a date before said expiration so that they could still connect. (More recent examples of notable certificate expiries affecting everything from COVID-19 reporting to streaming music services.)

Obviously, don’t change your system time. If you’re still getting the SSL/TLS handshake failed error and your system time is correct, the issue is originating somewhere else.

TLS handshake failed errorBrowser Error

This isn’t like a browser error — this is literally your browser making a mistake. Sometimes your browser can become misconfigured, or a plugin can cause things to work a little bit differently and it results in problems connecting to otherwise legitimate websites. While diagnosing exactly what needs to be tweaked on your current browser may be a little bit more difficult, narrowing the issue down to a specific browser error is pretty simple: just try another browser and see what happens.

If you’re using Google Chrome, switch to your OS’s native browser like Apple Safari or Microsoft Edge. Otherwise, hop on Mozilla Firefox (my preference) if you have it.

Basically, just switch it up and try connecting to the site. If you get the same SSL/TLS handshake failed error, then you know it’s not the browser causing the issue. But if you can connect, now you know something is up with your plugins or settings.

Related: Secure Your Website with a Comodo SSL Certificate. 

The fastest way to fix this SSL/TLS handshake error-causing issue is just to reset your browser to the default settings and disable all your plugins. From there, you can configure the browser however you want, testing your connection with the site in question as you tweak things. This may take a little bit of time, but it’s really the only way to address the issue if your browser is misconfigured or is making mistakes.

Man-in-the-Middle

A man-in-the-middle (MITM) is typically presented as a nefarious hacker that’s attempting to steal information or cause harm. That’s actually not always the case. A lot of programs and devices intercept traffic for inspection or some other non-malicious purpose like load balancing, and then send it along to the application server. This process technically constitutes a MITM, too.

SSL offloading

Unfortunately, sometimes issues with those devices can cause a TLS handshake to fail. It could be something like a network firewall preventing the connection, or it could be a configuration on an edge device on the server-side network. So, this issue can actually be either a client- or server-side fix depending on the scenario.

Here’s the thing: If this issue is client-side, you risk exposing yourself if you jigger with the settings on your antivirus or VPN. There should generally be a way to whitelist or create an exception for the site in question. But NEVER drop your firewall or your antivirus just connect to a website. If the issue is server-side, it’s likely a configuration issue on an edge device.

Recently, Ross Thomas, was telling me about a device he dealt with once that was intercepting traffic and affixing a small data string to indicate it had passed inspection. That was causing the data to fail check-sum hashes and could also potentially mess with authentication.

Again, there are too many possible origins for me to narrow it down to a single fix here, but if you have a device inspecting or intercepting traffic, start there.

SSL/TLS Handshake Failed: Server-Side Errors

The majority of the time SSL/TLS handshake failures are the result of server-side issues. Some of these are easy to fix, some of them are a little more involved, and some might not be worth fixing at all.

Let’s take a look.

Protocol Mismatch

This is actually an error that can occur on both the client- and the server-side, and it can actually be something that’s not worth fixing depending on the context. When it comes to supporting protocols and ciphers, the most important piece of wisdom is: always move forward, never move backwards.

TLS 1.2 came out more than a decade ago, yet there are still a small segment of websites that don’t support it. In 2018, TLS 1.3 was finally published as RFC 8446 by the IETF. As of August 2020, Qualys SSL Labs reports that 98.4% of the Alexa top 150,000 sites support TLS 1.2 and 32.8% support TLS 1.3.

In the other direction, PCI DSS requirements mandate that all websites that collect payment card information end support for SSL 3.0 and TLS 1.0. And the four major browser makers — Google, Firefox, Apple & Microsoft — jointly announced TLS 1.1 would be deprecated by 2020.

If you’re getting the SSL/TLS handshake failed error as a result of a protocol mismatch, it means that the client and server do not have mutual support for the same TLS version. Here’s an example:

CLIENT SERVER
Supports TLS 1.0, TLS 1.1 Supports TLS 1.2

In this scenario, there is no mutually supported TLS protocol and the server likely isn’t supporting backwards versioning. And before you ask, no, the server shouldn’t fix this. In this example, the client should upgrade their browser, or, in the case that the browser is current — configure it to support the latest TLS versions.

At this point, you should be using TLS 1.2 or TLS 1.3. If you’re not, add support for them. But remember, never go backwards.

TLS handshake failedCipher Suite Mismatch

This is incredibly similar to the protocol mismatch — just a bit more granular. SSL/TLS isn’t just one algorithm that handles everything (though ECC is close), it’s actually a collection of algorithms that serve different functions and work in conjunction to make up SSL/TLS.

SSL/TLS is like the Megazord and the cipher suite is like the Power Rangers.

What? You try to make a grouping of algorithms sound more interesting.

Anyway, while the cipher suites used by TLS 1.3 have been refined, traditionally a Cipher Suite has had algorithms that handle:

  • Asymmetric public key encryption
  • Symmetric session key encryption
  • Key generation
  • Signature hashing

Different industries and government agencies have different encryption standards that suggest different cipher suites. Generally, there’s a lot of overlap there, and most websites support a handful of cipher suites so that clients have several options and will generally be able to find a mutually agreeable cipher. Obviously, the odds of successful negotiation would decrease substantially if a site only supported a single cipher suite.

Oftentimes this can happen within a network if you’re performing SSL bridging, where an edge device receives and decrypts HTTPS traffic, then re-encrypts it so send along to the application server. If the edge device and the application server don’t share a mutually supported cipher suite, it will cause errors.

Much like with protocol versions, you should only ever move forward with cipher suites — never backwards. Remember, when a protocol version or cipher suite is deprecated it’s not because the industry is trying to be difficult — it’s because a vulnerability has been found or is imminent. So, going backwards only makes your connections potentially less safe.

Incorrect SSL/TLS Certificate

There are a number of different things that can make a browser view an SSL/TLS certificate as incorrect and prevent the handshake from completing successfully. We’ll go through each in the next sub-sections. It’s also worth noting that, sometimes, these issues will materialize into a different error on the client-side as opposed to the SSL/TLS handshake failed message. Generally, something along the lines of the website not providing a secure connection. But on a technical level that error is occurring as the result of a failed handshake.

ISSUE DESCRIPTION
Host Name Mismatch The CN in the certificate does not match the host name.
Incorrect Certificate Chain The certificate chain is missing intermediates.
Expired/Revoked Certificate The server presented an expired, revoked or untrusted certificate.
Self-Signed Replacements (Internal Networks) Certificate replacements confused path.

Incorrect Host Name

This used to be a problem with WWW and non-WWW versions of websites. However, this issue has largely been mitigated by the certificate authority community allowing one to be listed as a SAN (subject alternative name) domain free of charge. This issue can usually be fixed by re-issuing the certificate or sometimes by using a wildcard certificate.

Incorrect Certificate Chain

We went in-depth on certificate chains, roots and intermediate certificates in a previous article, but here’s the quick version. The trust model in SSL/TLS and PKI in general relies on meticulously-curated root programs. These are collections of trusted CA root certificates that literally live on a computer system.

ROOT PROGRAM USED BY
Mozilla Firefox Desktop and Mobile
Google Android OS
Apple iOS, macOS
Microsoft Windows

These CA roots are invaluable — so much so that rather than risk issuing directly from them, certificate authorities spin up intermediate roots and sign SSL/TLS leaf (end-user) certificates with those intermediates. Here’s where the chain starts to come in. The Root CA certificate is used to digitally sign the intermediate roots. Those intermediates are used to sign other intermediates or end-user, leaf SSL/TLS certificates.

difference between root and intermediate certificate

When a browser receives an SSL/TLS certificate, one of the things it does to check its authenticity is follows the signatures. It looks at the digital signature on the SSL/TLS certificate and follows it back to the intermediate root that signed it. Then it looks at that intermediate’s digital signature and follows it back to the certificate that signed the intermediate. So on and so forth until, eventually, it reaches one of the root CA certificates in its trust store.

If it can’t do this, the certificate chain is oftentimes incomplete, meaning that the browser couldn’t locate one of the intermediates and the SSL/TLS handshake failed. To remedy this, you’re going to need to find and install the missing intermediate certificate. Depending on which CA you purchased your certificate from, they should have their intermediates available on their website.

Expired/Revoked Certificates

While certificate revocation in the current SSL/TLS ecosystem leaves a lot to be desired, there are still some contexts where a browser will see that a certificate has been revoked and will fail a handshake on that basis. More often, it’s as a result of an expired certificate. SSL/TLS certificates are only valid for a set amount of time.

TLS handshake failed

RELATED: This is what happens when your SSL/TLS certificate expires

SSL/TLS certificate expiration occurs for a few potential reasons (depending on whom you ask):

  • To ensure that validation information stays accurate.
  • To proliferate protocol and cipher updates more quickly.
  • To eliminate the need for certificate revocation lists (CRLs).
  • To combat the possibility of cybercriminals from breaking standard encryption algorithms (although this is virtually impossible without quantum computing).

As of Sept. 1, 2020, max validity for an SSL/TLS certificate is now one year (398 days to be exact). That means you need to be swapping out certificates regularly. If you forgot to before one expired, that’s probably why the SSL/TLS handshake failed. Just get a valid certificate issued and install it — that should solve your problems.

Self-Signed Replacements

On the public internet, a self-signed certificate will return an error 100% of the time if the client hasn’t manually installed your private root in their root store. But, on internal networks self-signed certificates are fairly common. And if you swap them out enough, that can cause problems.

Most browsers will cache certificates so that upon return to a website it makes the handshake go faster. But if you’re generating new certificates at regular intervals, continuously adding all of those newly-generated certificates to the local database is going to cause confusion. Eventually, the browser will struggle with path-building and crash.

In the past, Firefox has struggled with this considerably — to the point where 7-8 certificate re-issues will cause significant latency, and 10 or more can cause the handshake to take upwards of 30 seconds.

SNI-Enabled Servers

This is more of an internal issue that exists between devices, but sometimes a client communicating with a server name indication server when it’s not SNI-enabled can be why the SSL/TLS handshake failed.

The first thing you’ll need to do is identify the host name and the port number of the server in question and make sure it’s SNI-enabled as well as that it’s communicating everything it needs to be. Again, this is usually less of a public-facing issue, but it can be the cause from time to time internally.

What Not to Do – Don’t Reward Bad SSL/TLS Implementations

A lot of the time website owners don’t want to make a change until there’s a problem they can’t ignore. While there are a few client-side fixes for the SSL/TLS handshake failed error, it’s generally going to be a server-side issue.

That means as a regular internet user, your options are limited when it comes to mitigating SSL/TLS handshake errors. The best thing to do is to inform the site owner of the problem and wait for them to fix it. If they don’t, it might be wise just to stop using the website.

There are some things you definitely should never do to reach a website:

  • Don’t drop your firewall. You can usually whitelist a website, but don’t drop your firewall. Ever.
  • Don’t disable your antivirus. Again, whitelist if possible, but keep it on and updated.
  • Don’t connect via HTTP or click through interstitial warnings. This is bad any way you look at it and can result in a lot of issues.

If the website can’t offer a safe browsing experience, you shouldn’t be visiting it. Eliminating the SSL/TLS handshake error isn’t worth jeopardizing your security.

Note: This article on TLS handshake failed errors (SSL handshake failed errors) was originally written by Patrick Nohe on Nov. 14, 2018. It was updated and re-published by Casey Crane as a “rehash” of the content on Sept. 3, 2020.

As always, leave any comments or questions below…

Hashed Out by The SSL Store is the voice of record in the SSL/TLS industry.

Источник

Обычно довольно легко настроить 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 по IP 192.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 по IP 192.168.3.17 на маршрутизаторе gateway2. Обратите внимание, что это обычно не так.

  • Может ли сервер на стороне сервера подключиться к другому компьютеру на стороне клиента?

Если нет, то проверьте ответы на следующие вопросы:

  • Имеет ли сервер в локальной сети на стороне клиента надлежащий шлюз в качестве шлюза по умолчанию?
  • Существует ли на клиентском компьютере правило брандмауэра, блокирующее доступ с IP-адресов, не относящихся к локальной сети? (На самом деле это будет хорошая политика безопасности!)

Методично прорабатывая все эти шаги, мы можем решить практически все проблемы маршрутизации. В некоторых случаях могут потребоваться более продвинутые методы отладки. Это может потребовать от нас временно отключить правила брандмауэра, поэтому перед попыткой сделать это следует соблюдать особую осторожность.

Найдите время, чтобы временно отключить брандмауэр

В списках рассылки OpenVPN было слишком много случаев, когда люди не могли заставить маршрутизацию работать, и это оказалось слишком ограничительным правилом брандмауэра или iptables. Нет необходимости отключать все правила брандмауэра, но если вы застряли на одном из двенадцати шагов, перечисленных ранее, то попробуйте отключить брандмауэр, связанный с устройством, которое вы не можете достичь или с которого вы отправляете трафик.

Заметка

Если вам нужно использовать настройку NATted, убедитесь, что вы не отключаете правила NATting.

Если ничего не помогает, используйте tcpdump

Низкоуровневый сетевой инструмент tcpdump — отличный инструмент для проверки подключения. Для устранения проблем с маршрутизацией мы можем использовать tcpdump, чтобы увидеть, поступает ли какой-либо трафик в конкретный сетевой интерфейс или покидает его, и мы можем проверить адреса источника и назначения этого трафика. На клиенте или сервере Windows может быть проще запустить Wireshark (http://www.wireshark.org), который предоставляет аналогичные функции, включая графический интерфейс.

В двенадцати шагах, перечисленных ранее, могут помочь следующие операторы tcpdump:

  1. Запустите tcpdump -nnel -i tun0 на сервере, чтобы увидеть, поступает ли вообще какой-либо трафик через VPN.
  2. Запустите tcpdump -nnel -i eth0 на сервере (где eth0 — интерфейс локальной сети используемого сервера), чтобы увидеть, поступает ли вообще какой-либо трафик на интерфейс локальной сети. Если нет, то, скорее всего, правило брандмауэра отбрасывает входящий трафик на туннельном интерфейсе.
  3. Запустите tcpdump -nnel -i eth0 на сервере, чтобы проверить, покидает ли трафик интерфейс LAN с помощью следующего:
source address      = 10.200.0.200
destination address = 172.31.1.254

Также проверьте, видим ли мы обратный трафик от серверного шлюза с обратными адресами отправителя и получателя.

  1. Снова запустите 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, и узнаете о планах по устранению этих проблем.

Источник

SSL/TLS Handshake process begins when your browser sends a request to make a secure connection with a web server like Apache. Though sometimes an error occurs, and one of the commonly faced SSL/TLS errors is an “SSL Handshake Failed error,” or also known as “SSL Handshake Failed.”

If you’re not having the right answer to what this SSL error means, then no worries, we’ve got your back. Read further and know what’s this SSL Handshake Failed Error, why it occurs, and how to fix the SSL/TLS Handshake Failed Error.

What Does SSL/TLS Handshake Failed Mean and What Causes It?

The SSL Handshake Failed error occurs when there’s a protocol mismatch. In other words, whenever the client and the server do not have mutual support for the same SSL/TLS version, it shows this SSL/TLS Handshake failed error message.

Once the user sends the secure connection request to the web browser, the browser is expected to send a public key to your computer, which is automatically verified against a list of CAs. And, the computer generates a key and encrypts it with the public key after receiving the certificate.

This SSL/TLS Handshake Failed Error occurs whenever the OS hasn’t granted the read access to the OS, ultimately preventing the complete authentication of the webserver, which indicates that the browser’s connection with the web server is not secure.

Some Reasons That Causes SSL/TLS Handshake Failed Error

CAUSE DESCRIPTION Who Can Fix It?
Incorrect System Time The date and time of the client device are not correct. Client
Browser Error Configuration of a browser is causing the error Client
Main-in-the-middle The connection is manipulated or intercepted by a third-party. Client
Protocol Mismatch The server doesn’t support the protocol used by the client. Server
Cipher Suite Mismatch The server doesn’t support the cipher suite used by the client. Server
SNI-Enabled Server SNI-enabled servers can’t communicate with the client. Server
Incorrect Certificate
  • The name on the certificate doesn’t match with the hostname in the URL.
  • Incomplete or invalid certificate chain.
  • The SSL/TLS Certificate is expired or revoked.
 Server

Now, let’s see each of the reasons for the SSL/TLS Handshake Fail error with the solution in detail.

Here’s the Client-Side Errors and its Solution

Whenever an SSL/TLS Handshake fails, it’s mostly due to certain things going on with the server, website, and the configuration of its installed SSL/TLS.

Presently the culprit is TLS configuration as support for SSL 3.0 is deprecated. However, there’s a distinct possibility that a client-side error can be the reason behind the SSL/TLS Handshake Failed error. And, some of the common ones are like incorrect system time or browser updates.

Let’s see some of the common causes of SSL Handshake fail error in detail.

1. Incorrect System Time

Not always happen, but sometimes the system clock differs from the actual time. Maybe you did it intentionally, accidental change of settings, or any other reason. It’s a fact that SSL/TLS certificates come with a specific validity period, so the date and time of the system is equally important.

So, the solution is to change the system time and date to correct one, if the system clock is not showing the right time and date. But again, there’s no need to change your system time if it’s correct, as it’s likely that the cause of the error is not the System time.

2. Browser Error

It’s not any browser error. But, SSL/TLS Handshake Failed Error is due to some mistakes made by your browser. Sometimes it happens, that your browser might be causing this error due to certain misconfiguration or a plugin can make sure things to work differently, which results in problems while connecting with the legitimate websites. While analyzing what’s exact needs to be fixed is not that easy on your current browser. So, you should try using a different browser.

For instance, if you’re using Google Chrome, then try using Mozilla Firefox or any other such as Apple Safari if OS is Mac or else Microsoft Edge for Windows.

However, if you still face the SSL/TLS Handshake Failed error, even after changing the browser, then the issue is not regarding browser but, most probably, the plugin. To verify whether the error can be solved or not, it’s recommended to disable all your installed plugins and reset your browser settings to default.

3. Man-in-the-Middle

Generally, the MITM (Man-in-the-Middle) attack comes across as a criminal activity that attempts to cause harm or steal user’s information. However, that’s not always the case. Many programs and devices intercept for inspection or any other reason like load balancing, which is sent along to the application server, and this is known as MITM too.

ssl-bridging

Nevertheless, sometimes issues occur with such devices, which causes the SSL Handshake Failure error. And, the reason could be a network firewall preventing the connection or else configuration on an edge device on the server-side network, which means there’s a possibility that this error could be from the client or server-side depending upon the scenario.

Lastly, if the issue is from the client-side, then you can take a chance of exposing yourself by tweaking the settings on your VPN or antivirus. Though, never drop your antivirus or firewall to connect with a website. And, if the server is causing the issue, then mostly configuration is creating an issue on an edge device.

Here’s the Server-Side Errors and Its Solution

Most of the time, SSL/TLS Handshake failure error is due to server-side issues. Some of them are easy to solve, and some aren’t, and some are not even worth solving at all.

Let’s look at some of the common server-side issues.

1. Protocol Mismatch

It’s one of the errors which can happen due to both the server-side or the client-side, and generally, it’s not worth solving depending upon the circumstance. And when it’s about ciphers and protocols, it’s advised to move forward rather than backward.

For instance:

TLS 1.2 came more than a decade ago, and small segments of websites still fail to support it. Earlier back in March 2018, the final version of TLS 1.3 was published as RFC 8446 by the IETF. And, sites were also advised for adding support for TLS 1.3 at their earliest.

So, if the SSL/TLS Handshake Failure error is due to protocol mismatch, it generally means the client and server do not have mutual support for the same TLS version.

For example:

  • The client supports TLS 1.0 and TLS 1.1, whereas the server supports TLS 1.2.

As shown in this example, the TLS protocol is not supported mutually. So, it’s likely that the server won’t support backward versions. Nevertheless, the server shouldn’t fix this as well. In this above example, the client must be recommended to upgrade their browser, or else it must be latest with the latest TLS version supported. Presently all we can suggest is that TLS 1.2 or TLS 1.3 must be used, or else support must be added for it.

2. Cipher Suite Mismatch

A cipher suite is quite similar to the Protocol Mismatch. SSL/TLS isn’t just a single algorithm that handles everything on its own but a combination of numerous algorithms that serves different functions and work with each other to make up SSL/TLS.

Nevertheless, Cipher Suites used by TLS 1.3 has been refined. Earlier, Cipher Suite has algorithms that handled:

  • Symmetric Session Key Encryption
  • Asymmetric Public Key Encryption
  • Signature Hashing
  • Key Generation

Different Organizations and Government Agencies have different types of encryption standards that suggest different kinds of cipher suites so clients can have different options while being able to find a mutually acceptable cipher. No doubt, it’s less likely that you get a site that only supports a single cipher suite.

Many times, it happens within a network, if you’re doing SSL bridging, where an edge device receives and decrypts HTTPS traffic and then re-encrypts it to send it to the application server. If the application server and edge device fail to share a mutually supported cipher suite, it will cause errors. Similar to Protocol versions, it’s also advisable for cipher suites, to never go backward but only moves forward.

Lastly, a protocol version or cipher suite is deprecated because there’s a vulnerability in that version. So, going back to the earlier version will only make your connection less secure.

3. Incorrect SSL/TLS Certificate

Many different reasons can make a browser view at an SSL/TLS Certificate as incorrect while preventing it from the successful handshake. Let’s dive into it in the next sub-sections and try to materialize the different issues that result because of a failed handshake due to the technical level.

  • Host Name Mismatch: Hostname fails to match with the CN in the certificate.
  • Incorrect Certificate Chain: Intermediate missing in the certificate chain.
  • Expired/Revoked Certificate: The server presents an untrusted, revoked, or expired SSL/TLS certificate.
  • Self-Signed Replacements: Certificate replacements or Internal Networks confuses the path.

4. The hostname is Not Correct

Previously there was a problem with non-WWW and WWW versions of the websites, but it has been reduced radically by the Certificate Authority community allowing one of them to be listed as a SAN free of cost. The simple solution for this issue is to re-issue the certificate or sometimes use a Wildcard certificate.

5. Certificate Chain is Not Correct

The SSL/TLS and PKI trust model generally relies on root programs, which are the collections of trusted CA root certificates that are stored onto your computer system.

Some of the Root program examples:

  • Mozilla root program used by Firefox Desktop and Mobile
  • Google root program used by Android OS
  • Apple root program used by iOS and macOS
  • Microsoft root program used by Windows

Nevertheless, CA root programs are invaluable, that it’s not issued directly, but Certificate Authorities make use of intermediate roots for signing SSL/TLS leaf (end-user) certificates. And, here’s the chain comes into play. The Root CA certificate is used for digitally signing the intermediate roots, and those intermediates are further used for signing other intermediate or end-user leaf SSL/TLS certificates.

certificate-chain-validation

So, whenever the browser gets an SSL certificate, the browser does one of the things for sure. It will check whether the signatures follow their authenticity. Looks digital name on the SSL/TLS certificate with the Intermediate root that signed it. Then it looks at the digital signature of the intermediate certificate and checks it back to the certificate, which signed the intermediate. This process is continuous like this till it reaches one of the Root CA certificates in its trust store.

Hence, whenever this process remains incomplete due to any reason, means browser failing to locate even one of their intermediate certificates will result in the SSL handshake failed error. The solution is to install the missing intermediate certificate. To find the missing intermediate certificate solution is to go to the CAs website from whom you purchased your SSL/TLS certificate.

6. Revoked/Expired Certificates

Currently, the maximum validity of an SSL/TLS certificate is of 2 years and three months extra (Total 27 months because CAs allow carrying up three months over from previously installed certificate.) In case, if your SSL/TLS certificate gets expired or due to any reason it gets revoked, then it may result in SSL Handshake Failure error. If this is the reason, then get a valid certificate issued and installed.

7. Self-Signed Replacements

If you’ve installed a self-signed SSL/TLS certificate on your website and its live on the public internet, then it will generate an error. To resolve a mistake, get your SSL/TLS certificate issued from the trusted CAs like Sectigo, Comodo, or DigiCert.

8. SNI-Enabled Servers

Generally, it’s an internal issue that happens between devices, but sometimes there are chances of getting an SSL/TLS handshake failed error if a client communicating with a Server Named Indication (SNI) enabled server is not SNI enabled.

To solve this issue, you must identify what’s the hostname and the port number of the server, while verifying whether it’s SNI-enabled and it’s communicating everything it has to.

Summary

Many times, website owners don’t make any necessary changes until they face a problem, which can’t be overlooked. Though some of the client-side fixes for this SSL/TLS handshake failed, the error is there as its mentioned in this article, mostly it’s going to be server-side.

So, if you’re a regular internet user, your options are limited. The best thing you can do as a website visitor is to inform the owner of the website about the SSL/TLS handshake failed to issue and wait for them to fix it. If they don’t take any action onto it, then it’s best to avoid using that website.

cheap-ssl-providers

Related Articles:

AboutSSL’s Best Stuff

Disclosure: AboutSSL appreciates your continuous support. It helps us tremendously to keep moving in the competitive SSL industry. Here most of the links which direct you to buy any SSL/TLS related service or products earns us a certain percentage of referral commission. Learn More

Источник

Sun Dec 18 02:21:46 2016 OpenVPN 2.3.12 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 23 2016
Sun Dec 18 02:21:46 2016 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Dec 18 02:21:46 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09
Sun Dec 18 02:21:46 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25341
Sun Dec 18 02:21:46 2016 Need hold release from management interface, waiting…
Sun Dec 18 02:21:46 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25341
Sun Dec 18 02:21:46 2016 MANAGEMENT: CMD ‘state on’
Sun Dec 18 02:21:46 2016 MANAGEMENT: CMD ‘log all on’
Sun Dec 18 02:21:46 2016 MANAGEMENT: CMD ‘hold off’
Sun Dec 18 02:21:46 2016 MANAGEMENT: CMD ‘hold release’
Sun Dec 18 02:21:46 2016 WARNING: Your certificate is not yet valid!
Sun Dec 18 02:21:46 2016 Control Channel Authentication: tls-auth using INLINE static key file
Sun Dec 18 02:21:46 2016 Outgoing Control Channel Authentication: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Sun Dec 18 02:21:46 2016 Incoming Control Channel Authentication: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Sun Dec 18 02:21:46 2016 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Dec 18 02:21:46 2016 UDPv4 link local: [undef]
Sun Dec 18 02:21:46 2016 UDPv4 link remote: [AF_INET]31.186.250.47:1194
Sun Dec 18 02:21:46 2016 MANAGEMENT: >STATE:1482024106,WAIT,,,
Sun Dec 18 02:21:46 2016 MANAGEMENT: >STATE:1482024106,AUTH,,,
Sun Dec 18 02:21:46 2016 TLS: Initial packet from [AF_INET]31.186.250.47:1194, sid=c6fffc0e 4c5088f1
Sun Dec 18 02:21:46 2016 VERIFY ERROR: depth=1, error=certificate is not yet valid: CN=ChangeMe
Sun Dec 18 02:21:46 2016 OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sun Dec 18 02:21:46 2016 TLS_ERROR: BIO read tls_read_plaintext error
Sun Dec 18 02:21:46 2016 TLS Error: TLS object -> incoming plaintext read error
Sun Dec 18 02:21:46 2016 TLS Error: TLS handshake failed
Sun Dec 18 02:21:46 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Dec 18 02:21:46 2016 MANAGEMENT: >STATE:1482024106,RECONNECTING,tls-error,,
Sun Dec 18 02:21:46 2016 Restart pause, 2 second(s)
Sun Dec 18 02:21:48 2016 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Dec 18 02:21:48 2016 UDPv4 link local: [undef]
Sun Dec 18 02:21:48 2016 UDPv4 link remote: [AF_INET]31.186.250.47:1194
Sun Dec 18 02:21:48 2016 MANAGEMENT: >STATE:1482024108,WAIT,,,
Sun Dec 18 02:21:49 2016 MANAGEMENT: >STATE:1482024109,AUTH,,,
Sun Dec 18 02:21:49 2016 TLS: Initial packet from [AF_INET]31.186.250.47:1194, sid=b60c4eb5 99b13093
Sun Dec 18 02:21:49 2016 VERIFY ERROR: depth=1, error=certificate is not yet valid: CN=ChangeMe
Sun Dec 18 02:21:49 2016 OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sun Dec 18 02:21:49 2016 TLS_ERROR: BIO read tls_read_plaintext error
Sun Dec 18 02:21:49 2016 TLS Error: TLS object -> incoming plaintext read error
Sun Dec 18 02:21:49 2016 TLS Error: TLS handshake failed
Sun Dec 18 02:21:49 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Dec 18 02:21:49 2016 MANAGEMENT: >STATE:1482024109,RECONNECTING,tls-error,,
Sun Dec 18 02:21:49 2016 Restart pause, 2 second(s)
Sun Dec 18 02:21:51 2016 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Dec 18 02:21:51 2016 UDPv4 link local: [undef]
Sun Dec 18 02:21:51 2016 UDPv4 link remote: [AF_INET]31.186.250.47:1194
Sun Dec 18 02:21:51 2016 MANAGEMENT: >STATE:1482024111,WAIT,,,
Sun Dec 18 02:21:51 2016 MANAGEMENT: >STATE:1482024111,AUTH,,,
Sun Dec 18 02:21:51 2016 TLS: Initial packet from [AF_INET]31.186.250.47:1194, sid=7c277811 d50b1a33
Sun Dec 18 02:21:51 2016 VERIFY ERROR: depth=1, error=certificate is not yet valid: CN=ChangeMe
Sun Dec 18 02:21:51 2016 OpenSSL: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sun Dec 18 02:21:51 2016 TLS_ERROR: BIO read tls_read_plaintext error
Sun Dec 18 02:21:51 2016 TLS Error: TLS object -> incoming plaintext read error
Sun Dec 18 02:21:51 2016 TLS Error: TLS handshake failed
Sun Dec 18 02:21:51 2016 SIGUSR1[soft,tls-error] received, process restarting
Sun Dec 18 02:21:51 2016 MANAGEMENT: >STATE:1482024111,RECONNECTING,tls-error,,
Sun Dec 18 02:21:51 2016 Restart pause, 2 second(s)

Источник

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Ошибка tls connection error
  • Ошибка tpms ниссан теана 2014

    • ➤