How To Guide: Set Up & Configure OpenVPN Client/server VPN | OpenVPN

Описание команд и параметров openvpn

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

• remote < host > – определяет удаленный конец туннеля. Могут использоваться записи IP и DNS.
• local < host > – определяет локальный ip или имя хоста, на котором будет работать OpenVPN. Актуально, если на локальной машине несколько адресов.
• dev < device > – определяет какой использовать тип устройства tun или tap. Например: dev tun или dev tap. Так же можно явно указывать номер виртуального интрефейса, например tun0.
• port < port number > – указывает на каком порту будет работать OpenVPN (локально и удаленно).
• proto < proto > – какой протокол будет использоваться. Возможные значения: udp, tcp, tcp-client, tcp-server.
• remote-random – если указана данная опция и в random перечисленно несколько удаленных хостов, то OpenVPN в случайном порядке будет к ним подключаться. Применяется для балансировки нагрузки.
• float – позволяет удаленному хосту изменять IP во время работы туннеля. Соединение при этом не разрывается.
• ipchange < cmd > – выполняет скрипт или команду указанную в < cmd >, если IP сменился. Пример: ipchange script-ip.sh
• connect-retry < seconds > – пробует переподключиться через указанное время в секундах, если соединение было разорвано.
• connect-retry-max < n > – максимальное количество повторов если соединение было разорвано
• resolv-retry < seconds > – если OpenVPN не удалось узнать имя удаленного хоста по DNS, то через указанное количество секунд попытаться переподключиться.
• lport < port > – указывает на локальный порт для использования OpenVPN
• rport < port > – аналогично для удаленного порта. Пример: rport 8000 – OpenVPN будет пытаться подключится к удаленному порту 8000
• nobind – использовать динамический порт для подключения (только для клиента)
• shaper < bytes > – указывает скорость передачи данных в байтах для исходящего трафика (только для клиента)
• tun-mtu < mtu size > – устанавливает максимальный размер MTU. По умолчанию tun-mtu равен 1500. Использование: tun-mtu 1200
• dev-node < interface name > – устанавливает имя виртуального интерфейса. Например: dev-node openvpn1
• ifconfig – устанавливает локальный IP и маску подсети для туннельного интерфейса. Например: ifconfig 10.3.0.1 255.255.255.0
• server < network > < mask > – автоматически присваивает адреса всем клиентам (DHCP) в указанном диапазоне с маской сети. Данная опция заменяет ifconfig и может работать только с TLS-клиентами в режиме TUN, соответственно использование сертификатов обязательно. Например: server 10.3.0.0 255.255.255.0 . Подключившиеся клиенты получат адреса в диапазоне между 10.3.0.1 и 10.3.0.254.
• server-bridge < gateway > < mask > < pool > – сервер в режиме моста для TAP устройств. Пример: server bridge 10.3.0.1 255.255.255.0 10.3.0.128 10.3.0.254 Клиентам будут выданы адреса в диапазоне 10.3.0.128 – 10.3.0.254, в качестве шлюза будет указан 10.3.0.1.
• mode server – переключает OpenVPN в режим сервера (начиная с 2-й версии)
• mode p2p – данная опция идет по умолчанию.

Advanced openvpn options for pkcs#11

pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
pkcs11-pin-cache 300
daemon
auth-retry nointeract
management-hold
management-signal
management 127.0.0.1 8888
management-query-passwords

This will load two providers into OpenVPN, use the certificate specified on pkcs11-id option, and use the management interface in order to query passwords. The daemon will resume into hold state on the event when token cannot be accessed.

Many PKCS#11 providers make use of threads, in order to avoid problems caused by implementation of LinuxThreads (setuid, chroot), it is highly recommend to upgrade to Native POSIX Thread Library (NPTL) enabled glibc if you intend to use PKCS#11.

Ccd/contractor2

ifconfig-push 10.8.2.5 10.8.2.6

Each pair of ifconfig-push addresses represent the virtual client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows clients and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from this set:

[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

This completes the OpenVPN configuration. The final step is to add firewall rules to finalize the access policy. For this example, we will use firewall rules in the Linux iptables syntax:

Chroot (non-windows only)

The chroot directive allows you to lock the OpenVPN daemon into a so-called chroot jail, where the daemon would not be able to access any part of the host system’s filesystem except for the specific directory given as a parameter to the directive. For example,

chroot jail

would cause the OpenVPN daemon to cd into the jail subdirectory on initialization, and would then reorient its root filesystem to this directory so that it would be impossible thereafter for the daemon to access any files outside of jail and its subdirectory tree.

Caveats: because chroot reorients the filesystem (from the perspective of the daemon only), it is necessary to place any files which OpenVPN might need after initialization in the jail directory, such as:

• the crl-verify file, or
• the client-config-dir directory.

Client

The OpenVPN client configuration can refer to multiple servers for load balancing and failover. For example:

remote server1.mydomain
remote server2.mydomain
remote server3.mydomain

will direct the OpenVPN client to attempt a connection with server1, server2, and server3 in that order. If an existing connection is broken, the OpenVPN client will retry the most recently connected server, and if that fails, will move on to the next server in the list.

remote-random

If you would also like DNS resolution failures to cause the OpenVPN client to move to the next server in the list, add the following:

resolv-retry 60

The 60 parameter tells the OpenVPN client to try resolving each remote DNS name for 60 seconds before moving on to the next server in the list.

The server list can also refer to multiple OpenVPN server daemons running on the same machine, each listening for connections on a different port, for example:

remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001

If your servers are multi-processor machines, running multiple OpenVPN daemons on each server can be advantageous from a performance standpoint.

OpenVPN also supports the remote directive referring to a DNS name which has multiple A records in the zone configuration for the domain. In this case, the OpenVPN client will randomly choose one of the A records every time the domain is resolved.

Example

As an example, we will revoke the client2 certificate, which we generated above in the “key generation” section of the HOWTO.

First open up a shell or command prompt window and cd to the easy-rsa directory as you did in the “key generation” section above. On Linux/BSD/Unix:

. ./vars
./revoke-full client2

On Windows:

vars
revoke-full client2

You should see output similar to this:

Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
Revoking Certificate 04.
Data Base Updated
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
client2.crt: /C=KG/ST=NA/O=OpenVPN-TEST/CN=client2/[email protected]
error 23 at 0 depth lookup:certificate revoked

Note the “error 23” in the last line. That is what you want to see, as it indicates that a certificate verification of the revoked certificate failed.

The revoke-full script will generate a CRL (certificate revocation list) file called crl.pem in the keyssubdirectory. The file should be copied to a directory where the OpenVPN server can access it, then CRL verification should be enabled in the server configuration:

crl-verify crl.pem

Now all connecting clients will have their client certificates verified against the CRL, and any positive match will result in the connection being dropped.

Example 1: a simple tunnel without security

On may:

openvpn –remote june.kg –dev tun1 –ifconfig 10.4.0.1 10.4.0.2 –verb 9

On june:

openvpn –remote may.kg –dev tun1 –ifconfig 10.4.0.2 10.4.0.1 –verb 9

Now verify the tunnel is working by pinging across the tunnel.

On may:

ping 10.4.0.2

On june:

ping 10.4.0.1

The –verb 9 option will produce verbose output, similar to the tcpdump(8) program. Omit the –verb 9 option to have OpenVPN run quietly.

First build a static key on may.

openvpn –genkey –secret key

This command will build a random key file called key (in ascii format). Now copy key to june over a secure medium such as by using the scp(1) program.

On may:

openvpn –remote june.kg –dev tun1 –ifconfig 10.4.0.1 10.4.0.2 –verb 5 –secret key

On june:

openvpn –remote may.kg –dev tun1 –ifconfig 10.4.0.2 10.4.0.1 –verb 5 –secret key

Now verify the tunnel is working by pinging across the tunnel.

On may:

ping 10.4.0.2

On june:

ping 10.4.0.1

Expanding the scope of the vpn to include additional machines on either the client or server subnet.

Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.

For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.

First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:

push "route 10.66.0.0 255.255.255.0"

Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

Make sure that you’ve enabled IP and TUN/TAP forwarding on the OpenVPN server machine.

One of the benefits of using ethernet bridging is that you get this for free without needing any additional configuration.

In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.

For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:

• The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
• The client must have a unique Common Name in its certificate (“client2” in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.

First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

client-config-dir ccd

In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually Program FilesOpenVPNconfig.

When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0

This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0

Firewalls

OpenVPN’s usage of a single UDP port makes it fairly firewall-friendly. You should add an entry to your firewall rules to allow incoming OpenVPN packets. On Linux 2.4 :

iptables -A INPUT -p udp -s 1.2.3.4 –dport 1194 -j ACCEPT

This will allow incoming packets on UDP port 1194 (OpenVPN’s default UDP port) from an OpenVPN peer at 1.2.3.4.

If you are using HMAC-based packet authentication (the default in any of OpenVPN’s secure modes), having the firewall filter on source address can be considered optional, since HMAC packet authentication is a much more secure method of verifying the authenticity of a packet source. In that case:

iptables -A INPUT -p udp –dport 1194 -j ACCEPT

would be adequate and would not render the host inflexible with respect to its peer having a dynamic IP address.

OpenVPN also works well on stateful firewalls. In some cases, you may not need to add any static rules to the firewall list if you are using a stateful firewall that knows how to track UDP connections. If you specify –ping n, OpenVPN will be guaranteed to send a packet to its peer at least once every n seconds.

You should also add firewall rules to allow incoming IP traffic on TUN or TAP devices such as:

iptables -A INPUT -i tun -j ACCEPT

to allow input packets from tun devices,

iptables -A FORWARD -i tun -j ACCEPT

to allow input packets from tun devices to be forwarded to other hosts on the local network,

iptables -A INPUT -i tap -j ACCEPT

to allow input packets from tap devices, and

iptables -A FORWARD -i tap -j ACCEPT

to allow input packets from tap devices to be forwarded to other hosts on the local network.

These rules are secure if you use packet authentication, since no incoming packets will arrive on a TUN or TAP virtual device unless they first pass an HMAC authentication test.

Modifying a live server configuration

While most configuration changes require you to restart the server, there are two directives in particular which refer to files which can be dynamically updated on-the-fly, and which will take immediate effect on the server without needing to restart the server process.

client-config-dir — This directive sets a client configuration directory, which the OpenVPN server will scan on every incoming connection, searching for a client-specific configuration file (see the the manual page for more information).

Files in this directory can be updated on-the-fly, without restarting the server. Note that changes in this directory will only take effect for new connections, not existing connections. If you would like a client-specific configuration file change to take immediate effect on a currently connected client (or one which has disconnected, but where the server has not timed-out its instance object), kill the client instance object by using the management interface (described below). This will cause the client to reconnect and use the new client-config-dir file.

crl-verify — This directive names a Certificate Revocation List file, described below in the Revoking Certificates section. The CRL file can be modified on the fly, and changes will take effect immediately for new connections, or existing connections which are renegotiating their SSL/TLS channel (occurs once per hour by default).

Pushing dhcp options to clients

The OpenVPN server can push DHCP options such as DNS and WINS server addresses to clients (some caveats to be aware of). Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreign_option_nenvironmental variable list.

For example, suppose you would like connecting clients to use an internal DNS server at 10.66.0.4 or 10.66.0.5 and a WINS server at 10.66.0.8. Add this to the OpenVPN server configuration:

push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"

To test this feature on Windows, run the following from a command prompt window after the machine has connected to an OpenVPN server:

ipconfig /all

The entry for the TAP-Windows adapter should show the DHCP options which were pushed by the server.

Running an openvpn server on a dynamic ip address

While OpenVPN clients can easily access the server via a dynamic IP address without any special configuration, things get more interesting when the server itself is on a dynamic address. While OpenVPN has no trouble handling the situation of a dynamic server, some extra configuration is required.

The first step is to get a dynamic DNS address which can be configured to “follow” the server every time the server’s IP address changes. There are several dynamic DNS service providers available, such as dyndns.org.

The next step is to set up a mechanism so that every time the server’s IP address changes, the dynamic DNS name will be quickly updated with the new IP address, allowing clients to find the server at its new IP address. There are two basic ways to accomplish this:

The OpenVPN client by default will sense when the server’s IP address has changed, if the client configuration is using a remote directive which references a dynamic DNS name. The usual chain of events is that (a) the OpenVPN client fails to receive timely keepalive messages from the server’s old IP address, triggering a restart, and (b) the restart causes the DNS name in the remote directive to be re-resolved, allowing the client to reconnect to the server at its new IP address.

More information can be found in the FAQ.

Signals

SIGHUP

Cause OpenVPN to close all TUN/TAP and network connections, restart, re-read the configuration file (if any), and reopen TUN/TAP and network connections.

SIGUSR1

Like SIGHUP, except don’t re-read configuration file, and possibly don’t close and reopen TUN/TAP device, re-read key files, preserve local IP address/port, or preserve most recently authenticated remote IP address/port based on –persist-tun, –persist-key, –persist-local-ip, and –persist-remote-ipoptions respectively (see above).This signal may also be internally generated by a timeout condition, governed by the –ping-restart option.

This signal, when combined with –persist-remote-ip, may be sent when the underlying parameters of the host’s network interface change such as when the host is a DHCP client and is assigned a new IP address. See –ipchange above for more information.

SIGUSR2

Causes OpenVPN to display its current statistics (to the syslog file if –daemon is used, or stdout otherwise).

SIGINT, SIGTERM

Causes OpenVPN to exit gracefully.

String types and remapping

In certain cases, OpenVPN will perform remapping of characters in strings. Essentially, any characters outside the set of permitted characters for each string type will be converted to underbar (‘_’).

Q: Why is string remapping necessary?

A: It’s an important security feature to prevent the malicious coding of strings from untrusted sources to be passed as parameters to scripts, saved in the environment, used as a common name, translated to a filename, etc.

Here is a brief rundown of OpenVPN’s current string types and the permitted character class for each string:

X509 Names: Alphanumeric, underbar (‘_’), dash (‘-‘), dot (‘.’), at (‘@’), colon (‘:’), slash (‘/’), and equal (‘=’). Alphanumeric is defined as a character which will cause the C library isalnum() function to return true.

Common Names: Alphanumeric, underbar (‘_’), dash (‘-‘), dot (‘.’), and at (‘@’).

Tls-auth

The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

• DoS attacks or port flooding on the OpenVPN UDP port.
• Port scanning to determine which server UDP ports are in a listening state.
• Buffer overflow vulnerabilities in the SSL/TLS implementation.
• SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

openvpn --genkey --secret ta.key

This command will generate an OpenVPN static key and write it to the file ta.key. This key should be copied over a pre-existing secure channel to the server and all client machines. It can be placed in the same directory as the RSA .key and .crt files.

In the server configuration, add:

tls-auth ta.key 0

In the client configuration, add:

tls-auth ta.key 1

Tun/tap persistent tunnel config mode:

Available with linux 2.4.7 . These options comprise a standalone mode of OpenVPN which can be used to create and delete persistent tunnels.

–mktun

(Standalone) Create a persistent tunnel on platforms which support them such as Linux. Normally TUN/TAP tunnels exist only for the period of time that an application has them open. This option takes advantage of the TUN/TAP driver’s ability to build persistent tunnels that live through multiple instantiations of OpenVPN and die only when they are deleted or the machine is rebooted.One of the advantages of persistent tunnels is that they eliminate the need for separate –up and –down scripts to run the appropriate ifconfig(8) and route(8) commands. These commands can be placed in the the same shell script which starts or terminates an OpenVPN session.

Another advantage is that open connections through the TUN/TAP-based tunnel will not be reset if the OpenVPN peer restarts. This can be useful to provide uninterrupted connectivity through the tunnel in the event of a DHCP reset of the peer’s public IP address (see the –ipchange option above).

One disadvantage of persistent tunnels is that it is harder to automatically configure their MTU value (see –link-mtu and –tun-mtu above).

On some platforms such as Windows, TAP-Win32 tunnels are persistent by default.

–rmtun

(Standalone) Remove a persistent tunnel.

–dev tunX | tapX

TUN/TAP device

Vpn address setup:

For purposes of our example, our two machines will be called may.kg and june.kg. If you are constructing a VPN over the internet, then replace may.kg and june.kgwith the internet hostname or IP address that each machine will use to contact the other over the internet.

Now we will choose the tunnel endpoints. Tunnel endpoints are private IP addresses that only have meaning in the context of the VPN. Each machine will use the tunnel endpoint of the other machine to access it over the VPN. In our example, the tunnel endpoint for may.kg will be 10.4.0.1 and for june.kg, 10.4.0.2.

Once the VPN is established, you have essentially created a secure alternate path between the two hosts which is addressed by using the tunnel endpoints. You can control which network traffic passes between the hosts (a) over the VPN or (b) independently of the VPN, by choosing whether to use (a)

the VPN endpoint address or (b) the public internet address, to access the remote host. For example if you are on may.kg and you wish to connect to june.kg via sshwithout using the VPN (since ssh has its own built-in security) you would use the command ssh june.kg.

You can use any address you wish for the tunnel endpoints but make sure that they are private addresses (such as those that begin with 10 or 192.168) and that they are not part of any existing subnet on the networks of either peer, unless you are bridging.

Задача

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

Основная задача — это безопасное и простое решение доступа к внутренним ресурсам моих серверов.

Первый сервер является «домашним» серверов, подключенный к широкополосному соединению в городе под управлением CentOS 5.5, выполняющий различные функции, в том числе шлюза для квартирной сети. Назовем его CITY. Квартирная сеть использует адреса 192.168.22.0/24 и 192.168.21.0/24.

Второй сервер установлен на дальнем объекте, например, за городом на даче. Сервер работает под управлением CentOS 5.5 и выполняет функции шлюза для дачной сети и тоже выполняет другие задачи. Доступ в сеть осуществляется с помощью недорогого доступа по технологии 3G — в сервер воткнут USB 3g-модем и настроено устойчивое соединение. Назовем его CAMP. Дачная сеть использует адреса 192.168.23.0/24 и адреса 192.168.24.0/24.

А еще у меня есть ноутбук под управлением Windows XP, который вместе с владельцем попадает в разные сети, в том числе из дома, с работы и прочих гостевых мест, где есть доступ в Интернет. Назовем его NOTEBOOK.

Я хочу иметь доступ с ноутбука на мой домашний сервер CITY, в том числе к файлопомойке по NetBIOS и пр. А еще я хочу иметь доступ на сервер CAMP.

В случае CITY некоторые проблемы доступа можно решить публичным IP адресом. Но для CAMP публичный IP адрес у мобильных операторов практически недоступен или стоит неоправданно дорого для частного использования. А обычные клиенты работают через NAT. На ноутбуке проблемы сходные — как правило, везде NAT, бывают публичные открытые сети, где весь трафик виден всем пользователям.

Решением этих проблем является использование OpenVPN для связи всех компьютеров в единую сеть, заодно, защищенную от посторонних глаз.

Команды для управления туннелем

• ping < seconds > – указывает отсылать ping на удаленный конец тунеля после указанных n-секунд, если по туннелю не передавался никакой трафик. Пример:
  ping 10
• ping-restart < seconds > – если за указанное время не было получено ни одного пакета с удаленной стороны, то перезапускать туннель. Пример: ping-restart 60 – если в течении 60 секунд не было получено ни одного пакета, то туннель будет перезапущен.
• ping-timer-rem – позволяет перезапускать туннель, только когда указан удаленный адрес.
• persist-tun – данная опция оставляет без изменения устройства tun/tap при перезапуске OpenVPN.
• persist-key – указывает не перечитавать файлы ключей при перезапуске туннеля.
• resolv-retry < seconds > – устанавливает время в секундах для запроса об удаленном имени хоста. Актуально только если используется DNS-имя удаленного хоста. Пример: resolv-retry 86400
• inactive < seconds > – после n-секунд неактивности устройство TUN/TAP автоматически отключется. Пример: inactive 120
• ping-exit < seconds > – если за указанные n-секунд не было получено ни одного пакета, то отключать OpenVPN. Пример: ping-exit 120
• keepalive < seconds > < seconds > – является совмещением сразу двух команд – ping и ping-restart. Использует сразу два параметра в секундах, перечисленных через пробел. Пример: keepalive 10 180 – каждые 10 секунд посылать ping на удаленный хост, и, если за 180 секунд не было получено ни одного пакета – то перезапускать туннель.
• persist-local-ip < IP > – оставлять неизменными локальный IP адрес и номер порт, если туннель был перезапущен.
• persist-remote-ip < IP > – оставлять неизменными удаленный IP адрес и номер порт, если туннель был перезапущен. persist-remote-ip 192.168.50.1

Конфигурационный файл сервера openvpn

В папке “C:Program FilesOpenVPNconfig”, создаем текстовой документ server.ovpn – это будет конфиг сервера, вставляем в файл текст:

dev tun # Поднимаем L3-туннель
proto udp # Протокол
port 12345 # Порт который слушает впн
# Ключи и сертификаты:
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
topology subnet # Грубо говоря экономим адреса
server 10.9.0.0 255.255.255.0 # Пул адресов
cipher AES-128-CBC # Метод шифрования
comp-lzo # Сжатие
mssfix # Немного улучшит пинг
keepalive 10 120 # Время жизни клиентов, если не откликнулся — отключает
verb 3 # Уровень отладки

Пробуем запустить сервер: Кликаем на рабочем столе по ярлыку OpenVPN Gui или запускаем файл “C:Program FilesOpenVPNbinopenvpn-gui.exe”.

В панели задач возле к появится серый значок, кликаем по нему дважды, если через 10-20 секунд он загорелся зеленым, значит, все хорошо, если нет, тогда смотрим лог в папке log.

Настраиваем сервер

Итак шаги для настройки сервера на базе СentOS, впрочем они легко применимы и для FedoraProject и собственно RedHat Enterprise Linux и прочим RPM based дистрибутивам, ну а с небольшими изменениями вполне должны работать по Debian/Ubuntu.

На всякий случай, выключите репозиторий rpmforge, т.к. в нем openvpn собран с неверными путями. Я использую репозиторий epel для установки OpenVPN.

Ставим openvpn:

yum install openvpn

переходим в рабочий каталог

cd /usr/share/openvpn/easy-rsa/2.0/

Настраиваем параметры сервера (необязательно):

vi vars

Инициализируем переменные окружения, для последующего запуска скриптов:

source ./vars

Очищаем все на всякий случай:

./clean-all

Создаем сертификат CA

./build-ca

Создаем сертификат X.509

./build-key-server server

Создаем ключ Диффи-Хеллмана

./build-dh

Создаем ta.key (TLS сертификат)

openvpn --genkey --secret /usr/share/openvpn/easy-rsa/2.0/keys/ta.key

Настраиваем конфигурацию сервера:

vi /etc/openvpn/openvpn.conf

Вот такой конфиг файл я использую:

Настройка openvpn развернутое руководство и видео в 2021 [айти бубен]

ip route|grep default

sudonano/etc/ufw/before.rules

## rules.before## Rules that should be run before the ufw command line added rules. Custom# rules should be added to one of these chains:#   ufw-before-input#   ufw-before-output#   ufw-before-forward#
 
# START OPENVPN RULES# NAT table rules*nat
:POSTROUTING ACCEPT [0:0]# Allow traffic from OpenVPN client to eth0-A POSTROUTING -s 10.8.0.0/8-o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
 
# Don't delete these required lines, otherwise there will be errors*filter
. . .

DEFAULT_FORWARD_POLICY="ACCEPT"

sudo ufw allow 1194/udp

sudo ufw disable
sudo ufw enable

cd ~/openvpn-ca

cp vars vars.original

nano vars

cp openssl-1.0.0.cnf openssl.cnf

# This variable should point to
# the openssl.cnf file included
# with easy-rsa.
#export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_CONFIG=$EASY_RSA/openssl-1.0.0.cnf

~/openvpn-ca/vars
. . .
 
exportKEY_COUNTRY="US"exportKEY_PROVINCE="CA"exportKEY_CITY="SanFrancisco"exportKEY_ORG="Fort-Funston"exportKEY_EMAIL="[email protected]"exportKEY_OU="MyOrganizationalUnit"
 
. . .

~/openvpn-ca/vars
. . .
 
exportKEY_COUNTRY="UA"exportKEY_PROVINCE="NY"exportKEY_CITY="Kharkiv"exportKEY_ORG="Mirax"exportKEY_EMAIL="[email protected]"exportKEY_OU="MyPersonal"
 
. . .

~/openvpn-ca/vars
exportKEY_NAME="server"

./build-key-server server

. . .

Certificate is to be certified until May  1 17:51:16 2026 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

./build-dh

openvpn --genkey --secret keys/ta.key

# mkdir /etc/openvpn/ccd
# nano ccd/farm1c
push "route 192.168.1.0 255.255.255.0"
#push "route 192.168.35.0 255.255.255.0"
# static IP
ifconfig-push 192.168.14.21 192.168.14.22
#iroute 192.168.2.0 255.255.255.0

$ cd
$ touch .rnd

default_crl_days= 3000# how long before next CRL

$ cd ~/openvpn-ca
$ source vars

$ ./revoke-full client1

crl-verify crl.pem

# service openvpn restart

Wed Aug 2514:28:09 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Aug 2514:28:09 2021 TLS Error: TLS handshake failed

push "route 10.66.0.0 255.255.255.0"

Настройка клиента под centos на сервере camp

Выполняем

yum install openvpn

забираем клиентские файлы в каталог

/etc/openvpn/

ca.crt<br>
ta.key<br>
camp.crt<br>
camp.key<br>

создаем конфигурацию:

vi /etc/openvpn/openvpn.conf

конфигурация:

client
dev tun
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
float
verb 1
log-append      /var/log/openvpn.log
ca              ca.crt
tls-auth        ta.key 1
remote          22.33.44.55 1194
cert            camp.crt
key             camp.key

Разрешаем соединение в firewall. Само главное — обратные пакеты UDP пустить:

Я делаю так в своем любимом /etc/rc.d/rc.firewall:

Настройка клиентов openvpn

Настройка клиента начинается на сервере с получения ключей и сертификатов клиента, для этого перейдем в директорию центра сертификации и загрузим переменные:

cd /etc/openvpn/easy-rsa
source ./vars

Затем создадим ключевую пару клиента командой:

./build-key client

где client -имя клиента, мы также рекомендуем давать им осмысленные имена.

Теперь скопируем файлы, которые необходимо передать на компьютер клиента в домашнюю директорию и изменим их владельца (по умолчанию владелец – root), чтобы вы смогли их скопировать с помощью любого FTP или SFTP клиента. В нашем случае имя пользователя ubuntu:

cd /etc/openvpn/easy-rsa/keys
cp ca.crt client.crt client.key ~
cd ~
chown ubuntu:ubuntu ca.crt client.crt client.key

Помните, что закрытый ключ клиента client.key является секретным и следует избегать его передачи по открытым каналам связи.

Также не будет лишним сразу скопировать шаблон клиентской конфигурации:

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client.ovpn

После чего скопируйте все эти файлы на клиент и установите на нем OpenVPN, в Windows системах советуем изменить путь установки OpenVPN на более короткий и без пробелов, скажем, C:OpenVPN.

Затем откроем файл client.ovpn, который в Windows системах должен быть расположен в C:OpenVPNconfig, а в Linux в /etc/openvpn, и внесем в него следующие изменения:

client
dev tun
proto udp

Данные опции задают клиентский режим работы, тип туннеля и используемый протокол UDP.

Затем укажем адрес сервера:

remote 111.222.333.444 1194

Следующая опция предписывает клиенту постоянно разрешать имя OpenVPN-сервера, имеет смысл если мы указываем сервер по FQDN-имени, а не IP-адресу.

resolv-retry infinite

Для Linux систем обязательно укажите:

Настройка учетных записей клиентов

Для генерации и подписывания сертификатов используются два скрипта:

./build-key-pass <имя пользователя> 

— для создания сертификата с паролем и

./build-key <имя пользователя>

— для сертификата без пароля.

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

Создаем аккаунт для ноутбука:

заходим в каталог

cd /usr/share/openvpn/easy-rsa/2.0/

инициализируем окружение командой:

source ./vars

генерируем ключ для пользователя notebook с паролем:

./build-key-pass notebook

в подкаталоге

./keys

появится комплект файлов для авторизации.

А еще для клиента нужно настроить параметры сети, которые находятся в файлах с именем клиента

/etc/openvpn/ccd/

, в данном случае нужно редактировать файл

notebook

vi /etc/openvpn/ccd/notebook

В этом файле мы указываем адрес и другие сетевые параметры.

Самое главное — назначим адрес для клиента в нашей VPN подсети.

Дла совместимости со стеком TCP/IP Windows адреса клиентам назначаются с интервалом 4, фактически на каждого клиента выделяется подсеть с маской /30: адрес сети, адрес клиента, адрес шлюза, широковещательный адрес.

Вот здесь указан список возможных адресов