Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Jan Just Keijser. OpenVPN 2 Cookbook (2011).pdf
Скачиваний:
193
Добавлен:
18.03.2016
Размер:
10.98 Mб
Скачать

12

New Features of OpenVPN 2.1 and 2.2

In this chapter, we will cover:

Inline certificates

Connection blocks

Port sharing with an HTTPS server

Routing features: redirect-private, allow-pull-fqdn

Handing out public IPs

OCSP support

New for 2.2: the x509_user_name parameter

Introduction

In this chapter, we will focus on some of the new features found in OpenVPN 2.1 and the upcoming 2.2 release. Many recipes from the previous chapters already made use of

OpenVPN 2.1-specific features (such as topology subnet), but a few other features introduced in OpenVPN 2.1 are less well known. The recipes in this chapter will cover some of these, such as the use of inline certificates, connection blocks, and port-sharing.

The upcoming 2.2 release of OpenVPN is mainly a bug-fix release, though a few new directives were introduced. In the last recipe of this chapter, we will focus on one of them.

New Features of OpenVPN 2.1 and 2.2

Inline certificates

To ease the deployment of OpenVPN configuration, public and private key files, a new feature is available to include all of them in a single file. This is done by integrating the contents of the ca, cert, key, and optionally the tls-auth file into the client configuration file itself. So, in this recipe, we will set up such a configuration file and use it to connect to our standard

OpenVPN server.

Getting ready

We use the following network layout:

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing at hand.

How to do it...

1.First, start the server:

[root@server]# openvpn --config basic-udp-server.conf

2.Create the client configuration file:

client proto udp

remote openvpnserver.example.com port 1194

dev tun nobind

ca [inline] cert [inline]

312

Chapter 12

key [inline] tls-auth [inline] 1

<ca>

-----BEGIN CERTIFICATE-----

# insert base64 blob from ca.crt

-----END CERTIFICATE-----

</ca>

<cert>

-----BEGIN CERTIFICATE-----

# insert base64 blob from client1.crt

-----END CERTIFICATE-----

</cert>

<key>

-----BEGIN PRIVATE KEY-----

# insert base64 blob from client1.key

-----END PRIVATE KEY-----

</key>

<tls-auth>

-----BEGIN OpenVPN Static key V1-----

# insert ta.key

-----END OpenVPN Static key V1-----

</tls-auth>

Insert the contents of the ca.crt, client1.crt, client1.key and ta.key files in the configuration. Save it as example12-1-client.conf.

3.Then, connect the client:

[root@client]# openvpn --config example12-1-client.conf

How it works...

When OpenVPN parses the configuration directives, ca, cert, key, and tls-auth (and dh for server configuration files), and it finds the value [inline], then an XML-like block must be present later in the configuration file. The contents of this XML-like block are then read and treated in the same manner as when a file is specified. When all the required configuration files or blocks are present, the connection is established.

Note that it is not required to treat all of the above configuration directives in the same manner. It is also possible to only specify an [inline] block for the CA certificate file, as this file tends to be static for all the clients.

313

New Features of OpenVPN 2.1 and 2.2

Connection blocks

Similar to the inline certificates used in the previous recipe, it is also possible to specify connection blocks. These connection blocks are treated as multiple definitions for remote servers and they are tried in order until a VPN connection is established. The advantage of using a connection block is that for each remote server, server-specific parameters can be specified, such as the protocol (UDP or TCP), the remote port, whether a proxy server should be used , and so on.

In this recipe, we will set up two servers, one listening on a UDP port and the other on a TCP port. We will then configure the OpenVPN client to try the first server using a UDP connection.

If the connection cannot be established, the client will attempt to connect to the second server using a TCP connection.

Getting ready

We use the following network layout:

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing at hand, as well as the server configuration file, example9-7-server.conf, from the

Chapter 9 recipe Tuning TCP-based connections.

How to do it...

1.Start both the servers:

[root@server1]# openvpn --config basic-udp-server.conf

[root@server2]# openvpn --config example9-7-server.conf

314

Chapter 12

2.Check the log files to check that both the servers have successfully started.

3.Create the client configuration file:

client dev tun

<connection>

remote openvpnserver1.example.com proto udp

port 1194 </connection>

<connection>

remote openvpnserver2.example.com proto tcp

port 1194 </connection>

ca

/etc/openvpn/cookbook/ca.crt

cert

/etc/openvpn/cookbook/client1.crt

key

/etc/openvpn/cookbook/client1.key

tls-auth /etc/openvpn/cookbook/ta.key 1

ns-cert-type server

Save it as example12-2-client.conf.

4.Start the client:

[root@client]# openvpn --config example12-2-client.conf

5.After the connection has been established, stop the first OpenVPN process on the server that the client connected to:

[root@server1]# killall openvpn

And wait for the client to reconnect. After the default timeout period, the client will reconnect to the alternate server using the TCP protocol.

How it works...

When the OpenVPN client starts up, it attempts to connect to the server specified in the first

<connection> block. If that connection fails, it will try the next <connection> block entry and so forth. When an OpenVPN server becomes unavailable or is stopped, the client will automatically restart and try to connect to the first available OpenVPN server again.

315

New Features of OpenVPN 2.1 and 2.2

The OpenVPN client first parses the global directives, which are specified outside the

<connection> blocks. For each block, the global directives are then overruled using block-specific directives. This makes it easier to specify in the <connection> blocks only those parameters that are different for each connection.

There's more...

Connection blocks, as well as inline certificates, are very handy new features introduced in OpenVPN 2.1. A consequence of these features is that the use of the command line to overrule the directives specified in the configuration file becomes harder, if not impossible. There are a few other things to keep in mind when using connection blocks.

Allowed directives inside connection blocks

There are only a few directives allowed inside a connection block:

bind

connect-retry, connect-retry-max, connect-timeout

float

http-proxy, http-proxy-option, http-proxy-retry, http-proxy- timeout

local lport

nobind

port

proto

remote, rport

socks-proxy, socks-proxy-retry

All other directives are considered global and can only be specified once.

Pitfalls when mixing TCP and UDP-based setups

Connection blocks make it very easy to mix TCP and UDP-based setups. The downside is that the global parameters specified in the configuration file must be valid for both the TCP and

UDP-based setups. This rules out the use of the commonly-used fragment directive, as well as a few other tuning parameters. It is expected that this shortcoming of <connection> blocks will be addressed in a future version of OpenVPN.

See also

Chapter 11's recipe, Multiple remotes & remote-random, which explains how to achieve the same setup without using connection blocks.

316