Как найти файл конфигурации openvpn

Starting the client

As in the server configuration, it’s best to initially start the OpenVPN server from the command line (or on Windows, by right-clicking on the client.ovpn file), rather than start it as a daemon or service:

openvpn [client config file] 

A normal client startup on Windows will look similar to the server output above, and should end with the Initialization Sequence Completed message.

Now, try a ping across the VPN from the client. If you are using routing (i.e. dev tun in the server config file), try:

ping 10.8.0.1

If you are using bridging (i.e. dev tap in the server config file), try to ping the IP address of a machine on the server’s ethernet subnet.

If the ping succeeds, congratulations! You now have a functioning VPN.

Troubleshooting

If the ping failed or the OpenVPN client initialization failed to complete, here is a checklist of common symptoms and their solutions:

• You get the error message: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity). This error indicates that the client was unable to establish a network connection with the server.Solutions:
  • Make sure the client is using the correct hostname/IP address and port number which will allow it to reach the OpenVPN server.
  • If the OpenVPN server machine is a single-NIC box inside a protected LAN, make sure you are using a correct port forward rule on the server’s gateway firewall. For example, suppose your OpenVPN box is at 192.168.4.4 inside the firewall, listening for client connections on UDP port 1194. The NAT gateway servicing the 192.168.4.x subnet should have a port forward rule that says forward UDP port 1194 from my public IP address to 192.168.4.4.
  • Open up the server’s firewall to allow incoming connections to UDP port 1194 (or whatever TCP/UDP port you have configured in the server config file).
• You get the error message: Initialization Sequence Completed with errors— This error can occur on Windows if (a) You don’t have the DHCP client service running, or (b) You are using certain third-party personal firewalls on XP SP2.Solution: Start the DHCP client server and make sure that you are using a personal firewall which is known to work correctly on XP SP2.
• You get the Initialization Sequence Completedmessage but the ping test fails — This usually indicates that a firewall on either server or client is blocking VPN network traffic by filtering on the TUN/TAP interface.Solution: Disable the client firewall (if one exists) from filtering the TUN/TAP interface on the client. For example on Windows XP SP2, you can do this by going to Windows Security Center -> Windows Firewall -> Advanced and unchecking the box which corresponds to the TAP-Windows adapter (disabling the client firewall from filtering the TUN/TAP adapter is generally reasonable from a security perspective, as you are essentially telling the firewall not to block authenticated VPN traffic). Also make sure that the TUN/TAP interface on the server is not being filtered by a firewall (having said that, note that selective firewalling of the TUN/TAP interface on the server side can confer certain security benefits. See the access policies section below).
• The connection stalls on startup when using a proto udpconfiguration, the server log file shows this line:
  

  TLS: Initial packet from x.x.x.x:x, sid=xxxxxxxx xxxxxxxx

  however the client log does not show an equivalent line.

  Solution: You have a one-way connection from client to server. The server to client direction is blocked by a firewall, usually on the client side. The firewall can either be (a) a personal software firewall running on the client, or (b) the NAT router gateway for the client. Modify the firewall to allow returning UDP packets from the server to reach the client.

See the FAQ for additional troubleshooting information.

Configuring OpenVPN to run automatically on system startup

The lack of standards in this area means that most OSes have a different way of configuring daemons/services for autostart on boot. The best way to have this functionality configured by default is to install OpenVPN as a package, such as via RPM on Linux or using the Windows installer.

Linux

If you install OpenVPN via an RPM or DEB package on Linux, the installer will set up an initscript. When executed, the initscript will scan for .conf configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.

Windows

The Windows installer will set up a Service Wrapper, but leave it turned off by default. To activate it, go to Control Panel / Administrative Tools / Services, select the OpenVPN service, right-click on properties, and set the Startup Type to Automatic. This will configure the service for automatic start on the next reboot.

When started, the OpenVPN Service Wrapper will scan the Program FilesOpenVPNconfig folder for .ovpn configuration files, starting a separate OpenVPN process on each file.

Controlling a running OpenVPN process

Running on Linux/BSD/Unix

OpenVPN accepts several signals:

• SIGUSR1 — Conditional restart, designed to restart without root privileges
• SIGHUP — Hard restart
• SIGUSR2 — Output connection statistics to log file or syslog
• SIGTERM, SIGINT — Exit

Use the writepid directive to write the OpenVPN daemon’s PID to a file, so that you know where to send the signal (if you are starting openvpn with an initscript, the script may already be passing a –writepid directive on the openvpn command line).

Running on Windows as a GUI

See the OpenVPN GUI page.

Running in a Windows command prompt window

On Windows, you can start OpenVPN by right clicking on an OpenVPN configuration file (.ovpn file) and selecting “Start OpenVPN on this config file”.

Once running in this fashion, several keyboard commands are available:

• F1 — Conditional restart (doesn’t close/reopen TAP adapter)
• F2 — Show connection statistics
• F3 — Hard restart
• F4 — Exit

Running as a Windows Service

When OpenVPN is started as a service on Windows, the only way to control it is:

• Via the service control manager (Control Panel / Administrative Tools / Services) which gives start/stop control.
• Via the management interface (see below).

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). If you would like to kill a currently connected client whose certificate has just been added to the CRL, use the management interface (described below).

Status File

The default server.conf file has a line

status openvpn-status.log

which will output a list of current client connections to the file openvpn-status.log once per minute.

Using the management interface

The OpenVPN management interface allows a great deal of control over a running OpenVPN process. You can use the management interface directly, by telneting to the management interface port, or indirectly by using an OpenVPN GUI which itself connects to the management interface.

To enable the management interface on either an OpenVPN server or client, add this to the configuration file:

management localhost 7505

This tells OpenVPN to listen on TCP port 7505 for management interface clients (port 7505 is an arbitrary choice — you can use any free port).

Once OpenVPN is running, you can connect to the management interface using a telnet client. For example:

ai:~ # telnet localhost 7505
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
help
Management Interface for OpenVPN 2.0_rc14 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 15 2005
Commands:
echo [on|off] [N|all]  : Like log, but only show messages in echo buffer.
exit|quit              : Close management session.
help                   : Print this message.
hold [on|off|release]  : Set/show hold flag to on/off state, or
                         release current hold and start tunnel.
kill cn                : Kill the client instance(s) having common name cn.
kill IP:port           : Kill the client instance connecting from IP:port.
log [on|off] [N|all]   : Turn on/off realtime log display
                         + show last N lines or 'all' for entire history.
mute [n]               : Set log mute level to n, or show level if n is absent.
net                    : (Windows only) Show network info and routing table.
password type p        : Enter password p for a queried OpenVPN password.
signal s               : Send signal s to daemon,
                         s = SIGHUP|SIGTERM|SIGUSR1|SIGUSR2.
state [on|off] [N|all] : Like log, but show state history.
status [n]             : Show current daemon status info using format #n.
test n                 : Produce n lines of output for testing/debugging.
username type u        : Enter username u for a queried OpenVPN username.
verb [n]               : Set log verbosity level to n, or show if n is absent.
version                : Show current version number.
END
exit
Connection closed by foreign host.
ai:~ #

For more information, see the OpenVPN Management Interface Documentation.

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

Including multiple machines on the server side when using a routed VPN (dev tun)

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.

Including multiple machines on the server side when using a bridged VPN (dev tap)

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

Including multiple machines on the client side when using a routed VPN (dev tun)

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

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2’s subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"

This will cause the OpenVPN server to advertise client2’s subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server’s LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won’t need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn’t know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

Including multiple machines on the client side when using a bridged VPN (dev tap)

This requires a more complex setup (maybe not more complex in practice, but more complicated to explain in detail):

• You must bridge the client TAP interface with the LAN-connected NIC on the client.
• You must manually set the IP/netmask of the TAP interface on the client.
• You must configure client-side machines to use an IP/netmask that is inside of the bridged subnet, possibly by querying a DHCP server on the OpenVPN server side of the VPN.

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. See the man page for non-Windows foreign_option_n documentation and script examples.

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.

Configuring client-specific rules and access policies

Suppose we are setting up a company VPN, and we would like to establish separate access policies for 3 different classes of users:

• System administrators — full access to all machines on the network
• Employees — access only to Samba/email server
• Contractors — access to a special server only

The basic approach we will take is (a) segregate each user class into its own virtual IP address range, and (b) control access to machines by setting up firewall rules which key off the client’s virtual IP address.

In our example, suppose that we have a variable number of employees, but only one system administrator, and two contractors. Our IP allocation approach will be to put all employees into an IP address pool, and then allocate fixed IP addresses for the system administrator and contractors.

Note that one of the prerequisites of this example is that you have a software firewall running on the OpenVPN server machine which gives you the ability to define specific firewall rules. For our example, we will assume the firewall is Linux iptables.

First, let’s create a virtual IP address map according to user class:

Next, let’s translate this map into an OpenVPN server configuration. First of all, make sure you’ve followed the steps above for making the 10.66.4.0/24 subnet available to all clients (while we will configure routing to allow client access to the entire 10.66.4.0/24 subnet, we will then impose access restrictions using firewall rules to implement the above policy table).

First, define a static unit number for our tun interface, so that we will be able to refer to it later in our firewall rules:

dev tun0

In the server configuration file, define the Employee IP address pool:

server 10.8.0.0 255.255.255.0

Add routes for the System Administrator and Contractor IP ranges:

route 10.8.1.0 255.255.255.0
route 10.8.2.0 255.255.255.0

Because we will be assigning fixed IP addresses for specific System Administrators and Contractors, we will use a client configuration directory:

client-config-dir ccd

Now place special configuration files in the ccd subdirectory to define the fixed IP address for each non-Employee VPN client.

ccd/sysadmin1

ifconfig-push 10.8.1.1 10.8.1.2

ccd/contractor1

ifconfig-push 10.8.2.1 10.8.2.2

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:

# Employee rule
iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.66.4.4 -j ACCEPT

# Sysadmin rule
iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.66.4.0/24 -j ACCEPT

# Contractor rule
iptables -A FORWARD -i tun0 -s 10.8.2.0/24 -d 10.66.4.12 -j ACCEPT

Using alternative authentication methods

OpenVPN 2.0 and later include a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client.

To use this authentication method, first add the auth-user-pass directive to the client configuration. It will direct the OpenVPN client to query the user for a username/password, passing it on to the server over the secure TLS channel.

Next, configure the server to use an authentication plugin, which may be a script, shared object, or DLL. The OpenVPN server will call the plugin every time a VPN client tries to connect, passing it the username/password entered on the client. The authentication plugin can control whether or not the OpenVPN server allows the client to connect by returning a failure (1) or success (0) value.

Using Script Plugins

Script plugins can be used by adding the auth-user-pass-verify directive to the server-side configuration file. For example:

auth-user-pass-verify auth-pam.pl via-file

will use the auth-pam.pl perl script to authenticate the username/password of connecting clients. See the description of auth-user-pass-verify in the manual page for more information.

The auth-pam.pl script is included in the OpenVPN source file distribution in the sample-scriptssubdirectory. It will authenticate users on a Linux server using a PAM authentication module, which could in turn implement shadow password, RADIUS, or LDAP authentication. auth-pam.pl is primarily intended for demonstration purposes. For real-world PAM authentication, use the openvpn-auth-pamshared object plugin described below.

Using Shared Object or DLL Plugins

Shared object or DLL plugins are usually compiled C modules which are loaded by the OpenVPN server at run time. For example if you are using an RPM-based OpenVPN package on Linux, the openvpn-auth-pam plugin should be already built. To use it, add this to the server-side config file:

plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login

This will tell the OpenVPN server to validate the username/password entered by clients using the loginPAM module.

For real-world production use, it’s better to use the openvpn-auth-pam plugin, because it has several advantages over the auth-pam.pl script:

• The shared object openvpn-auth-pam plugin uses a split-privilege execution model for better security. This means that the OpenVPN server can run with reduced privileges by using the directives user nobody, group nobody, and chroot, and will still be able to authenticate against the root-readable-only shadow password file.
• OpenVPN can pass the username/password to a plugin via virtual memory, rather than via a file or the environment, which is better for local security on the server machine.
• C-compiled plugin modules generally run faster than scripts.

If you would like more information on developing your own plugins for use with OpenVPN, see the README files in the plugin subdirectory of the OpenVPN source distribution.

To build the openvpn-auth-pam plugin on Linux, cd to the plugin/auth-pam directory in the OpenVPN source distribution and run make.

Using username/password authentication as the only form of client authentication

By default, using auth-user-pass-verify or a username/password-checking plugin on the server will enable dual authentication, requiring that both client-certificate and username/password authentication succeed in order for the client to be authenticated.

While it is discouraged from a security perspective, it is also possible to disable the use of client certificates, and force username/password authentication only. On the server:

client-cert-not-required

Such configurations should usually also set:

username-as-common-name

which will tell the server to use the username for indexing purposes as it would use the Common Name of a client which was authenticating via a client certificate.

Note that client-cert-not-required will not obviate the need for a server certificate, so a client connecting to a server which uses client-cert-not-required may remove the cert and key directives from the client configuration file, but not the ca directive, because it is necessary for the client to verify the server certificate.

How to add dual-factor authentication to an OpenVPN configuration using client-side smart cards

• About dual-factor authentication
• What is PKCS#11?
• Finding PKCS#11 provider library.
• How to configure a cryptographic token
• How to modify an OpenVPN configuration to make use of cryptographic tokens
  • Determine the correct object.
  • Using OpenVPN with PKCS#11.
  • PKCS#11 implementation considerations.
  • OpenSC PKCS#11 provider.
• Difference between PKCS#11 and Microsoft Cryptographic API (CryptoAPI).

About dual-factor authentication

Dual-factor authentication is a method of authentication that combines two elements: something you have and something you know.

Something you have should be a device that cannot be duplicated; such a device can be a cryptographic token that contains a private secret key. This private key is generated inside the device and never leaves it. If a user possessing this token attempts to access protected services on a remote network, the authorization process which grants or denies network access can establish, with a high degree of certainty, that the user seeking access is in physical possession of a known, certified token.

Something you know can be a password presented to the cryptographic device. Without presenting the proper password you cannot access the private secret key. Another feature of cryptographic devices is to prohibit the use of the private secret key if the wrong password had been presented more than an allowed number of times. This behavior ensures that if a user lost his device, it would be infeasible for another person to use it.

Cryptographic devices are commonly called “smart cards” or “tokens”, and are used in conjunction with a PKI (Public Key Infrastructure). The VPN server can examine a X.509 certificate and verify that the user holds the corresponding private secret key. Since the device cannot be duplicated and requires a valid password, the server is able to authenticate the user with a high degree of confidence.

Dual-factor authentication is much stronger than password-based authentication, because in the worst-case scenario, only one person at a time can use the cryptographic token. Passwords can be guessed and can be exposed to other users, so in the worst-case scenario an infinite number of people could attempt to gain unauthorized access when resources are protected using password-only authentication.

If you store the secret private key in a file, the key is usually encrypted by a password. The problem with this approach is that the encrypted key is exposed to decryption attacks or spyware/malware running on the client machine. Unlike when using a cryptographic device, the file cannot erase itself automatically after several failed decryption attempts.

What is PKCS#11?

This standard specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. Cryptoki, pronounced “crypto-key” and short for cryptographic token interface, follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token.

Source: RSA Security Inc. https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm.

To summarize, PKCS#11 is a standard that can be used by application software to access cryptographic tokens such as smart cards and other devices. Most device vendors provide a library that implements the PKCS#11 provider interface — this library can be used by applications in order to access these devices. PKCS#11 is a cross-platform, vendor-independent free standard.

Finding PKCS#11 provider library

The first thing you need to do is to find the provider library, it should be installed with the device drivers. Each vendor has its own library. For example, the OpenSC PKCS#11 provider is located at /usr/lib/pkcs11/opensc-pkcs11.so on Unix or at opensc-pkcs11.dll on Windows.

How to configure cryptographic token

You should follow an enrollment procedure:

• Initialize the PKCS#11 token.
• Generate RSA key pair on the PKCS#11 token.
• Create a certificate request based on the key pair, you can use OpenSC and OpenSSL in order to do that.
• Submit the certificate request to a certificate authority, and receive a certificate.
• Load the certificate onto the token, while noting that the id and label attributes of the certificate must match those of the private key.

A configured token is a token that has a private key object and a certificate object, where both share the same id and label attributes.

A simple enrollment utility is Easy-RSA 2.0 which is part of OpenVPN 2.1 series. Follow the instructions specified in the README file, and then use the pkitool in order to enroll.

Initialize a token using the following command:

$ ./pkitool --pkcs11-slots /usr/lib/pkcs11/
$ ./pkitool --pkcs11-init /usr/lib/pkcs11/  

Enroll a certificate using the following command:

$ ./pkitool --pkcs11 /usr/lib/pkcs11/   client1

How to modify an OpenVPN configuration to make use of cryptographic tokens

You should have OpenVPN 2.1 or above in order to use the PKCS#11 features.

Determine the correct object

Each PKCS#11 provider can support multiple devices. In order to view the available object list you can use the following command:

$ openvpn --show-pkcs11-ids /usr/lib/pkcs11/

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Certificate
       DN:             /CN=User1
       Serial:         490B82C4000000000075
       Serialized id:  aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600

Each certificate/private key pair have unique “Serialized id” string. The serialized id string of the requested certificate should be specified to the pkcs11-id option using single quote marks.

pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

Using OpenVPN with PKCS#11

A typical set of OpenVPN options for PKCS#11

pkcs11-providers /usr/lib/pkcs11/
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

This will select the object which matches the pkcs11-id string.

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. The token will be used for 300 seconds after which the password will be re-queried, session will disconnect if management session disconnects.

PKCS#11 implementation considerations

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.

OpenSC PKCS#11 provider

OpenSC PKCS#11 provider is located at /usr/lib/pkcs11/opensc-pkcs11.so on Unix or at opensc-pkcs11.dll on Windows.

Difference between PKCS#11 and Microsoft Cryptographic API (CryptoAPI)

PKCS#11 is a free, cross-platform vendor independent standard. CryptoAPI is a Microsoft specific API. Most smart card vendors provide support for both interfaces. In the Windows environment, the user should select which interface to use.

The current implementation of OpenVPN that uses the MS CryptoAPI (cryptoapicert option) works well as long as you don’t run OpenVPN as a service. If you wish to run OpenVPN in an administrative environment using a service, the implementation will not work with most smart cards because of the following reasons:

• Most smart card providers do not load certificates into the local machine store, so the implementation will be unable to access the user certificate.
• If the OpenVPN client is running as a service without direct interaction with the end-user, the service cannot query the user to provide a password for the smart card, causing the password-verification process on the smart card to fail.

Using the PKCS#11 interface, you can use smart cards with OpenVPN in any implementation, since PKCS#11 does not access Microsoft stores and does not necessarily require direct interaction with the end-user.

Routing all client traffic (including web-traffic) through the VPN

Overview

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.

In certain cases this behavior might not be desirable — you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.

Implementation

Add the following directive to the server configuration file:

push "redirect-gateway def1"

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

push "redirect-gateway local def1"

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site’s HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.

When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

push "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.

Caveats

Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:

• Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
• Issues exist with respect to pushing DNS addresses to Windows clients.
• Web browsing performance on the client will be noticably slower.

For more information on the mechanics of the redirect-gateway directive, see the manual page.

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:

• Use a NAT router appliance with dynamic DNS support (such as the Linksys BEFSR41). Most of the inexpensive NAT router appliances that are widely available have the capability to update a dynamic DNS name every time a new DHCP lease is obtained from the ISP. This setup is ideal when the OpenVPN server box is a single-NIC machine inside the firewall.
• Use a dynamic DNS client application such as ddclient to update the dynamic DNS address whenever the server IP address changes. This setup is ideal when the machine running OpenVPN has multiple NICs and is acting as a site-wide firewall/gateway. To implement this setup, you need to set up a script to be run by your DHCP client software every time an IP address change occurs. This script should (a) run ddclientto notify your dynamic DNS provider of your new IP address and (b) restart the OpenVPN server daemon.

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.

Connecting to an OpenVPN server via an HTTP proxy.

OpenVPN supports connections through an HTTP proxy, with the following authentication modes:

• No proxy authentication
• Basic proxy authentication
• NTLM proxy authentication

First of all, HTTP proxy usage requires that you use TCP as the tunnel carrier protocol. So add the following to both client and server configurations:

proto tcp

Make sure that any proto udp lines in the config files are deleted.

Next, add the http-proxy directive to the client configuration file (see the manual page for a full description of this directive).

For example, suppose you have an HTTP proxy server on the client LAN at 192.168.4.1, which is listening for connections on port 1080. Add this to the client config:

http-proxy 192.168.4.1 1080

Suppose the HTTP proxy requires Basic authentication:

http-proxy 192.168.4.1 1080 stdin basic

Suppose the HTTP proxy requires NTLM authentication:

http-proxy 192.168.4.1 1080 stdin ntlm

The two authentication examples above will cause OpenVPN to prompt for a username/password from standard input. If you would instead like to place these credentials in a file, replace stdin with a filename, and place the username on line 1 of this file and the password on line 2.

This example is intended show how OpenVPN clients can connect to a Samba share over a routed dev tun tunnel. If you are ethernet bridging (dev tap), you probably don’t need to follow these instructions, as OpenVPN clients should see server-side machines in their network neighborhood.

For this example, we will assume that:

• the server-side LAN uses a subnet of 10.66.0.0/24,
• the VPN IP address pool uses 10.8.0.0/24 (as cited in the server directive in the OpenVPN server configuration file),
• the Samba server has an IP address of 10.66.0.4, and
• the Samba server has already been configured and is reachable from the local LAN.

If the Samba and OpenVPN servers are running on different machines, make sure you’ve followed the section on expanding the scope of the VPN to include additional machines.

Next, edit your Samba configuration file (smb.conf). Make sure the hosts allow directive will permit OpenVPN clients coming from the 10.8.0.0/24 subnet to connect. For example:

hosts allow = 10.66.0.0/24 10.8.0.0/24 127.0.0.1

If you are running the Samba and OpenVPN servers on the same machine, you may want to edit the interfaces directive in the smb.conf file to also listen on the TUN interface subnet of 10.8.0.0/24:

interfaces  = 10.66.0.0/24 10.8.0.0/24

If you are running the Samba and OpenVPN servers on the same machine, connect from an OpenVPN client to a Samba share using the folder name:

\10.8.0.1\sharename

If the Samba and OpenVPN servers are on different machines, use folder name:

\10.66.0.4sharename

For example, from a command prompt window:

net use z: \10.66.0.4sharename /USER:myusername

Implementing a load-balancing/failover configuration

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. You can also direct the OpenVPN client to randomize its server list on startup, so that the client load will be probabilistically spread across the server pool.

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.

Server

The simplest approach to a load-balanced/failover configuration on the server is to use equivalent configuration files on each server in the cluster, except use a different virtual IP address pool for each server. For example:

server1

server 10.8.0.0 255.255.255.0

server2

server 10.8.1.0 255.255.255.0

server3

server 10.8.2.0 255.255.255.0

Hardening OpenVPN Security

One of the often-repeated maxims of network security is that one should never place so much trust in a single security component that its failure causes a catastrophic security breach. OpenVPN provides several mechanisms to add additional security layers to hedge against such an outcome.

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

proto udp

While OpenVPN allows either the TCP or UDP protocol to be used as the VPN carrier connection, the UDP protocol will provide better protection against DoS attacks and port scanning than TCP:

proto udp

user/group (non-Windows only)

OpenVPN has been very carefully designed to allow root privileges to be dropped after initialization, and this feature should always be used on Linux/BSD/Solaris. Without root privileges, a running OpenVPN server daemon provides a far less enticing target to an attacker.

user nobody
group nobody

Unprivileged mode (Linux only)

On Linux OpenVPN can be run completely unprivileged. This configuration is a little more complex, but provides best security.

In order to work with this configuration, OpenVPN must be configured to use iproute interface, this is done by specifying –enable-iproute2 to configure script. sudo package should also be available on your system.

This configuration uses the Linux ability to change the permission of a tun device, so that unprivileged user may access it. It also uses sudo in order to execute iproute so that interface properties and routing table may be modified.

OpenVPN configuration:

• • Write the following script and place it at: /usr/local/sbin/unpriv-ip:

#!/bin/sh
sudo /sbin/ip $*

• • Execute visudo, and add the followings to allow user ‘user1’ to execute /sbin/ip:

user1 ALL=(ALL)  NOPASSWD: /sbin/ip

• You can also enable a group of users with the following command:

%users ALL=(ALL)  NOPASSWD: /sbin/ip

• • Add the following to your OpenVPN configuration:

dev tunX/tapX
iproute /usr/local/sbin/unpriv-ip

• Please note that you must select constant X and specify tun or tap not both.
  • As root add persistant interface, and permit user and/or group to manage it, the following create tunX (replace with your own) and allow user1 and group users to access it.

openvpn --mktun --dev tunX --type tun --user user1 --group users

• Run OpenVPN in the context of the unprivileged user.

Further security constraints may be added by examining the parameters at the /usr/local/sbin/unpriv-ip script.

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. This is important from a security perspective, because even if an attacker were able to compromise the server with a code insertion exploit, the exploit would be locked out of most of the server’s filesystem.

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.

Larger RSA keys

The RSA key size is controlled by the KEY_SIZE variable in the easy-rsa/vars file, which must be set before any keys are generated. Currently set to 1024 by default, this value can reasonably be increased to 2048 with no negative impact on VPN tunnel performance, except for a slightly slower SSL/TLS renegotiation handshake which occurs once per client per hour, and a much slower one-time Diffie Hellman parameters generation process using the easy-rsa/build-dh script.

Larger symmetric keys

By default OpenVPN uses Blowfish, a 128 bit symmetrical cipher.

OpenVPN automatically supports any cipher which is supported by the OpenSSL library, and as such can support ciphers which use large key sizes. For example, the 256-bit version of AES (Advanced Encryption Standard) can be used by adding the following to both server and client configuration files:

cipher AES-256-CBC

Keep the root key (ca.key) on a standalone machine without a network connection

One of the security benefits of using an X509 PKI (as OpenVPN does) is that the root CA key (ca.key) need not be present on the OpenVPN server machine. In a high security environment, you might want to specially designate a machine for key signing purposes, keep the machine well-protected physically, and disconnect it from all networks. Floppy disks can be used to move key files back and forth, as necessary. Such measures make it extremely difficult for an attacker to steal the root key, short of physical theft of the key signing machine.

Revoking Certificates

Revoking a certificate means to invalidate a previously signed certificate so that it can no longer be used for authentication purposes.

Typical reasons for wanting to revoke a certificate include:

• The private key associated with the certificate is compromised or stolen.
• The user of an encrypted private key forgets the password on the key.
• You want to terminate a VPN user’s access.

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/emailAddress=me@myhost.mydomain
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.

CRL Notes

• When the crl-verify option is used in OpenVPN, the CRL file will be re-read any time a new client connects or an existing client renegotiates the SSL/TLS connection (by default once per hour). This means that you can update the CRL file while the OpenVPN server daemon is running, and have the new CRL take effect immediately for newly connecting clients. If the client whose certificate you are revoking is already connected, you can restart the server via a signal (SIGUSR1 or SIGHUP) and flush all clients, or you can telnet to the management interfaceand explicitly kill the specific client instance object on the server without disturbing other clients.
• While the crl-verify directive can be used on both the OpenVPN server and clients, it is generally unnecessary to distribute a CRL file to clients unless a server certificate has been revoked. Clients don’t need to know about other client certificates which have been revoked because clients shouldn’t be accepting direct connections from other clientsin the first place.
• The CRL file is not secret, and should be made world-readable so that the OpenVPN daemon can read it after root privileges have been dropped.
• If you are using the chrootdirective, make sure to put a copy of the CRL file in the chroot directory, since unlike most other files which OpenVPN reads, the CRL file will be read after the chroot call is executed, not before.
• A common reason why certificates need to be revoked is that the user encrypts their private key with a password, then forgets the password. By revoking the original certificate, it is possible to generate a new certificate/key pair with the user’s original common name.

Important Note on possible “Man-in-the-Middle” attack if clients do not verify the certificate of the server they are connecting to.

To avoid a possible Man-in-the-Middle attack where an authorized client tries to connect to another client by impersonating the server, make sure to enforce some kind of server certificate verification by clients. There are currently five different ways of accomplishing this, listed in the order of preference:

• [OpenVPN 2.1 and above]Build your server certificates with specific key usage and extended key usage. The RFC3280 determine that the following attributes should be provided for TLS connections:
  

  Mode	Key usage	Extended key usage
  Client	digitalSignature	TLS Web Client Authentication
  keyAgreement
  digitalSignature, keyAgreement
  Server	digitalSignature, keyEncipherment	TLS Web Server Authentication
  digitalSignature, keyAgreement

  You can build your server certificates with the build-key-server script (see the easy-rsadocumentation for more info). This will designate the certificate as a server-only certificate by setting the right attributes. Now add the following line to your client configuration:

  remote-cert-tls server

• [OpenVPN 2.0 and below] Build your server certificates with the build-key-server script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting nsCertType=server. Now add the following line to your client configuration:
  

  ns-cert-type server

  This will block clients from connecting to any server which lacks the nsCertType=server designation in its certificate, even if the certificate has been signed by the ca file in the OpenVPN configuration file.

• Use the tls-remotedirective on the client to accept/reject the server connection based on the common name of the server certificate.
• Use a tls-verifyscript or plugin to accept/reject the server connection based on a custom test of the server certificate’s embedded X509 subject details.
• Sign server certificates with one CA and client certificates with a different CA. The client configuration ca directive should reference the server-signing CA file, while the server configuration cadirective should reference the client-signing CA file.

Обновлено: 09.12.2021
Опубликовано: 20.07.2017

Тематические термины: OpenVPN, VPN, Windows, Linux, CentOS, Ubuntu

В данной инструкции подробно описан процесс настройки клиента OpenVPN на примере операционных систем Windows и Linux. Также, с ее помощью можно настроить скиента на Android.

Установка

Windows

Заходим на официальную страницу загрузки openvpn и скачиваем клиента для нужной Windows:

Запускаем скачанный файл и устанавливаем программу, нажимая «Далее».

Linux CentOS

Устанавливаем репозиторий EPEL:

yum install epel-release

Устанавливаем openvpn:

yum install openvpn

Linux Ubuntu

apt-get install openvpn

Android

Установка выполняется из Google Play. Набираем в поиске OpenVPN Connect – нажимаем установить и принимаем условия.

Настройка

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

В системах Windows создаем файл config.ovpn в папке %programfiles%OpenVPNconfig.

* имя файла может быть любым, расширение должно быть .ovpn.

Для создания конфигурационного файла в Linux выполняем команду:

vi /etc/openvpn/client.conf

* чтобы служба openvpn автоматически выполняла соединение, необходимо, чтобы конфигурационный файл назывался client.conf.

Пример конфигурационного файла

client
dev tun
proto udp
remote 192.168.0.15 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
dh dh2048.pem
tls-client
tls-auth ta.key 1
float
keepalive 10 120
comp-lzo
verb 0

Параметры конфигурационного файла

Наиболее полный и актуальный список параметров для OpenVPN можно получить командой openvpn –help (в Linux и Windows).

Сертификаты

Клиентские сертификаты генерируются на стороне сервера. Процедура следующая.

Для Linux:

cd /etc/openvpn/easy-rsa

. ./vars

./build-key client

Для Windows:

cd %ProgramFiles%OpenVPNeasy-rsa

vars.bat

build-key.bat client

* в выше приведенных примерах был сгенерирован клиентский сертификат client. Более подробно про создание сертификатов для клиентов читайте на страницах настройка openvpn на Windows и настройка openvpn на CentOS.

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

В итоге мы получаем, примерно, следующее.

Для Windows:

Для Linux:

ls /etc/openvpn/client/

ca.crt  client.crt  client.key  client.conf  dh2048.pem  ta.key

Запуск

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

Вручную

На Windows:

Запускаем OpenVPN GUI от имени администратора — в правом нижнем углу появится иконка программы:

Кликаем по ней правой кнопкой мыши и выбираем Подключиться:

На Linux:

Переходим в каталог с конфигурационным файлом:

cd /etc/openvpn

Вводим команду:

openvpn –config /etc/openvpn/client.conf

или:

systemctl start openvpn@client

* также служба может называться openvpn.

Автоматически

На Windows:

Выполняем 2 действия.

1. Наш конфигурационный файл с сертификатами переносим из каталога config в каталог config-auto:

* в старых версиях клиента каталога config-auto нет — тогда оставляем файлы в config.

2. Открываем службы и находим OpenVPNService. Переводим его в режим автозапуска:

На Linux:

Разрешаем автозапуск службы:

systemctl enable openvpn@client

или для старых версий.

CentOS / Red Hat / Fedora:

chkconfig openvpn on

Ubuntu / Debian:

update-rc.d openvpn defaults

Несколько конфигурационных файлов

Позволит держать несколько конфигураций для подключения к различным VPN-серверам. Между последними можно переключаться из клиентской программы.

Для Windows:

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

Пример каталога config:

Пример файлов в одном из каталогов:

Теперь при подключении клиентом к можно выбрать конкретный VPN-сервер:

Для Linux:

Также как для Windows, создаем для каждого сервера свой каталог, куда скопируем рабочие файлы:

mkdir /etc/openvpn/server1

А в каталоге /etc/openvpn создаем для каждого подключения свой конфиг:

vi /etc/openvpn/client1.conf

* в конфигурационном файле все пути до файлов должны вести в соответствующий каталог (в нашем примере, /etc/openvpn/server1).

Запускаем OpenVPN:

openvpn –config /etc/openvpn/server1/client.conf

Для автоматического запуска мы уже ранее применяли команду:

systemctl enable openvpn@client

… где @client — указатель на использование конфигурационного файла client внутри папки openvpn (/etc/openvpn). Таким образом, если мы создали 2 файла client1.conf и client2.conf, команды для разрешения автозапуска бelen такие:

systemctl enable openvpn@client1

systemctl enable openvpn@client2

Сертификаты внутри конфигурационного файла

Ключи сертификатов можно хранить не в отдельных файлах, а внутри конфигурационного файла ovpn.

* key-direction 1 — необходим для tls-auth, в противном случае, работать не будет; ca — ключ центра сертификации (ca.crt); tls-auth — ta.key; cert — открытый сертификат клиента (clients.crt); key — закрытый сертификат клиента (clients.key); dh — сертификат, созданный на базе протокола Диффи Хеллмана.

Отзыв сертификата

Для Linux:

cd /etc/openvpn/easy-rsa

. ./vars

./revoke-full client

Для Windows:

cd %ProgramFiles%OpenVPNeasy-rsa

vars.bat

revoke-full.bat client

* с помощью данных манипуляций мы отзываем сертификат client.

Читайте также

Настройка сервера OpenVPN на Windows

Установка и настройка OpenVPN на Linux CentOS 7

Настройка OpenVPN сервера с включением аутентификации через LDAP (Active Directory)

Настройка доступа к локальной сети клиентам OpenVPN в CentOS 7

Когда у нас появились сотрудники, работающие удаленно, пришлось думать над тем, как обеспечить им защищенный доступ к нашим хостинговым серверам, виртуальным выделенным серверам разработчиков Virtual Dedicated Server (VDS), сайтам обеспечения и сопровождения разработки и к другим ресурсам.

По соображениям безопасности доступ к этим ресурсам ограничен при помощи межсетевого экрана (файервола) по портам и адресам IP. Ежедневную перенастройку доступа при изменении динамических IP сотрудников едва ли можно назвать разумным решением.

Выход нашелся довольно быстро — это использование технологии виртуальных частных сетей Virtual Private Network (VPN) и ее свободной реализации OpenVPN. Эта реализация доступна практически для всех распространенных платформ, в том числе для планшетов и смартфонов. История развития OpenVPN насчитывает уже 12 лет (компания OpenVPN Technologies, Inc. была создана Francis Dinha и James Yona в 2002 году), так что это надежное и проверенное временем решение.

В нашей компании сеть VPN позволила предоставить защищенный доступ сотрудников к VDS, играющей роль сервера OpenVPN. И уже для фиксированного IP этого сервера был разрешен доступ к другим ресурсам компании. Попутно на сервере OpenVPN был установлен прокси Squid, что решило все проблемы доступа сотрудников с динамическими IP к защищенным ресурсам компании.

Теме OpenVPN посвящены многочисленные статьи и сообщения на форумах. Тем не менее, нужную информацию мне пришлось собирать по частям из разных мест. Попутно приходилось разбираться с многочисленными терминами и технологиями. В качестве серверов OpenVPN были использованы VDS на базе FreeBSD и Debian Linux, в качестве клиентов — рабочие станции FreeBSD, Debian Linux, Ubuntu и Microsoft Windows.

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

С благодарностью приму замечания и предложения по содержимому статьи.

Оглавление

• Немного теории
• Компоненты сети OpenVPN
• Готовим оборудование для установки OpenVPN
• Создание удостоверяющего центра CA
• Установка утилиты Easy-RSA
• Создание сервера OpenVPN
• Установка и запуск ПО клиента OpenVPN
• Установка прокси-сервера Squid
• Особенности установки на FreeBSD
• Особенности установки клиента OpenVPN в Microsoft Windows
• Полезные ссылки

Немного теории

Если раньше для создания безопасного канала передачи данных крупным компаниям и организациям приходилось прокладывать (либо арендовать) кабели и защищать их от физического доступа злоумышленников, то теперь в этом нет необходимости. С помощью VPN можно создавать защищенные виртуальные каналы, работающие через безопасный “туннель” в Интернете. Такое решение может позволить себе любая, даже очень небольшая компания.

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

Почему сеть VPN называется виртуальной и частной?

Виртуальная она потому, что узлы сети объединяются не физическими линиями, а виртуальными соединениями, которые создаются программным обеспечением (ПО) VPN.

Сеть VPN частная, так как к ней могут подключаться только узлы компании, создавшей эту сеть, а не все желающие. На каждом узле сети VPN должно работать ПО VPN. Еще там должны находиться ключи и сертификаты, обеспечивающие узлам доступ к сети VPN и криптографическую защиту передаваемых данных.

Таким образом, сеть VPN может объединять ресурсы (серверы и рабочие станции) компании в единую безопасную виртуальную сеть, созданную на базе Интернета. И теперь сотрудники, работающие удаленно (из дома или из другой страны) будут находиться как бы в общей сети своей компании. Сеть VPN подходит и для консолидации территориально разделенных офисов компании.

Обмен данными по сети

ПО OpenVPN передает данные по сети с помощью протоколов UDP или TCP с применением драйвера TUN/TAP. Протокол UDP и драйвер TUN позволяет подключаться к серверу OpenVPN клиентам, расположенным за NAT.

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

Безопасность и шифрование

Безопасность и шифрование в OpenVPN обеспечивается библиотекой OpenSSL и протоколом транспортного уровня Transport Layer Security (TLS). Вместо OpenSSL в новых версиях OpenVPN можно использовать библиотеку PolarSSL. Протокол TLS представляет собой усовершенствование протокола защищенной передачи данных уровня защищенных сокетов Secure Socket Layers (SSL).

В OpenSSL может использоваться симметричная и ассиметричная криптография.

В первом случае перед началом передачи данных на все узлы сети необходимо поместить одинаковый секретный ключ. При этом возникает проблема безопасной передачи этого ключа через небезопасный Интернет.

Во втором случае у каждого участника обмена данными есть два ключа — публичный (открытый) и приватный (секретный).

Публичный ключ используется для зашифрования данных, а приватный — для расшифрования. В основе шифрования лежит довольно сложная математика. Выбранный в SSL/TLS алгоритм зашифрования публичным ключом обеспечивает возможность расшифрования только с помощью приватного ключа.

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

Для безопасной передачи данных необходимо идентифицировать стороны, принимающие участие в обмене данными. В противном случае можно стать жертвой так называемой “атаки посредника” (Man in the Middle, MITM). В ходе такой атаки злоумышленник подключается к каналу передачи данных и прослушивает его. Он также может вмешиваться, удалять или изменять данные.

Чтобы обеспечить аутентификацию (проверку подлинности пользователя) протокол TLS использует инфраструктуру публичных ключей (Public Key Infrastructure, PKI) и асимметричную криптографию.

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

Хотя размер ключа влияет на сложность расшифрования, никакой ключ не дает гарантии полной безопасности данных. Кроме того, существует возможность похищения уже расшифрованных данных и ключей за счет уязвимостей и закладок в операционной системе или прикладном ПО, а также в аппаратном обеспечении серверов и рабочих станций.

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

Сертификаты и удостоверяющий центр CA

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

Сертификат должна заверить организация, которой доверяют. Эта организация играет роль удостоверяющего центра (Certification authority, CA).

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

Существует немало коммерческих организаций, выпускающих сертификаты, пригодные, например, для создания HTTPS-сайтов, для цифровой подписи сообщений электронной почты или документов, для систем мгновенного обмена сообщениями, такими как Jabber. Эти сертификаты выдаются на ограниченный срок и стоят денег.

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

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

Сертификаты создаются в соответствии со стандартом X.509. Этот стандарт определяет форматы данных и процедуры распределения открытых ключей с помощью сертификатов, снабженных электронными подписями.

Сертификат X.509 — это публичный ключ, содержащий такие данные, как субъект, владеющий сертификатом, имя узла, период действия, алгоритм и значение подписи сертификата, и т.д. Сертификат должен быть подписан приватным ключом удостоверяющего центра (Certification authority, CA).

Когда наш узел рабочей станции подключается к удаленному узлу (серверу) с использованием протокола TLS, сервер отправляет ему сертификат X.509. На нашем узле есть публичный ключ удостоверяющего центра CA, который подписал этот сертификат. Этот ключ используется для проверки подписи.

Таким образом, имеется способ проверки удаленного узла (сервера), к которому наш узел собирается подключиться, чтобы исключить “атаки посредника” MITM.

Список отзыва сертификатов

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

Для упрощения этой процедуры в OpenVPN предусмотрен список отзыва сертификатов (Сertificate Revocation List, CRL) и простые средства для управления этим списком.

Список CRL создается в удостоверяющем центре CA и потом копируется на сервер OpenVPN. После внесения изменений в список CRL его необходимо повторно скопировать на сервер OpenVPN.

Файл Диффи-Хелмана

Файл Диффи-Хелмана (Diffie-Hellman) необходим для реализации одноименного протокола, позволяющего использовать небезопасный канал для получения общего секретного ключа. Этот ключ будет в дальнейшем использоваться для защищенного обмена данными с помощью алгоритмов симметричного шифрования.

В применении к OpenVPN файл Диффи-Хелмана нужен для обеспечения защиты трафика от расшифровки, если ключи были похищены. Здесь имеется в виду тот трафик, который был записан и сохранен еще до похищения ключей.

Файл Диффи-Хелмана создается на сервере OpenVPN.

Статический ключ HMAC

Статический ключ (хэш-код) аутентификации сообщений (Hash-based Message Authentication Code, HMAC) обеспечивает проверку подлинности информации, передаваемой между сторонами. Этот ключ создается на сервере OpenVPN с целью дополнительной защиты от DoS-атак и флуда.

Компоненты сети OpenVPN

Прежде чем мы перейдем от теории к практике, перечислим основные компоненты сети OpenVPN и объекты, с которыми нам придется иметь дело.

Удостоверяющий центр CA

Выдает сертификаты по запросу узлов сети VPN, подписанные сертификатом удостоверяющего центра. Предоставляет узлам сети VPN свой собственный сертификат для проверки удостоверяющей стороны. Управляет списком отзыва сертификатов CRL.

Сервер OpenVPN

ПО сервера OpenVPN создает туннель внутри незащищенной сети, например, Интернета. Этот туннель обеспечивает безопасный зашифрованный трафик между узлами — участниками обмена данными в сети OpenVPN.

Клиент OpenVPN

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

Сертификаты (публичные ключи) X.509 

Сертификаты X.509 представляют собой публичные ключи, заверенные удостоверяющим центром CA. Они используются для зашифровывания данных. Факт заверения сертификата удостоверяющим центром CA позволяет идентифицировать сторону, передающую зашифрованные данные.

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

Приватные ключи

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

Приватные ключи создаются на узлах сети OpenVPN одновременно с файлом запроса на получение сертификата.

Список отзыва сертификатов CRL

Содержит список сертификатов, утративших доверие. Он создается и редактируется на узле удостоверяющего центра CA. Чтобы отключить узел от сети, достаточно занести его сертификат в список CRL.

После создания и каждого изменения список CRL переносится на серверы OpenVPN.

Файл Диффи-Хелмана

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

Статический ключ HMAC

Служит для проверки подлинности передаваемой информации. Обеспечивает защиту от DoS-атак и флуда. Создается на сервере OpenVPN.

Готовим оборудование для установки OpenVPN

Если вы впервые настраиваете сеть VPN, лучше всего экспериментировать на виртуальных машинах VDS. Это могут быть VDS, созданные локально на вашем компьютере или на сервере в вашей сети, либо арендованные у провайдера. Перед арендой VDS поинтересуйтесь, поддерживается ли драйвер TUN/TAP. Некоторые провайдеры требуют дополнительной оплаты для подключения TUN/TAP.

На рис. 1. мы показали схему стенда, на котором будем устанавливать компоненты и узлы OpenVPN (имена и адреса IP хостов могут быть другими).

Рис. 1. Стенд для изучения OpenVPN.

Здесь изображены три узла (хоста), для каждого из которых потребуется отдельный VDS:

• сервер OpenVPN (vpnsrv, 192.168.0.54);
• клиент OpenVPN (vpnclient, 192.168.0.55);
• удостоверяющий центр CA (ca, 192.168.0.53)

Хосты клиента и сервера VPN соединены обычным, небезопасным каналом. В случае макета это может быть локальная сеть, в реальной жизни — канал сети Интернет. ПО OpenVPN создает в этой сети канал, обозначенный на рис. 1 красным цветом, внутри которого устанавливается безопасный шифрованный канал (обозначен зеленым цветом).

В макете хост удостоверяющего центра CA можно подключить к вашей локальной сети. Для реальной работы хост CA нужно отсоединить от сети, а обмен сертификатами и ключами осуществлять с помощью, например, USB флэш-диска.

Если к безопасности предъявляются повышенные требования, хост CA необходимо поместить в охраняемое помещение — расположенная на этой машине информация позволяет создавать ключи доступа к вашей сети VPN.

Мы проводили установку серверов OpenVPN в среде ОС Debian Linux и FreeBSD, клиентов OpenVPN в ОС Debian Linux, FreeBSD и Microsoft Windows.

Основная часть статьи посвящена установке компонентов OpenVPN для Debian Linux. Далее мы рассмотрим особенности установки для FreeBSD и Microsoft Windows.

По возможности на узлах сети OpenVPN используйте новые версии ОС. Перед тем как приступить к работе с OpenVPN, обновите пакеты Linux:

# apt-get update
# apt-get upgrade

Установите на всех узлах пакет пакет zip, если он не был установлен ранее:

# aptitude install zip

Этот пакет будет нужен для распаковки архива утилиты Easy-RSA, с помощью которой мы будем создавать ключи и сертификаты.

На всех узлах настройте обновление и синхронизацию времени.

# apt-get install ntpdate
# apt-get install -y ntp
# /etc/init.d/ntp stop
# ntpdate pool.ntp.org
# /etc/init.d/ntp start

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

Дальнейшие работы мы начнем с подготовки хоста удостоверяющего центра CA. Затем установим хосты сервера и клиента OpenVPN.

Создание удостоверяющего центра CA

Как мы уже говорили, задача удостоверяющего центра CA — выдача подписанных сертификатов для сервера и клиентов OpenVPN.

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

Одновременно с запросом сертификата создается приватный ключ. Приватные ключи создаются для всех узлов сети OpenVPN: для удостоверяющего центра CA, для сервера и всех клиентов OpenVPN.

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

На рис. 2 показан процесс получения подписанного сертификата для сервера OpenVPN.

Рис. 2. Получение сертификата для сервера OpenVPN

Сервер OpenVPN создает свой приватный ключ и файл запроса на получение сертификата. Файл запроса передается в удостоверяющий центр, например, на USB флеш-диске.

Удостоверяющий центр на основе запроса создает подписанный сертификат, который затем требуется перенести на сервер OpenVPN, также на USB флэш-диске.

Если к безопасности не предъявляется особых требований или вы только изучаете OpenVPN, можно подключить машину удостоверяющего центра к сети и передавать запросы и сертификаты, например, с помощью утилит SFTP или SCP. Можно даже совместить функции CA и, например, сервера OpenVPN в одном хосте.

Аналогичным образом необходимо получить сертификаты для всех клиентских узлов (рис. 3).

Рис. 3. Получение сертификата для клиента OpenVPN

Установка утилиты Easy-RSA

Все операции по созданию ключей и сертификатов можно выполнить с помощью утилиты openssl. Однако проще воспользоваться специально созданной для этого программой Easy-RSA, которая использует openssl для выполнения действий с ключами и сертификатами.

Ранее утилита Easy-RSA поставлялась вместе с OpenVPN, но теперь это отдельный проект.

Все операции с удостоверяющим центром и сертификатами можно (и нужно) проводить от имени непривилегированного пользователя.

Создайте пользователя с именем, например, ca и перейдите в его домашний каталог:

# adduser ca
# su ca
$ cd

Загрузите дистрибутив программы утилитой wget.

$ wget https://github.com/OpenVPN/easy-rsa/archive/master.zip

После загрузки распакуйте архив master.zip:

$ unzip master.zip

В табл. 1 перечислены файлы и каталоги, входящие в дистрибутив Easy-RSA.

Таблица 1. Состав дистрибутива Easy-RSA.

Мы рекомендуем ознакомиться с файлом README.quickstart.md, а также с файлами из папки Doc. Для создания ключей и сертификатов нужно перейти в каталог easyrsa3, где находится исполнимый файл программы Easy-RSA.

Создание инфраструктуры публичных ключей PKI

На первом шаге создайте инфраструктуру публичных ключей (Public Key Infrastructure, PKI):

$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa init-pki

Вы увидите сообщение:

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/ca/easy-rsa-master/easyrsa3/pki

В результате выполнения команды init-pki был создан каталог /home/ca/easy-rsa-master/easyrsa3/pki, где и находится инфраструктура публичных ключей PKI.

На втором шаге с помощью команды build-ca создайте удостоверяющий центр CA:

$ ./easyrsa build-ca

В ответ на эту команду вам будет предложено ввести пароль и так называемое имя Common Name:

Generating a 2048 bit RSA private key
.....+++
................................................................+++
writing new private key to '/home/ca/easy-rsa-master/easyrsa3/pki/private/ca.key'
Enter PEM pass phrase:********
Verifying - Enter PEM pass phrase:********
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value, 
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:ca.mydomain.ru>
CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/ca/easy-rsa-master/easyrsa3/pki/ca.crt

Пароль будет защищать приватный ключ удостоверяющего центра, созданный в формате PEM (Privacy Enhancement for Internet Electronic Mail). Этот пароль потребуется каждый раз, когда вы будете подписывать в удостоверяющем центре сертификаты для серверов и клиентов OpenVPN.

Чтобы избавиться от необходимости ввода пароля, можно при запуске команды build-ca задать опцию nopass:

$ ./easyrsa build-ca nopass

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

В качестве Common Name задайте, например, доменное имя, выделенное для удостоверяющего центра CA, имя пользователя или хоста сервера CA.

Для удостоверяющего центра команда build-ca создаст два файла:

/home/ca/easy-rsa-master/easyrsa3/pki/private/ca.key
/home/ca/easy-rsa-master/easyrsa3/pki/ca.crt

Файл ca.key представляет собой приватный ключ центра CA, он секретный, и его нельзя переносить на другие узлы вашей сети.

Файл сертификата удостоверяющего центра ca.crt, напротив, открытый, и он будет нужен на узлах серверов и клиентов OpenVPN. Запишите файл ca.crt на USB флэш-диск, чтобы перенести на другие узлы.

Смонтировать USB флэш-диск, можно, например, так:

# fdisk -l
# mkdir /mnt/flash
# mount -t vfat /dev/sdb1 /mnt/flash

Здесь мы предполагаем, что USB флэш-диск стал устройством /dev/sdb1, а его файловая система — FAT32.

Копируем файл сертификата CA:

# cp /home/ca/easy-rsa-master/easyrsa3/pki/ca.crt /mnt/flash/ca.crt

Для работы с USB флэш-диском с файловой системой NTFS сначала установите пакет ntfs-3g:

# aptitude install ntfs-3g

Смонтируйте диск следующим образом:

# mount -t ntfs-3g /dev/sdb1 /mnt/flash

После окончания копирования размонтируйте USB диск:

# umount /mnt/flash

Создание списка отзывов сертификатов

Если сотрудник уволился, необходимо заблокировать его доступ в сеть VPN компании. Специально для этой цели в OpenVPN предусмотрен список отзыва сертификатов CRL. Создайте его такой командой:

$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa gen-crl

У вас будет запрошен пароль доступа к приватному ключу ca.key удостоверяющего центра. Список отзыва сертификатов будет создан в файле /home/ca/easy-rsa-master/easyrsa3/pki/crl.pem.

Скопируйте этот файл на USB флэш-диск:

# cp /home/ca/easy-rsa-master/easyrsa3/pki/crl.pem /mnt/flash

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

$ ./easyrsa revoke developer5

Здесь мы отозвали сертификат для клиента developer5. Далее нужно скопировать новый файл CRL на сервер OpenVPN и перезапустить демон OpenVPN.

Созданные файлы и каталоги PKI

В табл. 2 мы привели краткое описание некоторых файлов и каталогов PKI, созданных в результате наших действий.

Таблица 2. Структура каталога PKI.

Справка по утилите Easy-RSA

Запустите утилиту Easy-RSA без параметров:

$ ./easyrsa

На экране появится список всех команд утилиты, а также полный путь к программе и к PKI.

Для того чтобы получить справку по нужной команде, добавьте опцию help. Например, так можно получить справку по команде build-ca:

$ ./easyrsa help build-ca

Создание сервера OpenVPN

Процесс создания сервера OpenVPN включает в себя установку пакета openvpn, подготовку файлов конфигурации, ключей и сертификатов.

Установка пакета openvpn

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

# apt-get install openvpn

Подготовка файлов конфигурации

Файлы конфигурации, сертификаты и ключи нужно поместить в каталог /etc/openvpn, который будет создан автоматически в процессе установки пакета openvpn.

Прежде всего, подготовим файлы конфигурации openssl.cnf и server.conf. Первый из этих файлов определяет конфигурацию OpenSSL, второй — конфигурацию сервера OpenVPN.

В комплекте с утилитой Easy-RSA поставляется пример файла конфигурации OpenSSL (предполагается, что мы установили утилиту в домашний каталог пользователя ca):

/home/ca/easy-rsa-master/easyrsa3/openssl-1.0.cnf

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

В файле openssl.cnf указан абсолютный путь к каталогу с ключами и сертификатами, который вы только что создали.

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/openvpn
crl_dir = $dir
database = $dir/index.txt
new_certs_dir = $dir
certificate = $dir/ca.crt
serial = $dir
crl = $dir/crl.pem
private_key = $dir/server.key
RANDFILE = $dir/.rand
default_days = 3650
default_crl_days = 365
default_md = md5
unique_subject = yes
policy = policy_any
x509_extensions = user_extensions
[ policy_any ]
organizationName = match
organizationalUnitName = optional
commonName = supplied
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
x509_extensions = CA_extensions
[ req_distinguished_name ]
organizationName = Organization Name (must match CA)
organizationName_default = Company
organizationalUnitName = Location Name
commonName = Common User or Org Name
commonName_max = 64
[ user_extensions ]
basicConstraints = CA:FALSE
[ CA_extensions ]
basicConstraints = CA:TRUE
default_days = 3650
[ server ]
basicConstraints = CA:FALSE
nsCertType = server

Пример файла openvpn.conf конфигурации сервера OpenVPN есть на сайте проекта по адресу openvpn.net/index.php/open-source/documentation/howto.html#server. Мы предлагаем начать с сокращенной версии этого файла из нашей статьи.

port 1194
proto udp
dev tun
user openvpn
group openvpn
cd /etc/openvpn
persist-key
persist-tun
tls-server
tls-timeout 120
dh /etc/openvpn/dh.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/vpn-server.crt
key /etc/openvpn/server.key
crl-verify /etc/openvpn/crl.pem
tls-auth /etc/openvpn/ta.key 0
server 10.15.0.0 255.255.255.0
client-config-dir /etc/openvpn/ccd
client-to-client
topology subnet
max-clients 5
push "dhcp-option DNS 10.15.0.1"
route 10.15.0.0 255.255.255.0
comp-lzo
keepalive 10 120
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-server.log
verb 3
mute 20

Чтобы запуск сервера OpenVPN произошел успешно, необходимо создать каталоги, сертификаты и ключи, на которые есть ссылки в файлах openssl.cnf и server.conf, а также пользователя openvpn.

Создайте каталог для журнала сервера OpenVPN:

# mkdir /var/log/openvpn/

Создайте каталог для конфигураций клиентов (пока не используем):

# mkdir /etc/openvpn/ccd

Подготовка сертификата и ключа для сервера OpenVPN

Помимо openssl.cnf и openvpn.conf в каталоге /etc/openvpn/ нам потребуются файлы, перечисленные в табл. 3.

Таблица 3. Файлы для сервера OpenVPN.

Прежде всего мы создадим приватный ключ и файл запроса на сертификат для сервера OpenVPN, а также получим по созданному запросу в удостоверяющем центре CA подписанный сертификат. В результате у нас появятся файлы server.crt и server.key. Далее займемся остальными файлами, перечисленными в табл. 3.

Чтобы создать для сервера OpenVPN запрос на сертификат и приватный ключ, нам потребуется установить на сервер OpenVPN программу Easy-RSA, аналогично тому, как мы это делали для удостоверяющего центра CA.

Установку Easy-RSA, генерацию приватного ключа сервера OpenVPN и запроса на сертификат мы будем делать от имени пользователя vpnoperator, не имеющего привилегий администратора. Добавьте этого пользователя перед началом работ:

# adduser vpnoperator

Прежде всего, устанавливаем на сервере OpenVPN утилиту Easy-RSA и запускаем инициализацию инфраструктуры публичных ключей PKI:

$ cd /home/vpnoperator
$ wget https://github.com/OpenVPN/easy-rsa/archive/master.zip
$ unzip master.zip
$ cd /home/vpnoperator/easy-rsa-master/easyrsa3
$ ./easyrsa init-pki

После успешной инициализации PKI в консоли появится сообщение:

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /home/vpnoperator/easy-rsa-master/easyrsa3/pki

Так как наш сервер OpenVPN не будет играть роль удостоверяющего центра, то после инициализации PKI мы не будем создавать CA командой build-ca.

Инфраструктура PKI будет создана в каталоге /home/vpnoperator/easy-rsa-master/easyrsa3/pki.

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

$ ./easyrsa gen-req server

Этой командой будет создан файл запроса server.req и приватного ключа server.key. В процессе генерации у вас будет запрошен пароль, а также имя Common Name для сервера OpenVPN:

Generating a 2048 bit RSA private key
...............................................................................................................+++
....................................+++
writing new private key to '/home/vpnoperator/easy-rsa-master/easyrsa3/pki/private/server.key'
Enter PEM pass phrase:******
Verifying - Enter PEM pass phrase:******
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [server]: vpn-server
Keypair and certificate request completed. Your files are:
req: /home/vpnoperator/easy-rsa-master/easyrsa3/pki/reqs/server.req
key: /home/vpnoperator/easy-rsa-master/easyrsa3/pki/private/server.key

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

Как мы уже говорили, безопаснее всего передавать запрос на сертификат через USB флеш-диск, чтобы не подключать сервер CA к сети:

# fdisk -l
# mkdir /mnt/flash
# mount -t vfat /dev/sdb1 /mnt/flash
# cp /home/vpnoperator/easy-rsa-master/easyrsa3/pki/reqs/server.req /mnt/flash/server.req
# umount /mnt/flash

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

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

В этой ситуации можно создать приватный ключ без пароля с помощью опции nopass:

$ ./easyrsa gen-req server nopass

Итак, вы создали приватный ключ сервера OpenVPN и запрос на сертификат.

Смонтируйте USB флэш-диск на хосте удостоверяющего центра CA, а затем импортируйте от имени пользователя ca запрос в PKI:

# mount -t vfat /dev/sdb1 /mnt/flash
# su ca
$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa import-req /mnt/flash/server.req vpn-server

Здесь мы указали сокращенное имя запроса на сертификат как “vpn-server”. Это сокращенное имя будет использовано в дальнейших операциях с сертификатом.

После удачного импорта запроса вы увидите следующее сообщение:

The request has been successfully imported with a short name of: vpn-server
You may now use this name to perform signing operations on this request.

Если ошибок нет, подписываем запрос на получение сертификата:

./easyrsa sign-req server vpn-server

В процессе создания подписанного сертификата будет запрошено подтверждение (ответьте на него “yes”), а также пароль приватного ключа удостоверяющего центра CA:

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender.
Request subject, to be signed as a server certificate for 3650 days:

subject=
    commonName                = server
Type the word 'yes' to continue, or any other input to abort.
Confirm request details: yes
Using configuration from /home/ca/easy-rsa-master/easyrsa3/openssl-1.0.cnf
Enter pass phrase for /home/ca/easy-rsa-master/easyrsa3/pki/private/ca.key:******
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'server'
Certificate is to be certified until Jun 26 15:48:25 2024 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
Certificate created at: /home/ca/easy-rsa-master/easyrsa3/pki/issued/vpn-server.crt

Теперь сертификат получен, и он находится на сервере удостоверяющего центра в файле home/ca/easy-rsa-master/easyrsa3/pki/issued/vpn-server.crt. Этот файл нам нужно передать на сервер OpenVPN.

Скопируйте через USB флеш-диск файл сертификата /ca/easy-rsa-master/easyrsa3/pki/issued/vpn-server.crt с сервера удостоверяющего центра в файл на сервере OpenVPN /home/vpnoperator/vpn-server.crt:

# cp /home/ca/easy-rsa-master/easyrsa3/pki/issued/vpn-server.crt /mnt/flash/

Затем смонтируйте USB диск на VDS OpenVPN и скопируйте файлы ca.crt сертификата CA, список отзыва сертификатов crl.pem и сертификат vpn-server.crt сервера OpenVPN в каталог /etc/openvpn:

# mount -t vfat /dev/sdb1  /mnt/flash
# cp /mnt/flash/ca.crt /etc/openvpn
# cp /mnt/flash/crl.pem /etc/openvpn
# cp /mnt/flash/vpn-server.crt /etc/openvpn
# umount /mnt/flash

Файл приватного ключа скопируйте из каталога usr/home/vpnoperator/easy-rsa-master/easyrsa3/pki/private/ в каталог /etc/openvpn/:

# cp /home/vpnoperator/easy-rsa-master/easyrsa3/pki/private/server.key /etc/openvpn

Генерация файла Диффи-Хелмана

Создайте ключи Диффи-Хелмана следующей командой:

$ cd /home/vpnoperator/easy-rsa-master/easyrsa3
$ ./easyrsa gen-dh

Команда gen-dh работает довольно долго. По завершении вы увидите сообщение:

DH parameters of size 2048 created at /home/vpnoperator/easy-rsa-master/easyrsa3/pki/dh.pem

Скопируйте файл/home/vpnoperator/easy-rsa-master/easyrsa3/pki/dh.pem в каталог /etc/openvpn/ :

# cp /home/vpnoperator/easy-rsa-master/easyrsa3/pki/dh.pem /etc/openvpn

Создание статического ключа HMAC

Для создания ключа HMAC используйте команду openvpn с опциями –genkey и –secret:

# cd /etc/openvpn
# openvpn --genkey --secret ta.key

Запишите файл ta.key на USB диск:

# cp /etc/openvpn/ta.key /mnt/flash

Ревизия файлов перед запуском OpenVPN

Итак, мы получили из удостоверяющего центра подписанный сертификат сервера OpenVPN, сертификат самого удостоверяющего центра CA, список отзыва сертификатов, создали файл Диффи-Хелмана и ключ HMAC.

Перед тем как запустить демон OpenVPN, нам нужны в каталоге /etc/openvpn/ для Linux или /usr/local/etc/openvpn/ для FreeBSD следующие файлы:

• openssl.cnf — файл конфигурации OpenSSL;
• server.conf — файл конфигурации сервера OpenVPN;
• ca.crt — cертификат удостоверяющего центра;
• vpn-server.crt — cертификат сервера OpenVPN;
• server.key — приватный ключ сервера OpenVPN, секретный;
• crl.pem — cписок отзыва сертификатов;
• dh.pem — файл Диффи-Хелмана для обеспечения защиты трафика от расшифровки;
• ta.key — ключ HMAC для дополнительной защиты от DoS-атак и флуда

Добавление пользователя openvpn

Добавьте непривилегированного пользователя и группу openvpn, от имени которого будет работать демон сервера OpenVPN:

# adduser --system --no-create-home --home /nonexistent --disabled-login --group openvpn

Запуск демона OpenVPN

Запустите демон OpenVPN следующей командой:

# /etc/init.d/openvpn start

Проверка результата запуска демона OpenVPN

Если сервер OpenVPN стартовал без ошибок, убедитесь с помощью команды ifconfig в том, что появился интерфейс TUN:

# ifconfig 
...
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.15.0.1 P-t-P:10.15.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Как мы уже говорили, использование TUN/TAP на арендованных VDS может потребовать дополнительной оплаты.

Если все хорошо, то в интерфейсе tun появился адрес IP 10.15.0.1. Это адрес сервера OpenVPN в нашем защищенном туннеле, заданный в файле конфигурации server.conf.

После проверки наличия интерфейса TUN убедитесь, что OpenVPN занял порт 1194:

# netstat -ltupn | grep 1194

Если демон запустился нормально и порт 1194 занят сервером OpenVPN, можно переходить к установке клиента OpenVPN, описанной в следующем разделе статьи. При возникновении ошибок проанализируйте журнал /var/log/openvpn/openvpn-server.log.

При установке OpenVPN на Linux с новыми ядрами, начиная с 2.6, интерфейс TUN может не появится. При этом в логах появляется ошибка:

Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-tun instead

Чтобы избавиться от проблемы, добавьте в файл /etc/modprobe.d/dist.conf строку:

alias netdev-tun tun

Если такого файла нет, его следует создать. После внесения изменений в файл /etc/modprobe.d/dist.conf перезагрузите ОС.

Степень детализации журнала зависит от параметра verb файла конфигурации server.conf. Параметр verb может принимать значения от 0 до 11, при этом 11 соответствует максимальной детализации, а значение по умолчанию равно 1. Если значение параметра verb равно 0, то в журнал будут записываться сообщения только о наиболее серьезных, фатальных ошибках.

Для отладки установите значение этого параметра, равным 5 или выше.

Установка и запуск ПО клиента OpenVPN

Процедура установки клиента OpenVPN аналогична процедуре установки сервера OpenVPN. Основные отличия в файлах конфигурации. Перед установкой не забудьте обновить пакеты и порты.

# apt-get install openvpn

Подготовка файлов конфигурации

Файлы конфигурации, ключи и сертификаты должны находится в каталоге /etc/openvpn.

Далее подготовьте файлы конфигурации openssl.cnf и server.conf.

Файл openssl.cnf, определяющий конфигурацию OpenSSL, используйте точно такой же, как и для сервера OpenVPN. Что касается файла server.conf для клиента OpenVPN, то для начала возьмите его из нашей статьи.

dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/etc/openvpn/ca.crt"
cert "/etc/openvpn/developer1.crt"
key "/etc/openvpn/client.key"
tls-auth "/etc/openvpn/ta.key" 1
remote-cert-tls server
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log

Обратите внимание на параметр remote, в котором указан адрес IP сервера OpenVPN:

remote 192.168.0.54 1194

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

Создайте каталог для журнала клиента OpenVPN:

# mkdir /var/log/openvpn/

Создание инфраструктуры публичных ключей PKI

Подключитесь к хосту клиента OpenVPN (в нашем случае это хост разработчика ПО) с правами обычного пользователя developer1 и скачайте утилиту Easy-RSA с сайта github.com/OpenVPN/easy-rsa.

$ cd /home/developer1
$ wget https://github.com/OpenVPN/easy-rsa/archive/master.zip
$ unzip master.zip

Запустите инициализацию инфраструктуры публичных ключей PKI:

$ cd /home/developer1/easy-rsa-master/easyrsa3
$ ./easyrsa init-pki

В результате будет подготовлен каталог PKI:

/home/developer1/easy-rsa-master/easyrsa3/pki

Подготовка сертификата и ключа для клиента OpenVPN

Создайте запрос на сертификат и приватный ключ рабочей станции разработчика developer1:

$ ./easyrsa gen-req client nopass

Вам потребуется ввести имя Common Name для создания запроса на сертификат и приватного ключа рабочей станции:

Generating a 2048 bit RSA private key
..............................................................................................+sftp++
................................+++
writing new private key to '/home/developer1/easy-rsa-master/easyrsa3/pki/private/client.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [client]:developer1
Keypair and certificate request completed. Your files are:
req: /home/developer1/easy-rsa-master/easyrsa3/pki/reqs/client.req
key: /home/developer1/easy-rsa-master/easyrsa3/pki/private/client.key

Если к защите данных предъявляются повышенные требования, создавайте приватный ключ с паролем, без использования опции nopass:

$ ./easyrsa gen-req client

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

Теперь вам потребуется перенести созданный запрос сертификата /home/developer1/easy-rsa-master/easyrsa3/pki/reqs/client.req на хост удостоверяющего центра CA и записать в файл /home/ca/client.req.

Сделайте это с помощью USB флэш-диска, если хост CA не подключен к сети.

Запишите запрос на USB диск:

# mkdir /mnt/flash
# mount -t vfat /dev/sdb1  /mnt/flash
# cp /home/developer1/easy-rsa-master/easyrsa3/pki/reqs/client.req /mnt/flash
# umount /mnt/flash

Импортируйте запрос в PKI, используя в качестве короткого имени developer1:

$ cd /home/ca/easy-rsa-master/easyrsa3
$ ./easyrsa import-req /mnt/flash/client.req developer1

Далее подпишите запрос на получение сертификата:

$ ./easyrsa sign-req client developer1

После ввода подтверждения и пароля приватного ключа CA будет создан сертификат:

/home/ca/easy-rsa-master/easyrsa3/pki/issued/developer1.crt

Запишите файл developer1.crt на USB флэш-диск, чтобы перенести его на хост клиента OpenVPN.

# cp /home/ca/easy-rsa-master/easyrsa3/pki/issued/developer1.crt /mnt/flash
# umount /mnt/flash

Скопируйте файл сертификата в каталог /etc/openvpn:

# mount -t vfat /dev/sdb1  /mnt/flash
# cp /mnt/flash/developer1.crt /etc/openvpn

Итак, теперь у нас есть файл приватного ключа рабочей станции client.key и файл сертификата developer1.crt, подписанного удостоверяющим центром CA.

Скопируйте файл ключа в каталог /etc/openvpn:

# cp /home/developer1/easy-rsa-master/easyrsa3/pki/private/client.key /etc/openvpn

Скопируйте в каталог /etc/openvpn клиента VPN следующие файлы, подготовленные на USB диске:

# cp /mnt/flash/ca.crt /etc/openvpn
# cp /mnt/flash/ta.key /etc/openvpn

Напомним, что файлы ca.crt и crl.pem были созданы на хосте удостоверяющего центра CA, а файл ta.key — на хосте сервера OpenVPN.

Запуск клиента OpenVPN

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

# /etc/init.d/openvpn start

Если возникла проблема с запуском клиента, проверьте содержимое журнала /var/log/openvpn/openvpn-client.log

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

# ifconfig
...
 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
 inet addr:10.15.0.2 P-t-P:10.15.0.2 Mask:255.255.255.0
 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:100
 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Проверьте также, что сервер OpenVPN откликается на команду ping по адресу 10.15.0.1:

# ping 10.15.0.1

Установка прокси-сервера Squid

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

В качестве прокси-сервера мы выбрали ПО с открытым исходным кодом Squid, который часто применяется, в частности, для кэширования Web-страниц в высоконагруженных проектах. Нам, однако, сейчас пригодится только его функция проксирования.

Установку Squid проще всего выполнить из пакета:

# apt-get install squid3

После завершения установки в каталоге /etc/squid3 будет создан файл конфигурации squid.conf внушительных размеров, который необходимо отредактировать. Впрочем, в нашем случае требуется внести лишь очень небольшие изменения.

Прежде всего, отыщите в файле squid.conf следующую строку:

http_access deny all

Перед этой строкой добавьте:

acl allowed_hosts src 10.15.0.0/24
http_access allow allowed_hosts
http_access deny manager

Первая из этих строк разрешает доступ к Squid из вашей сети OpenVPN.

Если требуется проксировать доступ к каким-либо нестандартным портам SSL, добавьте их к строке:

acl SSL_ports port 443

Например, здесь мы добавили нестандартный порт 7195:

acl SSL_ports port 443 7195

Убедитесь, что в файле squid.conf разрешен доступ из сети 10.0.0.0/8. По умолчанию там есть такая строка:

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network

После завершения редактирования файла конфигурации перезапустите Squid:

# /etc/init.d/squid3 restart

Журналы Squid помогут при отладке, если что-то пойдет не так. Они находятся в каталоге /var/log/squid3. Это файлы access.log и cache.log.

После установки и запуска Squid пропишите в браузере прокси 10.15.0.1, порт 3128. Если все настроено правильно, браузер будет ходить в Интернет через ваш сервер OpenVPN. В этом можно убедиться, например, посетив сайт 2ip.ru, myip.ru или аналогичный, показывающий IP-адрес посетителя.

Особенности установки на FreeBSD

Перед началом работ обновите порты FreeBSD:

# portsnap fetch
# portsnap extract

Также позаботьтесь о настройке синхронизации времени на узлах сети OpenVPN. Однократная синхронизация выполняется так:

# ntpdate 1.pool.ntp.org

Вы можете добавить эту команду в задание cron. Также для синхронизации можно установить демон ntpd.

Установка утилиты Easy-RSA

Для загрузки дистрибутива используйте команду fetch:

$ fetch --no-verify-peer https://github.com/OpenVPN/easy-rsa/archive/master.zip

Опция –no-verify-peer позволяет избавиться от ошибки, которая возникает при проверке сертификата digicert.com в FreeBSD версии 10.0. FreeBSD версии 9.2 проверяет данный сертификат успешно, там эта опция не нужна.

В остальном приемы работы с утилитой Easy-RSA в среде FreeBSD ничем не отличаются от приемов работы в среде Debian Linux.

Установка сервера и клиента OpenVPN

Запустите установку OpenVPN на хосте сервера и клиентов OpenVPN из портов следующем образом:

# сd /usr/ports/security/openvpn
# make install clean

Файлы конфигурации OpenVPN

Файлы конфигурации сервера OpenVPN при его установке в ОС FreeBSD необходимо размещать в каталоге /usr/local/etc/openvpn.

Создайте этот каталог:

# mkdir /usr/local/etc/openvpn

Файлы конфигурации openssl.cnf и server.conf содержат путь к каталогу /usr/local/etc/openvpn.

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /usr/local/etc/openvpn
crl_dir = $dir2
database = $dir/index.txt
new_certs_dir = $dir
certificate = $dir/ca.crt
serial = $dir
crl = $dir/crl.pem
private_key = $dir/server.key
RANDFILE = $dir/.rand
default_days = 3650
default_crl_days = 365
default_md = md5
unique_subject = yes
policy = policy_any
x509_extensions = user_extensions
[ policy_any ]
organizationName = match
organizationalUnitName = optional
commonName = supplied
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
x509_extensions = CA_extensions
[ req_distinguished_name ]
organizationName = Organization Name (must match CA)
organizationName_default = Company
organizationalUnitName = Location Name
commonName = Common User or Org Name
commonName_max = 64
[ user_extensions ]
basicConstraints = CA:FALSE
[ CA_extensions ]
basicConstraints = CA:TRUE
default_days = 3650
[ server ]
basicConstraints = CA:FALSE
nsCertType = server 

port 1194
proto udp
dev tun
user openvpn
group openvpn
cd /usr/local/etc/openvpn
persist-key
persist-tun
tls-server
tls-timeout 120
dh /usr/local/etc/openvpn/dh.pem
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/server.crt
key /usr/local/etc/openvpn/server.key
crl-verify /usr/local/etc/openvpn/crl.pem
tls-auth /usr/local/etc/openvpn/ta.key 0
server 10.15.0.0 255.255.255.0
client-config-dir /usr/local/etc/openvpn/ccd
client-to-client
topology subnet
max-clients 5
push "dhcp-option DNS 10.15.0.1"
route 10.15.0.0 255.255.255.0
comp-lzo
keepalive 10 120
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-server.log
verb 3
mute 20

dev tun
proto udp
remote 192.168.0.54 1194
client
resolv-retry infinite
ca "/usr/local/etc/openvpn/ca.crt"
cert "/usr/local/etc/openvpn/developer1.crt"
key "/usr/local/etc/openvpn/client.key"
tls-auth "/usr/local/etc/openvpn/ta.key" 1
#ns-cert-type server
remote-cert-tls server
#ifconfig 10.15.0.0 255.255.255.0
persist-key
persist-tun
comp-lzo
verb 3
status /var/log/openvpn/openvpn-status.log 1
status-version 3
log-append /var/log/openvpn/openvpn-client.log

Создайте каталог для конфигураций клиентов:

# mkdir /usr/local/etc/openvpn/ccd

Работа с инфраструктурой PKI

Установите на сервере OpenVPN утилиту Easy-RSA и запустите инициализацию инфраструктуры публичных ключей PKI:

$ cd /home/vpnoperator
$ fetch https://github.com/OpenVPN/easy-rsa/archive/master.zip
$ unzip master.zip
$ cd /home/vpnoperator/easy-rsa-master/easyrsa3
$ ./easyrsa init-pki

В процессе передачи файлов запроса на сертификаты и подписанные сертификаты вы можете использовать USB флэш-диск. Ниже приведены команды для монтирования и размонтирования диска:

# ls  /dev/da*
# mount_msdosfs /dev/da1s1 /mnt
# umount /mnt

Здесь предполагается, что для USB флэш-диска выделено устройство /dev/da1s1.

Добавление пользователя openvpn

С помощью команды adduser добавьте пользователя openvpn. В качестве Shell для этого пользователя укажите nologin.

Запуск демона OpenVPN

Создайте каталог для записи журнала демона OpenVPN:

# mkdir /var/log/openvpn

Добавьте в файл /etc/rc.conf строки:

openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"

Здесь указан путь к рабочему файлу конфигурации демона OpenVPN.

Запустите демон OpenVPN:

# /usr/local/etc/rc.d/openvpn start

При успешном запуске на сервере и клиенте OpenVPN должен появится интерфейс TUN. Убедитесь в этом с помощью команды ifconfig:

# ifconfig
 ...
 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
 options=80000<LINKSTATE>
 inet6 fe80::20c:29ff:fe28:d4be%tun0 prefixlen 64 scopeid 0x3
 inet 10.15.0.1 --> 10.15.0.1 netmask 0xffffff00
 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
 Opened by PID 493

Проверьте, что демон сервера OpenVPN занял порт 1194:

# sockstat | grep 1194

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

Установка SQUID

В среде ОС FreeBSD мы выполнили установку Squid из портов:

# cd /usr/ports/www/squid33
# make install clean

Файл конфигурации Squid находится в каталоге /usr/local/etc/squid/ и называется squid.conf. В него надо внести такие же изменения, что и в случае установки для Debian Linux.

Для запуска добавьте в файл /etc/rc.conf строку:

squid_enable="YES"

Чтобы запустить Squid, используйте следующую команду:

/usr/local/etc/rc.d/squid start

Особенности установки клиента OpenVPN в Microsoft Windows

Для тех сотрудников, кто использует на своих рабочих станциях ОС Microsoft Windows, мы настроили доступ к серверу OpenVPN с помощью ПО OpenVPN-GUI. Дистрибутив OpenVPN-GUI можно скачать здесь.

Установка OpenVPN-GUI

Выберите вариант загрузки Windows Installer (64-bit) или Windows Installer (32-bit) в зависимости от разрядности вашей версии ОС Microsoft Windows. Далее запустите полученный файл и выполните установку по умолчанию. Файлы конфигурации, сертификаты и ключи необходимо записать в папку C:Program FilesOpenVPNconfig.

В папку C:Program FilesOpenVPNeasy-rsa устанавливается версия программы Easy-RSA для Windows.

Краткую инструкцию по использованию Easy-RSA для Windows вы найдете в файле C:Program FilesOpenVPNeasy-rsaREADME.txt

Мы рассмотрим вариант, при котором запрос на сертификат создается на хосте Microsoft Windows, а затем передается через USB флэш-диск на хост удостоверяющего центра CA. Там на основании запроса создается подписанный файл сертификата и, опять же, через USB флэш-диск, передается на хост Microsoft Windows.

Создание запроса на сертификат

Перейдем к процедуре создания запроса на сертификат.

Прежде всего, запустите консоль с правами администратора. Для удобства вместо стандартной консоли Microsoft Windows мы использовали бесплатный эмулятор консоли ConEmu-Maximus5.

Запустив консоль, перейдите в каталог Easy-RSA и выполните команды:

cd C:Program FilesOpenVPNeasy-rsa
init-config.bat
clean-all 

В результате будет создан каталог C:Program FilesOpenVPNeasy-rsakeys и файл vars.bat.

Отредактируйте в файле vars.bat строки по примеру, приведенному ниже, указав код своей страны KEY_COUNTRY и региона KEY_PROVINCE, название города KEY_CITY, компании KEY_ORG, адрес электронной почты KEY_EMAIL и название отдела KEY_OU:

set KEY_COUNTRY=RU
set KEY_PROVINCE=RU
set KEY_CITY=Moscow
set KEY_ORG=IT-Company
set KEY_EMAIL=develop@itcompany.ru
set KEY_CN=changeme
set KEY_NAME=changeme
set KEY_OU=IT

Создайте приватный ключ хоста и запрос на сертификат:

vars
build-ca
build-key client

Ответьте на вопросы, аналогичные тем, что задаются при создании ключей и сертификатов для узлов OpenVPN в Debian Linux или FreeBSD.

После этого в каталоге C:Program FilesOpenVPNeasy-rsakeys будет создан файл запроса сертификата client.csr, сертификат client.crt и файл приватного ключа клиента client.key.

Из этих файлов нам потребуются только два — запрос сертификата client.csr и приватный ключ client.key. Сертификат client.crt подписан приватным ключом хоста Microsoft Windows, созданным командой build-ca, и не подойдет для работы с нашим сервером OpenVPN. Тут необходим сертификат, созданный нашим удостоверяющим центром CA.

Получение сертификата от удостоверяющего центра CA

Скопируйте файл запроса сертификата client.csr через USB флэш-диск на хост удостоверяющего центра и создайте запрос, аналогично тому, как мы это делали для клиента OpenVPN на базе Debian Linux. Запишите полученный сертификат на USB флэш-диск, чтобы перенести его на хост Microsoft Windows.

Создание файла конфигурации клиента OpenVPN

Создайте файл конфигурации клиента OpenVPN в каталоге C:Program FilesOpenVPNconfig. Расширение имени этого файла должно быть ovpn. Вот пример нашего файла:

client
dev tun
proto udp
remote 192.168.0.54 1194
tls-client
ca "key/ca.crt"
cert "key/developer-w1.crt"
key "key/client.key"
tls-auth "key/ta.key" 1
comp-lzo
tun-mtu 1500
mssfix 1450
verb 3

Здесь предполагается, что мы скопировали в каталог C:Program FilesOpenVPNconfigkey следующие файлы:

• ca.crt — сертификат удостоверяющего центра CA;
• developer-w1.crt — сертификат хоста Microsoft Windows, подписанный удостоверяющим центром CA;
• client.key — приватный ключ хоста Microsoft Windows;
• ta.key — ключ HMAC для дополнительной защиты от DoS-атак и флуда, скопированный с сервера OpenVPN

Запуск OpenVPN-GUI

Запустите OpenVPN-GUI как обычное приложение Windows с помощью кнопки Пуск (существует также возможность запуска OpenVPN-GUI в качестве службы). В панели системных задач (в системном «трее», или в панели System Tray) появится значок OpenVPN-GUI в виде небольшого окна с замком.

Щелкните этот значок правой клавишей мыши и выберите имя файла конфигурации, который вы создали в каталоге C:Program FilesOpenVPNconfig. Если все настроено правильно, на экране появится окно соединения, в котором будут отображаться сообщения.

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

Чтобы разъединить канал OpenVPN, щелкните значок OpenVPN-GUI правой клавишей мыши и выберите из меню строку Отключиться.

Полезные ссылки

Протокол Диффи — Хеллмана

HMAC

Шифрование

X.509

OpenVPN: создание сервера на Windows

Центр сертификации или удостоверяющий центр (Certification authority, CA)

Была ли эта статья полезной?