Ошибка при подключении openvpn - Решение и исправление самых разных ошибок на TopOshibok.ru

Purpose of this troubleshooting page

This page is specifically about attempting to find and resolve problems with an OpenVPN client program failing to connect to an OpenVPN Access Server. It does not deal with problems in reaching a target system over the established VPN tunnel once the VPN tunnel is already working. That is handled in a separate page: troubleshooting reaching systems over the VPN tunnel.

So if for example you start the OpenVPN client connection and it issues an error and disconnects you, then the information here should help you in determining a possible cause and solution. If not, reach out to us on the support ticket system and provide as much detail as you can.

Locating the server log files

To diagnose problems with an OpenVPN server or client, it is helpful to look at the log files. The log files are located in specific areas on your computer systems, and the following is a general guide on how to find them and how to get the best information out of them. Log files are the place to check whenever you’re having any problems making a connection with an OpenVPN client program to the OpenVPN Access Server, they the information needed to ascertain what’s going wrong.

On the OpenVPN Access Server there is the server side log:
/var/log/openvpnas.log /var/log/openvpnas.node.log (in case of a failover setup)

In the event that you are having problems with starting the Access Server or certain portions of it, for example the web services, then it may be useful to stop the Access Server service, move the log file aside, then start the Access Server service, and stop it again immediately. This creates a new clean log file that contains the startup and shutdown sequence of the Access Server and no other extraneous information. This makes analysis of the log file much easier. To do so use these commands in order:

service openvpnas stop
mv /var/log/openvpnas.log /var/log/openvpnas.log.old
service openvpnas start
service openvpnas stop

You can then grab the /var/log/openvpnas.log file for analysis and start the Access Server again:

service openvpnas start

Locating the client log files

Log file location for the OpenVPN Connect Client for Windows:
C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\etc\log\openvpn_(unique_name).log

The OpenVPN Connect Client for Mac:
/Library/Application Support/OpenVPN/log/openvpn_(unique_name).log

Macintosh may not show you this folder in finder as it only shows you certain things and hides others. So to get to the /Library folder, open Finder and in the menu at the top choose Go followed by Go to folder and then enter the path /Library to get into that directory. You can then go to the correct folder and look up the log file. Please also note that the OpenVPN Connect Client for Macintosh will have permissions set on the log file so that you cannot normally open it. To bypass this, right click the log file and choose the Get info option in the menu. Then at the bottom, under Sharing & Permissions, you will be able to use the yellow padlock icon to unlock the settings and to give everyone read access. Then you will be able to open the log file with a right click and selecting Open with and then choosing something like Text editor to view the contents of the log file.

Known error messages and possible solutions

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

This particular error can have multiple different causes as it is a fairly generic error message.
A possible explanation is that the client program is old and supports only TLS 1.0, but the server is expecting TLS level 1.1 or higher. To see if this is the case log on to the server and check the server side log file. The chances are high that your client program is an older version, like version 2.2 or older, and that it doesn’t know how to handle a modern TLS minimum level requirement, when you see messages that look like this on the server side:

OpenSSL: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol'
TLS_ERROR: BIO read tls_read_plaintext error'
TLS Error: TLS object -> incoming plaintext read error'
TLS Error: TLS handshake failed'
SIGUSR1[soft,tls-error] received, client-instance restarting'

The solution to this particular problem is to upgrade the client software to the latest version.
Another possible explanation is that the settings regarding TLS minimum requirement level have been altered but the OpenVPN client is using an older copy of the connection profile which has incorrect instructions. The settings on the client and the server must match for the connection to be successful. In this situation installing a new copy of the configuration profile will solve the issue. A complete uninstall, redownload, and reinstall of the OpenVPN Connect Client should take care of that for you.

And yet another possible explanation is that there is a blockade in place in a firewall or at the Internet service provider that is blocking or interfering with the TLS handshake in some way.

TLS Error: local/remote TLS keys are out of sync

For some reason the negotiated TLS key to be used on the client side for TLS encryption/decryption is different from the one used on the server side. That should never happen. When the client and server are talking to one another they agree upon a TLS key to be used for encrypting and decrypting traffic. By default in Access Server such a key is valid for 6 hours, and after those 6 hours, automatically the TLS refresh kicks in and they will agree upon a new key. There is a short overlap where both the old and new key are accepted, until the old key is expired and the new key must be used. If for some reason one side doesn’t do this, you see this error message.

A possible cause is a bug in the OpenVPN protocol with the version used in OpenVPN Connect Client which was resolved, where the automatic TLS key refresh would fail because the client and server couldn’t agree properly on the encryption cipher to use. So if you encounter this particular problem and you are using an OpenVPN3 based client like OpenVPN Connect Client 2.*, then consider updating to the latest version. You can do so for example per computer by downloading OpenVPN Connect Client for Windows or OpenVPN Connect Client for macOS from our website, and installing it. However a better solution would be to update your Access Server to the latest version so that you get the updated Connect Client embedded in there, and then downloading and installing the latest version of OpenVPN Connect Client from your Access Server. If you use other client software and it shows problems, try finding a newer version for it. Worst case scenario, you could also consider changing the TLS key refresh to something larger in the Advanced VPN page of the Admin UI, to avoid triggering the issue. This does of course lower security somewhat.

Server poll timeout

One of the very first steps that an OpenVPN client program will do when trying to connect to an OpenVPN Access Server is to simply send out a message requesting for a reply. So basically a «hello are you there?» message. The server is then supposed to respond and then a connection is started. However if you see a server poll timeout error message then the server could not be reached at the specified port. Why this is not possible is another question entirely, but the error message is very clear: there is simply no response at all on that address and port. So when you see this message it would be good to check if the port is actually open, if the port is correct, if the address you’re trying to reach can actually be reached from the Internet, and isn’t a private IP address only, and other such checks to confirm basic connectivity to the server. At this point you’re not even looking at a problem that has anything to do with the OpenVPN protocol itself. This is a most basic «this server cannot be reached» message.

A common mistake that is made is that people set up the Access Server on a private IP address but neglect to set up a proper FQDN DNS name for it, and configure that FQDN DNS name in the Admin UI under Server Network Settings in the Host name or IP address field. It is that field value that connection profiles generated and provisioned to the OpenVPN clients will be using to start a connection to. So if this is set to an internal private IP address that the Access Server was installed on, then the connection profiles will try to connect to that private IP address, which is unlikely to be reachable from anywhere else but the internal network that the Access Server itself is on. The solution is to set up a proper DNS name and configure that and save settings. Then uninstall, redownload, and reinstall the connection profile or OpenVPN Connect Client program and to try again.

Another common mistake is to forget to open the 3 ports required for OpenVPN Access Server to be reachable properly. By default these are TCP 443, TCP 943, and UDP 1194.

SESSION_ID only allowed to be used by client IP address that created it

OpenVPN Access Server uses a session-based-token system for server-locked and user-locked profiles. Auto-login type profiles don’t. What this means is that after a user authenticates successfully, they are given a session token to identify themselves with. Compare it to going to a party and you show up and pay your entry fees, and if you need to go out for a little bit, they give you a stamp on the back of your hand, or put a paper/plastic strip around your wrist, so that you can show up again later and be admitted access again. That’s a very simplified explanation. With a session token, each token is unique and uniquely identifies you. This avoids having to store your credentials in memory or bothering the user to reauthenticate when you temporarily lose contact with the server and reconnect again, so it’s safer and more convenient. The session token is locked to the IP address that the original authentication attempt was made from, this is a security feature. When you see this message it means the session token your client program offered to the server was generated originally from another IP address. This can happen for example if you switch Internet connection, like logging in at work, then moving your laptop home and it tries to reconnect automatically with the session token. This session token IP lock is a security feature that can be disabled to allow such automatic reconnects to occur without this error message.

Authentication Error: Session: your session has expired, please reauthenticate

The OpenVPN Access Server works with a session token based authentication system when you are using a server-locked or user-locked profile. When you authenticate successfully, you are given a session token instead. The session token identifies you now from that moment onward. By default the session token expires after 5 minutes of inactivity as in not being connected to the server, and it also expires after 24 hours by default. Furthermore, when the session token is generated on the server, it gets locked to the VPN client’s connecting IP address. This session IP lock can be disabled, and the timeout for session inactivity and the timeout for total session duration mentioned can also be adjusted. If for example you are on your phone and you are connected through WiFi, and you walk out of range of WiFi, and it switches to another Internet connection like 3G/4G or something, then your VPN client will disconnect but attempt to reconnect automatically. Your IP will now be different and as such the session token is not valid anymore. You will see an error like in the previous section in the server side log file (SESSION_ID only allowed to be used by client IP address that created it). And if your connection has lasted 24 hours in total, then it will also disconnect you if you’re on a session-based connection with server-locked or user-locked profile. The solution is to either use an auto-login type profile or to increase the session token duration.

unable to obtain session ID from vpn.yourserver.com, ports=443: (error description here)

This error message can be found in the capi.log file and also shown in the popup message in Windows or macOS when you use OpenVPN Connect Client for Windows or macOS. This error message indicates that a server-locked connection profile is being used, which is the default on OpenVPN Access Server when you download and install the OpenVPN Connect Client. A server-locked connection profile is designed to be user-agnostic, meaning it doesn’t carry any user-identifiable information in it, and is a sort of universal profile. This allows any valid user accounts to start a connection with this OpenVPN Connect Client. The credentials are passed over a secure HTTPS channel to the XML-RPC services of the Access Server for verification, and if approved, the client will receive a copy of the user-locked profile for this user, and a session token. Those will be used to start the OpenVPN tunnel. After the tunnel is disconnected, the user-locked profile and session token are deleted. But for this to work, there must be a working HTTPS connection to the web services of the Access Server.

unable to obtain session ID from vpn.yourserver.com, ports=443:
Other SSL errors:[(‘SSLroutines’,’SSL23_READ’,’ssl handshake failure’)]

This could indicate that the Connect Client was able to reach some service, but it does not appear to be the Access Server web services, or perhaps the traffic is mangled by some firewall or proxy solution. For example we have seen situations where OpenVPN Access Server was installed with default settings, and OpenVPN Connect Client was installed and working, and then the port was changed on the server side from TCP 443, to TCP 444 for example, and then a web server was setup on that same server system, with an HTTPS website running on it on port TCP 443. The OpenVPN Connect Client won’t have received an update to the new port setting for the Access Server web services, and so it tries to talk to the old port, where now a web server runs. This causes an unexpected problem that can result in this type of error. If you encounter this problem you should investigate if the port that the client is trying to reach is actually reachable by this client, and to try to determine if there really is an Access Server web service running there. If you changed the ports on the server you need to reinstall this client so it updates the settings.

unable to obtain session ID from vpn.yourserver.com, ports=443:
ConnectionRefusedError: 10061: No connection could be made because the target machine actively refused it

This is a very clear indication that the address and port that the OpenVPN Connect Client is trying to reach, does not have an Access Server web service running there. For example if you install OpenVPN Connect Client on a client computer, and then you go to the Access Server and change the ports that it listens to, then the client will still be trying to connect to the old ports that were originally configured. This can also sometimes occur if the address of your server is simply misconfigured. The solution is making sure that in the Admin UI in the Network Settings page you have set the address that your server can be reached at correctly (it is best to do a DNS name instead of an IP) and that the ports are how you want them, and then after that’s set up, to download and install the OpenVPN Connect Client on your client computers.

unable to obtain session ID from vpn.yourserver.com, ports=443:
XML-RPC: TimeoutError

This indicates that the Access Server web interface’s XML-RPC interface is unreachable. The OpenVPN Connect Client uses this interface to obtain the necessary certificates and configuration to start the OpenVPN connection when you are using a server-locked profile. You will not be needing the XML-RPC interface when you use user-locked and auto-login profiles. The advantage of server-locked profiles is that they are universal — any valid user at the Access Server can log in and connect. The timeout error just means the connection timed out, usually a firewall or such is blocking the connection. The solution is to ensure that the web interface is reachable from this OpenVPN client, or instead use a user-locked or auto-login type profile.

unable to obtain session ID from vpn.yourserver.com, ports=443:
XML-RPC function GetSession with 1 arguments may not be called at the configured relay level

The OpenVPN Connect Client program for Windows and macOS by default uses server-locked profiles. These contain only the information necessary to talk to the XML-RPC web interface of the Access Server for the purpose of authenticating a user and obtaining the required certificates and connection information to start the OpenVPN tunnel. This is done so this client is universal. It will work for all valid users on the server and isn’t locked to a specific user. This does require that the web interface is reachable and that under client settings in the Admin UI the XML-RPC function is set to at least limited functionality. Full functionality also works, but when you set this to disabled, then you will get this error. The solution is to either stop using server-locked profiles and switch to user-locked or auto-login profiles, or to enable at least limited functionality for XML-RPC calls. The default is limited functionality and that is sufficient for OpenVPN Connect Client and server-locked profiles.

See the logfile ‘C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\core\ovpntray.exe.log’ for details

If you see this error message while launching the OpenVPN Connect Client, and it fails to launch, you may be missing specific Microsoft Visual C++ Redistributable DLL library files. This issue was resolved in OpenVPN Connect Client for Windows version 2.5.0.136 by adding specific required library files into the OpenVPN Connect Client program directories. You should ensure you use up-to-date software to resolve this issue. You can upgrade your Access Server to the latest version so that it offers updated OpenVPN Connect Client software, or you can separately download the OpenVPN Connect Client for Windows from our website, to upgrade your existing Connect Client version.

Serial number not found in DB

OpenVPN Access Server by default comes with an internal PKI structure, which means a self-signed root certificate with unique certificates generated for each OpenVPN client for that server. These are all unique and tied together. This is part of the strength of OpenVPN, the identity of a VPN client and a VPN server are verified in both directions when a connection is made. The client verifies the server, and the server verifies the client. So for each user account you add to the Access Server, a unique certificate is generated. The certificate is bound to the user account name, so you can’t log in with the credentials for user bob with the certificates for user billy. Each certificate also has a serial number, a unique number identifying the certificate. If you see the error that the serial number is not found in the database, that means this certificate is not known to this server. Even if you revoke a certificate, it is still known to the server, and will not produce this particular error. So you may be using a certificate from a completely different Access Server by mistake, or maybe you started with a new setup of Access Server on your server and the certificates are wiped and new ones generated for the new setup, while you’re still using old certificates from the previous installation. To resolve this problem, make sure to delete the wrong connection profile from your client computer and obtain a new one from your current Access Server installation and use that to connect.

Open TAP device «» PATH=»» FAILED TUN Error: cannot acquire TAP handle EVENT: TUN_IFACE_CREATE cannot acquire TAP handle [FATAL-ERR] 2021 EVENT: DISCONNECTED Client exception in transport_recv: tun_exception: not connected

You may receive this error message when the OpenVPN Connect 3.x service stops or does not resume when you sign back into the computer. The issue is likely caused by an antivirus program. Specifically, we’ve seen this with ESET Antivirus. You can reconnect by restarting the service manually, but the automatic connection may still encounter the issue. To test, turn off ESET. If that resolves the issue, then you may want to open a support ticket with ESET.

See also the topic authentication problems for more possible error messages and solutions regarding authentication issues.

Источник

Иногда случаются проблемы с VPN подключением или VPN не работает. На данной странице вы можете найти описание возникающей ошибки впн и самостоятельно исправить ее.

Вы везунчик!

Поздравляем! Вы нашли скрытый промо-код со скидкой 75% на покупку анонимного VPN без логов.
Промо-код действует только 1 час.

Купить VPN

Ошибки OpenVPN

Если вы не знаете как узнать ошибку, возникшую в ходе подключения, нажмите на следующую ссылку:

Как узнать какая OpenVPN ошибка возникла?

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

Не могу выбрать «Connect» при нажатии на иконку в системном трее?
Connect to IP:Port failed, will try again in 5 seconds; No Route to Host
Cannot load certificate file client.crt
All TAP-Win32 adapters on this system are currently in use
ERROR: Windows route add command failed: returned error code 1?
Initialization Sequence Completed With Errors

Как узнать какая OpenVPN ошибка возникла?

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

Когда соединение прошло успешно, и вы подключены к VPN серверу, то окно лога должно выглядеть так:

наверх

Не могу выбрать «Connect» при нажатии на иконку в системном трее

В списке есть только «Proxy Settings», «About» и «Exit», но нет пункта «Connect».

Это означает, что вы не скачали и/или не скопировали конфигурационный файл «client.ovpn» в «C:/Program Files/OpenVPN/config». Откройте еще раз Инструкцию по настройке OpenVPN соединения для вашей ОС и проверьте все шаги установки и настройки.

наверх

Connect to IP:Port failed, will try again in 5 seconds; No Route to Host

Данная ошибка означает, что у вас нет подключения к Интернету, либо его блокирует ваш Firewall или Антивирус.

Проверьте активно ли ваше Интернет подключение, отключите Firewall, Антивирус и подключитесь еще раз.

наверх

Cannot load certificate file client.crt

Данная ошибка связана с отсутствием сертификационных файлов в папке «C:Program FilesOpenVPNconfig».

В процессе установки было необходимо скачать архив с сертификатами и распаковать его в папку с программой. Откройте еще раз Инструкцию по настройке OpenVPN соединения для вашей ОС и проверьте все шаги установки и настройки.

наверх

All TAP-Win32 adapters on this system are currently in use

Эта впн ошибка связана с некорректной работой Windows и программы OpenVPN. Также эта OpenVPN ошибка может возникнуть вследствие отключения Интернета без отключения сначала OpenVPN соединения. Всегда отключайте сначала OpenVPN соединение и только затем Интернет.

Для устранения ошибки, зайдите в «Пуск -> Сетевые подключения». Найдите «Подключение по локальной сети. TAP-Win32 Adapter» и правой кнопкой мышки щелкните на ярлыке. Выберите «Отключить».

Затем, таким же образом, «Включите» данное подключение. После выполнения данных действий проблемы с VPN подключением должны исчезнуть.

наверх

ERROR: Windows route add command failed: returned error code 1

Данная ошибка связана с ограничением прав в Windows Vista, Seven.

Для устранения ошибки, необходимо выйти из OpenVPN GUI. Правой кнопкой мышки нажать на иконку OpenVPN GUI на рабочем столе и выбрать пункт меню «Свойства»

На вкладке «Совместимость» поставьте галочку «Выполнять эту программу от имени администратора».

Теперь запустите OpenVPN GUI еще раз и подключитесь к VPN серверу.

наверх

Initialization Sequence Completed With Errors

Данная ошибка связана с неправильной работой службы DHCP из-за антивирусов или фаерволов.

Ошибка наблюдалась постоянно у фаервола Outpost Firewall версии 2009 и ранее, наблюдается также у антивируса Касперского. Ниже представлено решение для антивируса Касперского. Сам алгоритм ничем не отличается от решения проблемы для других антивирусов и фаерволов.

Для устранения ошибки, необходимо зайти в «Пуск -> Панель Управления -> Сетевые подключения» и зайти в «Свойства» виртуального адаптера «TAP-Win 32 Adapter». На вкладке «Общие» в списке отключить Kaspersky Anti-Virus NDIS Filter и затем нажать «ОК».

Теперь подключитесь к VPN и подключение должно пройти успешно.

наверх

Источник

Tweak your settings to secure an unbreakable VPN connection

by Elena Constantinescu

Elena started writing professionally in 2010 and hasn’t stopped exploring the tech world since. With a firm grasp of software reviewing and content editing, she is always trying… read more

Updated on January 18, 2023

OpenVPN is one of the most popular VPN protocols, thanks to its superior security and connection speed.
You can also use an official OpenVPN client for free.
Many users report that OpenVPN is not working on their Windows 10 PCs.
If you’re one of them, discover our easy workarounds, like adding an exception to the system firewall.

OpenVPN is an open-source VPN client and VPN protocol with immense popularity, thanks to high security and excellent connection speed.

You can separately download and install the OpenVPN client on all popular devices for free if you want to create a secure tunnel to the web.

Or, you can turn to a commercial VPN provider that adopts OpenVPN.

However, OpenVPN may stop working on Windows 10 computers, due to various issues. If you’re encountering this scenario, here’s what you need to do.

Speaking of scenarios, there are several errors that may appear when you have problems with OpenVPN, many users report issues when attempting to start up the app:

OpenVPN GUI not opening
Openvpnagent request error in Windows 7, Windows 10 or Windows 11
Connecting to the Management interface failed in OpenVPN

Meanwhile, others manage to launch it only to encounter severe disruptions afterward:

OpenVPNcrashing in Windows 10 or OpenVPN stopped working all of a sudden
OpenVPN connected but not working windows 10
DNS not working in Windows 10 with OpenVPN
TAP mode is not supported in OpenVPN
OpenVPN service is not available
Error attempting to connect to the selected server in OpenVPN
OpenVPN socket protect error
OpenVPN Windows Firewall not working

Below you will find easy-to-follow instructions that should help fix any of the above-mentioned errors and be able to browse the web through a secure OpenVPN tunnel.

How do I enable OpenVPN in Firewall on Windows 10?

In case you have OpenVPN connected but not working in Windows 10, you can enable it by changing a few settings in your firewall security.

Hence, these are the short steps on how to enable OpenVPN in your Firewall:

In the Start Menu, access Firewall settings.
Click on the Advanced Settings.
In the next windows, go to Inbound Rules.
Click on the New rule button.
Select the Program option and Next.
Go to Program’s path and choose OpenVPN.
On the Action window, select Allow the connection.
Let all the three options checked and click Next.
Set the name and description, and then click Finish.

At the same time, this step-by-step guide should resolve OpenVPN not working on Windows 11, so you can use the method on the newest OS version without problems.

How can I fix OpenVPN not working on Windows 10?

1. Add an exception to the firewall

Press the Win key, type firewall, and open Firewall & network protection
Click Allow an app through the firewall
Click Change settings (you need admin rights)
Search for OpenVPN in this list and check its boxes for Private and Public
If it’s not in this list, click Allow another app to browse and select it

It’s possible that your firewall didn’t whitelist OpenVPN when you installed the client. In that case, you have to manually add an exception for it in the system firewall.

If another application is responsible for your computer’s firewall, make sure to adjust the above settings accordingly.

To quickly test this theory, you can temporarily disable the firewall and check if OpenVPN works properly on Windows 10 now.

But don’t forget to turn it back on since you risk exposing your home network to vulnerabilities.

2. Use a reliable VPN client with OpenVPN support

If you’re trying and failing to get the OpenVPN to work on Windows 10, consider getting a commercial VPN app that supports the OpenVPN protocol.

And we can’t think of a better option than Private Internet Access. This software supports multiple protocols, including OpenVPN.

This VPN is compatible with all major operating systems and also has a manual configuration option for OpenVPN for those of you who want to add it directly to a supported router.

More about Private Internet Access

35 000+ servers in 80+ countries
Split tunneling functionality
Private DNS address on each server
Zero-logs policy
Bypass geo-blocking restrictions from other regions
Compatibility with any devices like Windows, macOS, Android, or iOS

Private Internet Access

Utilize this leading VPN software to set up OpenVPN on your Windows device for complete privacy.

3. Whitelist OpenVPN in your antivirus

If your anti-malware application throws errors when you try to use OpenVPN on Windows 10, it could mean that it’s blocking the client or protocol.

However, it’s a false positive. In that case, make sure to add OpenVPN to the whitelist to prevent your antivirus from blocking your VPN.

As in the previous solution, you can quickly test it by temporarily deactivating the real-time detection engine of your anti-malware tool.

But we suggest turning it back on as soon as you finish the test and not leave your computer exposed to malware attacks.

If you’re interested in an anti-malware tool with built-in VPN functionality, check out our best picks.

4. Reset the TAP adapter

uninstall TAP drivers from Device Manager

Right-click the Start button and select Device Manager
Expand the Network adapters menu
Look for any TAP drivers, right-click and select Uninstall device
Open the Action menu and select Scan for hardware changes

The OpenVPN client requires a TAP driver to work properly. If its functionality is broken, it could be the reason why OpenVPN is not working on your Windows 10 PC.

However, you can easily fix this by uninstalling the TAP driver from Device Manager – it should get automatically reinstalled.

As a general rule, it’s essential to keep Windows drivers updated to the latest version.

Read more about this topic

How to Show The Folder Size on Windows 11?
Fix: No Internet in Windows 11 Safe Mode With Networking

5. Check if the DHCP service is running

Press the Win key, type services, and open Services
Right-click DHCP Client and select Properties
Set Startup type to Automatic
Click OK

Many OpenVPN users report seeing the Initialization Sequence Completed with errors message on Windows 10.

It signals a problem with the DHCP client, which you can restart using the instructions above.

6. Flush DNS and reset Winsock

Run Command Prompt as admin: press Ctrl + R, type cmd, hold Ctrl + Shift, and press Enter
Copy and paste the next lines (press Enter between each line)

ipconfig /flushdns

ipconfig /registerdns

ipconfig /release

ipconfig /renew

NETSH winsock reset catalog

NETSH int ipv4 reset reset.log

NETSH int ipv6 reset reset.log

exit

Restart your PC to apply the new changes.

The DNS cache and Winsock configuration are responsible for your computer connectivity.

If they’re not initialized properly, it could be the reason why OpenVPN isn’t working on Windows 10.

To recap, if your OpenVPN configuration fails to work on Windows 10, you can fix this issue by adding an exception to the firewall and whitelisting OpenVPN in your antivirus.

You can also reset the TAP adapter, check if the DHCP service is running, as well as flush your DNS and reset Winsock.

But we suggest opting for a trustworthy VPN like Private Internet Access It has built-in support for the OpenVPN protocol, which means that you shouldn’t see any errors anymore.

Learn everything about OpenVPN to master this VPN protocol and client. Also, visit our VPN Troubleshooting Hub whenever you need a VPN quick fix.

Источник

Обычно довольно легко настроить 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 Files\OpenVPN\log доступен только пользователю с повышенными привилегиями.

Последние несколько строк в файле журнала говорят нам, что 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:

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

source address      = 10.200.0.200
destination address = 172.31.1.254

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

Снова запустите tcpdump -nnel -i eth0 на сервере, чтобы проверить, покидает ли трафик интерфейс локальной сети со следующими заголовками пакетов:

source address      = 10.200.0.200
destination address = 172.31.1.XXX

Здесь 172.31.1.XXX — это IP-адрес компьютера, к которому мы пытаемся подключиться в локальной сети на стороне сервера. Есть ли обратный трафик?

И так далее и так далее для оставшихся шагов!

Как оптимизировать производительность с помощью ping и iperf

Получить максимальную производительность из установки OpenVPN может быть сложно. В чистой сети Ethernet стандартные настройки OpenVPN довольно хороши. Однако в гигабитных сетях требуется некоторая настройка.

Когда используется ADSL или кабельное модемное соединение, производительность также обычно довольно хорошая. Однако при определенных обстоятельствах производительность нашего туннеля OpenVPN может значительно отставать от производительности обычной сети. Эти обстоятельства почти всегда зависят от интернет-провайдера, но, тем не менее, стоит изучить как повысить производительность.

Ключом к оптимизации производительности является наличие хороших инструментов для измерения производительности. Два основных, но бесценных инструмента для измерения производительности сети — это ping и iperf. Инструмент iperf легко доступен в Linux, FreeBSD и Mac OS. Есть порты, доступные для Windows и даже Android.

Использование ping

Используя ping мы можем определить оптимальный размер MTU для нашей сети. Большинство сетевых операторов сейчас предоставляют своим клиентам MTU для Ethernet размером 1500 байт. Это приводит к полезной нагрузке пакета в 1472 байта. Остальные 28 байтов являются издержками TCP/IP для таких вещей, как адрес источника и назначения.

Однако если между клиентом и сервером существует сеть с более низким MTU, то это может значительно повысить производительность, уменьшив размер пакетов OpenVPN чуть ниже этого размера. Чтобы определить максимальный размер передачи для нашей сети, мы используем следующее:

$ ping -M do -s 1472 www.example.org

В Windows мы используем следующее:

C:\> ping -f -l 1472 www.example.org

Она будет отправлять ICMP-пакеты на удаленный сервер по нашему выбору с установленным флагом not fragment, инструктируя сетевые маршрутизаторы не разбивать этот пакет на более мелкие биты. Если между клиентом и сервером есть сеть с меньшим MTU, то команда ping завершится неудачно:

$ ping -M do -s 1472 www.example.org
PING www.example.org (IP) 1472(1500) bytes of data.

ping: local error: Message too long, mtu=1480

Это говорит нам о том, что производительность будет, скорее всего, лучше, если мы используем либо фрагмент размером 1480, либо размер MTU 1480 байт вместо значения по умолчанию 1500. Обратите внимание, что это не является гарантией — только измерив фактическую производительность VPN, мы узнаем, каково влияние на самом деле.

Использование iperf

Используя iperf мы можем измерить производительность сети как внутри, так и вне VPN-туннеля. Это даст нам ценную информацию о том, сколько пропускной способности мы тратим, используя VPN-туннель.

Прежде чем измерять производительность самого VPN-туннеля, всегда пытайтесь измерить производительность нормальной сети. Будет довольно сложно заставить VPN работать лучше чем базовая сеть.

Сначала запустите iperf на сервере с помощью следующей команды:

Затем запустите iperf на клиенте с помощью следующей команды:

$ iperf -c openvpn.example.org

В кабельной сети, которая использовалась для тестирования, результат выглядит следующим образом:

Это на самом деле скорость загрузки используемого кабельного соединения. Теперь мы можем проверить производительность VPN-туннеля в той же сети:

[ 3] 0.0-10.8 sec 5.25 MBytes 4.09 Mbits/sec

Повторение измерения дает очень похожие цифры, поэтому справедливо утверждать, что производительность VPN-туннеля на несколько процентов ниже производительности базовой сети. Это на самом деле имеет смысл, так как использование VPN действительно создает некоторые накладные расходы для инкапсуляции, шифрования и аутентификации (подписи) исходных данных. Это будет трудно для дальнейшей оптимизации этой сети.

Аналогично, для скорости загрузки используемого кабельного соединения мы обнаруживаем, что производительность VPN-туннеля на несколько процентов ниже:

Производительность базовой сети показана следующим образом:

[ 4]  0.0-10.6 sec  51.6 MBytes 40.7 Mbits/sec

Теперь сравните это с VPN-туннелем:

[ 4]  0.0-10.7 sec  49.5 MBytes 39.0 Mbits/sec

Опять же, мы видим снижение производительности на 4,5 процента.

Теперь мы можем использовать параметры fragment и mssfix, чтобы посмотреть сможем ли мы повысить производительность. Там будет немного проб и ошибок для поиска подходящего места для конкретной установки. Неизвестно, какое именно место будет заранее, но метод его определения всегда один и тот же. Теперь добавьте параметры в файлы конфигурации клиента и сервера:

Делая это и изменяя X, мы получаем следующие результаты:

X (bytes)	Download (Mbps)	Upload (Mbps)
1200	37.9	3.94
1300	38.1	4.01
1400	38.4	4.04
1472	38.8	4.06
1500	37.6	3.98
	39.0	4.09

Мы можем заключить, что настройки OpenVPN по умолчанию — самое приятное место для этой сети. Мы могли бы повторить это упражнение, изменив параметр tun-mtu но мы получили бы тот же результат. Однако рекомендуется сначала настроить производительность с помощью параметра fragment, поскольку этот параметр меньше влияет на пересылку пакетов.

Гигабитная сеть

Теперь мы выполним ту же процедуру в неиспользуемой сети Gigabit Ethernet. Производительность iperf базовой сети составляет 950 Мбит/с вверх и вниз.

Когда мы запускаем сервер OpenVPN с помощью конфигурации basic-udp-server.conf и подключаем к нему клиента с помощью файла конфигурации basic-udp-client.conf, мы достигаем следующей производительности iperf:

[ ID] Interval        Transfer      Bandwidth
[ 5]   0.0-10.0 sec    193 MBytes    161 Mbits/sec
[ 4]   0.0-10.0 sec    242 MBytes    203 Mbits/sec

Сейчас наблюдается явное падение производительности. К сожалению, снижение параметра fragment нам здесь не поможет. С fragment 1200 мы достигаем 149 Мбит/с и 115 Мбит/с соответственно.

В высокоскоростных сетях также имеет смысл поэкспериментировать с шифром кодирования. Оба сервера, используемые в этом примере, способны выполнять быстрые инструкции AES благодаря расширению AES-NI, которое присутствует в процессорах (Xeon E5 2620 с тактовой частотой 2 ГГц и Xeon E5 2643 с тактовой частотой 3,5 ГГц, соответственно). Давайте добавим следующее:

Теперь мы получаем следующий результат:

[ 5]  0.0-10.0 sec  316 MBytes  265 Mbits/sec
[ 4]  0.0-10.0 sec  266 MBytes  223 Mbits/sec

На способном процессоре шифр оказывает большое влияние на производительность. Поскольку OpenVPN является монолитной программой — большое количество ядер не помогает вообще. Тактовая частота процессора является доминирующим фактором. Подключив ноутбук Core i7 с тактовой частотой 3,8 ГГц к серверу Xeon E5-2643 с частотой 3,5 ГГц, мы получаем гораздо более высокую пропускную способность, используя точно такую же конфигурацию:

[ 5]  0.0-10.0 sec  707 MBytes  593 Mbits/sec
[ 4]  0.0-10.0 sec  529 MBytes  443 Mbits/sec

Таким образом, если вы хотите настроить туннель OpenVPN через высокоскоростную сеть, то лучший совет — использовать высокопроизводительные ЦП, которые поддерживают набор инструкций AES-NI. С такой настройкой можно достичь скорости сети более 500 Мбит/с в обоих направлениях.

Анализ трафика OpenVPN с помощью tcpdump

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

Сначала мы настраиваем нашу стандартную сеть OpenVPN, используя конфигурационные файлы basic-udp. На клиенте также работает веб-сервер. Мы будем использовать команду wget на стороне сервера, чтобы извлечь файл с веб-сервера, чтобы мы могли посмотреть на полученный сетевой трафик.

Мы запускаем tcpdump на интерфейсе Ethernet и собираем сетевой трафик, выполняя wget вне туннеля:

wget -O /dev/null https://CLIENT-IP/test1

Результирующий вывод tcpdump выглядит следующим образом (для ясности изменен):

Как мы видим, существует 13 пакетов для передачи текстового файла размером 5 КБ. Большинство из этих пакетов были использованы для установки и разрыва соединения, но есть четыре больших пакета, которые были использованы для фактической передачи данных. Первые три из четырех пакетов имеют размер 1514 байт, что является максимальным размером пакета Ethernet.

Далее мы запускаем ту же команду wget внутри туннеля. Теперь мы наблюдаем зашифрованный трафик на адаптере Ethernet:

Здесь мы видим 22 захваченных пакета. Первый и последний два пакета являются heartbeat пакетами OpenVPN и могут игнорироваться. Оставшиеся 18 пакетов являются зашифрованным эквивалентом пакетов, показанных в первом выводе tcpdump. Как мы видим здесь, длина пакета немного меньше, и особенно payload каждого пакета немного меньше: самый большой пакет payload UDP составляет 1445 байтов. Эти 1445 байт содержат зашифрованные и подписанные данные из команды wget. В нашей настройке мы не указали параметр fragment — это означает, что OpenVPN 2.3 по умолчанию будет иметь внутреннюю фрагментацию 1450 байт.

Общий размер каждого пакета никогда не превышает 1487 байтов, что довольно близко к оптимальному: обычно пакеты не должны превышать размер MTU, который составляет 1500 байтов.

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

Давайте посмотрим, что произойдет, если мы добавим fragment 1400 в нашу настройку. Мы перезапускаем сервер и клиент и снова запускаем команду wget:

С добавленным в нашу настройку fragment 1400 мы можем видеть в выводе tcpdump что полезная нагрузка пакета теперь составляет 1397 байт, что очень близко к пределу 1400. Мы также видим, что теперь требуется больше пакетов для передачи текстового файла размером 5 КБ по туннелю, что означает снижение производительности. Из этого снимка экрана мы можем сделать вывод, что нам следует снова удалить параметр.

Из предыдущего скриншота и предыдущего мы также можем сделать вывод, что каждый пакет OpenVPN несет 42-байтовые издержки. Эти издержки частично способствуют накладным расходам, возникающим при использовании любого решения VPN. Он включает в себя всю служебную информацию, поскольку все сетевые пакеты должны содержать служебную информацию об адресе источника, адресе назначения, типе пакета, контрольные суммы, флаги и многое другое.

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

Этот скриншот говорит нам следующее:

Фактический размер пакета составляет 1487 байт.
Он содержит заголовки Ethernet и IPv4, как и любой сетевой пакет в сети Ethernet.
Это пакет OpenVPN с исходным портом 35400 и портом назначения 1194 — это означает, что он перемещается от клиента к серверу. На самом деле это один из зашифрованных пакетов при передаче файла размером 5 КБ с клиента на сервер.
Полезной нагрузкой пакета является пакет данных OpenVPN (формат версии 1) с размером полезной нагрузки 1487 байт. Обратите внимание, что tcpdump сообщил о 1488 байтах ранее, но Wireshark может декодировать полезную нагрузку и увидеть, что первый байт является кодом операции OpenVPN.

Этот пакет будет получен OpenVPN, проверен на аутентификацию, расшифрован и распакован (если мы указали). Полученный незашифрованный пакет затем перенаправляется в таблицы маршрутизации операционной системы, которые решают, куда направить пакет. В нашем случае пакет останется на сервере и будет передан процессу wget.

Резюме

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

Конечно, OpenVPN не идеален и поэтому ваша нерабочая настройка также может быть вызвана ошибкой в самом OpenVPN. Существует несколько каналов для сообщения об ошибках, включая список электронной почты (openvpn-users@lists.sourceforge.net), канал IRC (#openvpn на freenode.net IRC) и веб-сайт форума (https://forums.openvpn.net). Вы также можете отправлять запросы на функции или списки пожеланий на эти каналы, некоторые из которых могут появиться в будущей версии OpenVPN.

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

Источник

Here we can see, “How to: Fix Openvpn Not Working on Windows 10”

Because of its improved security and connection speed, OpenVPN is one of the most used VPN protocols. An official OpenVPN client is also available for free.
Many users have complained that OpenVPN does not operate on their Windows 10 computers. Discover our simple workarounds, such as adding an exception to the system firewall if you’re one of them.

OpenVPN is a popular open-source VPN client and protocol because of its high security and fast connection speeds.

If you wish to construct a secure web tunnel, you can download and install the OpenVPN client separately on all popular devices for free.

You can also use a commercial VPN service that uses OpenVPN.

However, OpenVPN may cease to function on Windows 10 machines due to different difficulties. Here’s what you should do if you find yourself in this situation.

1. Add an exception to the firewall

1. Open Firewall & Network Protection by pressing the Win key and typing firewall.
2. Allow an app to pass past the firewall
3. Change the settings (you need admin rights)
4. In this list, look for OpenVPN and tick the boxes for Private and Public.
5. If it isn’t already selected, click Allow another app to browse and choose it.

It’s conceivable that when you installed OpenVPN, your firewall didn’t whitelist it. In that situation, you’ll need to manually add an exception to the system firewall.

If another program controls your computer’s firewall, please be sure to update the settings mentioned above correctly.

You may immediately test this notion by briefly turning off the firewall and seeing if OpenVPN works on Windows 10.

But, because you risk exposing your home network to vulnerabilities, remember to turn it back on.

2. Whitelist OpenVPN in your antivirus

If you get issues when trying to use OpenVPN on Windows 10, your anti-malware program may be preventing the client or protocol.

It is, however, a false positive. Add OpenVPN to the whitelist to keep your VPN from being blocked by your antivirus.

You can rapidly test it with the last option by temporarily turning off your anti-malware tool’s real-time detection engine.

However, to avoid leaving your computer vulnerable to malware attacks, we recommend turning it back on as soon as you finish the test.

3. Use a reliable VPN client with OpenVPN support

Consider obtaining a commercial VPN app that supports the OpenVPN protocol if you’re having trouble getting OpenVPN to function on Windows 10.

4. Reset the TAP adapter

1. Select Device Manager from the Start menu by right-clicking the Start button.
2. The Network Adapters menu will be expanded.
3. Look for any TAP drivers and pick Uninstall device from the context menu.
4. Select Scan for Hardware Changes from the Action menu.

A TAP driver is required for the OpenVPN client to function properly. If its functionality is broken, it could cause OpenVPN not to work on your Windows 10 PC.

You may repair this by deleting the TAP driver from Device Manager and then manually reinstalling it.

5. Check if the DHCP service is running

1. Open Services by pressing the Win key and typing services.
2. Select Properties from the right-click menu for DHCP Client.
3. Select Automatic as the startup type.
4. Click OK

On Windows 10, many OpenVPN users have reported receiving the message Initialization Sequence Completed with Errors.

It indicates an issue with the DHCP client, which you can fix by following the steps above.

6. Flush DNS and reset Winsock

1. As an administrator, open Command Prompt by pressing Ctrl + R, typing cmd, holding Ctrl + Shift, and pressing Enter.
2. Copy and paste the lines below (press Enter between each line)

ipconfig /flushdns
ipconfig /registerdns 
ipconfig /release 
ipconfig /renew 
NETSH winsock reset catalog 
NETSH int ipv4 reset reset.log 
NETSH int ipv6 reset reset.log 
exit

To implement the modified settings, restart your computer.

The DNS cache and Winsock setup determine your computer’s connectivity.

It’s possible that they’re not correctly initialized, so OpenVPN isn’t working on Windows 10.

Conclusion

I hope you found this guide useful. If you’ve got any questions or comments, don’t hesitate to use the shape below.

User Questions

1. How do I get OpenVPN to work again?

Setting up a valid DNS name, configuring it, and saving the settings is the solution. Then try again by uninstalling, redownloading, and reinstalling the connection profile or OpenVPN Connect Client application. Another common blunder is failing to open the three ports required for OpenVPN Access Server to function correctly.

2. What is the procedure for enabling OpenVPN in the Windows 10 firewall?

Open Control Panel, go to Windows Defender settings, click Allow an app or feature through Windows Defender Firewall, and activate VPN software using that option.

3. What port does OpenVPN need to listen on?

OpenVPN daemons that listen on port 1194 UDP and OpenVPN daemons that listen on port 443 TCP are installed by default on the OpenVPN Access Server. Although the ideal connection for an OpenVPN tunnel is on the UDP port, we use TCP 443 as a backup.

4. Does anyone have a reliable fix for openvpn client on … – Reddit

Does anyone have a reliable fix for openvpn client on windows 10? from OpenVPN

5. OpenVPN Connect is not launching. – Reddit

OpenVPN Connect is not launching. from OpenVPN

Источник