OpenVPN [CentOS 5]
Certifikáty pro OpenVPN
PKI (Public key infrastructure) se skládá z těchto částí:
oddělený certifikát, také známý jako public key
a soukromý (privat) klíč pro server a každého klienta
Hlavní certifikační autority (CA)
a klíče, který je použitý pro podepsání každého
– ze serverových
– a klientských certifikátů.
TEDY:
public key (certifikát)
privat key
CA
podpisový klíč
OpenVPN podporuje obousměrnou autentifikaci, tzn, že
klient musí ověřit serverový certifikát
server musí ověřit klientský certifikát
Teprve potom je ustavena vzájemná důvěra.
Server i klient nejprve ověří, že přítomný certifikát byl podepsán hlavní certifikační autoritou (CA)
a potom ověří informace v hlavičce otestovaného certifikátu – jako je common name nebo typ certifikátu
(klient nebo server) – proto musí být common name správně vyplněno.
Tento bezpečnostní model má několik potřebných rysů z pohledu OpenVPN.
Server pouze potřebuje svůj vlastní (owner) certifikát/klíč.
Nepotřebuje znát individuální certifikáty každého klienta který se může připojitServer bude akceptovat pouze klienty, jejichž certifikáty byly podepsány hlavní CA autoritou
(kterou budeme generovat níž). A protože server může provést toto podpisové ověření
bez potřeby přístupu k CA privátnímu klíči samotnému, je možné pro CA klíč (nejvíc citlivé místo
/klíč v celém PKI) aby bydlel (sídlil) na kompletně jiném počítači klidně samostatně BEZ síťového připojení.Jestliže je privátní klíč zkompromitován, to může být vypnuto vložením tohoto certifikátu do CRL (
(certificate revocation list),. CRL dovoluje kompromitované certifikáty selektivně odmítnout (reject)
bez toho, aby muselo být celé PKI přestavěno.Server může vynutit zvláštní klientská přístupová práva
založená na vložených certifikátových polích jako je Common Name.
Vytvoření hlavní certifikační autority (CA), certifikátu a klíče
Nyní vytvoříme
hlavní CA certifikát / klíč
serverový certifikát / klíč
a certifikáty / klíče pro tři oddělené klienty
Použijeme sadu skriptů obsažených v OpenVPN.
V LINUXU:
Otevřeme shell a jdeme do easy-rsa podadresáře v OpenVPN distribuci.
Pokud jsme OpenVPN instalovali z rpm balíčku, normálně je tento podadresář
v /usr/share/doc/packages/openvpn nebo /usr/share/doc/openvpn-2.0.x
(nejlépe je kopírovat tento adresář na jiné mosto, např. /etc/openvpn,
před jakoukoli úpravou, takže budoucí upgrade OpenVPN balíčku nepřepíše vaše úpravy).
Pokud jsme instalovali z .tar.gz file, easy-rsa adresář bude
na vrchní části rozbaleného zdrojového stromu.
Soubor vars můžeme změnit – naše parametry hlavně v
KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parametry
učiníme adresář a soubory v něm spustitelné pro roota
chown -R 755 jmenoadresare(napriklad2.0)
V Linuxu/BSD/Unixu:
spustíme postupně všechny tři soubory
. ./vars
./clean-all
./build-ca
VE WINDOW$
V cmd řádce cd do \Program Files\OpenVPN\easy-rsa
Spustíme následující batch soubor a překopírujeme konfigurační soubor
tím přepíšeme každý preexistující vars bat a openssl.cnf soubor.
init-config
Nyní upravíme vars soubor – ve Windows se jmenuje vars.bat a určíme
KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parametry
Nenechávejte žádný z těchto parametrů nevyplněných.
Nyní inicializujeme PKI.
Ve Window$:
vars
clean-all
build-ca
Závěrečný příkaz (build–ca) vytvoří certifikační autoritu (CA) certificate a key vyvoláním interaktivního openssl příazu:
ai:easy-rsa # ./build-ca
Generating a 1024 bit RSA private key
............++++++
...........++++++
writing new private key to 'ca.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.
-----
Country Name (2 letter code) [KG]:
State or Province Name (full name) [NA]:
Locality Name (eg, city) [BISHKEK]:
Organization Name (eg, company) [OpenVPN-TEST]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:OpenVPN-CA
Email Address [me@myhost.mydomain]:
Většina parametrů vložených v ukázce je defaultně obsaženo v souborech vars nebo vars.bat
sou defaultní. Jediný parametr, který musí být výslovně vložen je Common Name. V příkladu je použito „OpenVPN-CA“.
Můj skutečný postup vypadal takto:
[root@internet easy-rsa]# [root@internet 2.0]# ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/2.0/keys
[root@internet 2.0]# ./clean-all
[root@internet 2.0]# ./build-ca
Generating a 1024 bit RSA private key
………………………………++++++
………………++++++
writing new private key to ‚ca.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.
—–
Country Name (2 letter code) [CS]:CS
State or Province Name (full name) [CA]:Liberecký kraj
Locality Name (eg, city) [Liberec]:Liberec
Organization Name (eg, company) [Profiltechnik]:Profiltechnik
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server’s hostname) [Profiltechnik CA]:Profiltechnik
Email Address [smolik@profiltechnik.cz]:smolik@profiltechnik.cz
[root@internet 2.0]#
Generování certifiátu a klíče pro server
Nyní vygenerujeme certifikát a privat key pro server
Linux/BSD/Unix:
./build-key-server server
Windows:
build-key-server server
Jako v předešlém příkladu většina parametrů může být defaultních. Když je požadováno Common Name vložte „server“.
Dva další požadavky vyžadují pozitivní odpověď. „Sign the certificate? [y/n]“
and „1 out of 1 certificate requests certified, commit? [y/n]“.
Můj skutečný výstup:
[root@internet 2.0]# ./build-key-server server
Generating a 1024 bit RSA private key
……………………………….++++++
……………………………++++++
writing new private key to ‚server.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.
—–
Country Name (2 letter code) [CS]:CS
State or Province Name (full name) [CA]:Liberecký kraj
Locality Name (eg, city) [Liberec]:Liberec
Organization Name (eg, company) [Profiltechnik]:Profiltechnik
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server’s hostname) [server]:Profiltechnik
Email Address [smolik@profiltechnik.cz]:smolik@profiltechnik.cz
Please enter the following ‚extra‘ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName :PRINTABLE:’CS‘
stateOrProvinceName :T61STRING:’Libereck\0xFFFFFFC3\0xFFFFFFBD kraj‘
localityName :PRINTABLE:’Liberec‘
organizationName :PRINTABLE:’Profiltechnik‘
organizationalUnitName:PRINTABLE:’IT‘
commonName :PRINTABLE:’Profiltechnik‘
emailAddress :IA5STRING:’smolik@profiltechnik.cz‘
Certificate is to be certified until Feb 8 14:08:46 2016 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
[root@internet 2.0]#
Generování certifiátů a klíčů pro tři klienty
Generování klientských certifikátů je velmi podobné předchozím krokům.
Linux/BSD/Unix:
./build-key client1
Můj skutečný výstup:
[root@internet 2.0]# ./build-key client1
Generating a 1024 bit RSA private key
...................................++++++
......................................................++++++
writing new private key to 'client1.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.
-----
Country Name (2 letter code) [CS]:CS
State or Province Name (full name) [CA]:Liberecký kraj
Locality Name (eg, city) [Liberec]:Liberec
Organization Name (eg, company) [Profiltechnik]:Profiltechnik
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) [client1]:client1
Email Address [smolik@profiltechnik.cz]:smolik@profiltechnik.cz
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CS'
stateOrProvinceName :T61STRING:'Libereck\0xFFFFFFC3\0xFFFFFFBD kraj'
localityName :PRINTABLE:'Liberec'
organizationName :PRINTABLE:'Profiltechnik'
organizationalUnitName:PRINTABLE:'IT'
commonName :PRINTABLE:'client1'
emailAddress :IA5STRING:'smolik@profiltechnik.cz'
Certificate is to be certified until Feb 8 14:13:57 2016 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
[root@internet 2.0]#
Stejným způsobem dále:
./build-key client2
./build-key client3
Windows:
build-key client1
build-key client2
build-key client3
Pokud chceme chránit naše klientské klíče heslem, nahraďte (substitute) build–key–pass script.
Pamatujte, že u každého klienta musíte vložit odpovídající Common Name když jste vyzvání. To je „client1“, „client2“, or „client3“.
Vždy použijte unikátní specifický Common Name pro každého klienta.
Pokud potřebujeme později přidat další klienty, stačí znovu spustit skript
./build-key jmenoklienta
a přidat potřebné klienty 🙂
—- všechno proběhlo v pořádku—— 😀
Generování Diffie Hellman parameterů
Diffie Hellman parametery musí být generovány pro OpenVPN server. Linux/BSD/Unix: ./build-dh Windows: build-dh Výstup: |
ai:easy-rsa # ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................+...........................................
...................+.............+.................+.........
......................................
Key Files
Nyní nalezneme náš nově generovaný klíč a certifikáty v podadresáři keys.
Zde je vysvětlení pro soubory:
Název | Potřebuje | Účel | Tajný |
ca.crt | server + all clients | Root CA certificate | NO |
ca.key | key signing machine only | Root CA key | YES |
dh{n}.pem | server only | Diffie Hellman parameters | NO |
server.crt | server only | Server Certificate | NO |
server.key | server only | Server Key | YES |
client1.crt | client1 only | Client1 Certificate | NO |
client1.key | client1 only | Client1 Key | YES |
client2.crt | client2 only | Client2 Certificate | NO |
client2.key | client2 only | Client2 Key | YES |
client3.crt | client3 only | Client3 Certificate | NO |
client3.key | client3 only | Client3 Key | YES |
Finální krok v procesu generování klíče je kopírování všech souborů na počítače, které je potřebují.
Buďte opatrní při kopírování secret files přes bezpečný kanál.
Dodatek – bezpečnější způsob tvorby
Now wait, you may say. Shouldn’t it be possible to set up the PKI without a pre-existing secure channel?
The answer is ostensibly yes. In the example above, for the sake of brevity, we generated all private
keys in the same place. With a bit more effort, we could have done this differently. For example,
instead of generating the client certificate and keys on the server, we could have had the client
generate its own private key locally, and then submit a Certificate Signing Request (CSR)
to the key-signing machine. In turn, the key-signing machine could have processed the CSR
and returned a signed certificate to the client. This could have been done without ever requiring
that a secret .key file leave the hard drive of the machine on which it was generated.
Creating configuration files for server and clientsGetting the sample config filesIt’s best to use the OpenVPN sample configuration files as a starting point for your own configuration. These files can also be found in
Note that on Linux, BSD, or unix-like OSes, the sample configuration files are named server.conf and client.conf. On Windows they are named server.ovpn and client.ovpn. Úprava konfiguračního souboru serveruVzorový konfigurační soubor serveru je ideální startovní bod pro konfiguraci OpenVPN serveru. Tp vytvpří VPN použitím virtuálního TUN síťového rozhraní (pro routování), bude naslouchat pro klientské spojení na UDP port 1194 (OpenVPN’s official port number), a distribuovat virtuální adresy pro připojení klientů z 10.8.0.0/24 podsítě. Předtím, než použijeme vzorový konfigurační soubor, nejdříve musíme editovat ca, cert, key, a dh parameters k bodu do souborů, které jsme generovali v PKI sekci výš. Od tohoto bodu je serverový konfigruační soubor použitelný, ačkoliv stále můžete chtít přizpůsobit později:
Pokud chcete spouštět víc OpenVPN instancí na jednom stroji, každá použiije jiný konfigurační soubor. To je možné, když:
Editace konfiguračního souboru na klientoviVzorový konfigurační soubor na klientovi (client.conf na Linux/BSD/Unix nebo client.ovpn na Windows) zrcadlí defaultní direktvy nastavené ve vzorovém konfiguračním souboru na serveru.
Mů Můj reálný konfigurační soubor:POZNÁMKA: pro klasický vpn tunel se dvěma konci a statickým klíčem se konfigurační soubor jmenuje vpn.conf Ovšem u konfigurace serveru se jmenuje server.conf a u konfigurace klienta client.conf Jesliže nastavujeme režim server, musím být povoleny tyto dvě volby: mode server Jinak OpenVPN neneaběhne… |
Jednoduché vzorové konfigurační soubory:
SERVER (server.conf):
local IP.ADRESA.SERVERU
port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
# Pro pevne prirazeni IP adres stanicim
# (vyplati se psat cele cesty
ifconfig-pool-persist /etc/openvpn/ipp.txt
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
client-config-dir ccd
client-to-client
keepalive 10 120
comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# kam se loguje
status /var/log/openvpn/openvpn_status.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 0
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
CLIENT (client1.conf) :
remote ip.adresa serveru 1194
client
dev tun
proto udp
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
# Most clients don’t need to bind to
# a specific local port number.
nobind
# Try to preserve some state across restarts.
persist-key
persist-tun
# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
# Set log file verbosity.
verb 3
# Silence repeating messages
;mute 20
# musime routovat do lokalni podsite serveru.
# Tuto routu zadavame zde na klientovi. Napriklad:.
route 192.168.0.0 255.255.255.0
Start klientaJako v konfiguraci servru je lepší startovat OpenVPN server z příkazové řádky (nebo ve Windows right-clickem na soubor client.ovpn ), raději než jako službu: openvpn [client config file] Výpis bude vypadat podobně jako výstup serveru nahoře a bude končit zprávou Initialization Sequence Completed. Nyní zkusíme pingnout napříč VPN z klienta na klienta. Pokud používáme routování (t.j. dev tun v server konfig souboru), zkusíme: ping 10.8.0.1 Pokud používáme bridging (t.j. dev tap v server config file), zkusíme pingnout IP addresy strojů na serverové ethernetové podsíti. Pokud je ping úspěšný, congratulations! Máte nyní funkční VPN. TroubleshootingIf the ping failed or the OpenVPN client initialization failed to complete, here is a checklist of common symptoms and their solutions:
See the FAQ for additional troubleshooting information. Configuring OpenVPN to run automatically on system startupThe 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. LinuxIf you install OpenVPN via an RPM 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. WindowsThe 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 Files\OpenVPN\config folder for .ovpn configuration files, starting a separate OpenVPN process on each file. Controlling a running OpenVPN processRunning on Linux/BSD/UnixOpenVPN accepts several signals:
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 GUIRunning in a Windows command prompt windowOn 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:
Running as a Windows ServiceWhen OpenVPN is started as a service on Windows, the only way to control it is:
Modifying a live server configurationWhile 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 FileThe 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 interfaceThe 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/24 and 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:
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 Files\OpenVPN\config. 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 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):
Pushing DHCP options to clientsThe 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_n environmental variable list. See the man page or openvpn-users mailing list archive 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" 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-Win32 adapter should show the DHCP options which were pushed by the server. Configuring client-specific rules and access policiesSuppose we are setting up a company VPN, and we would like to establish separate access policies for 3 different classes of users:
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: | |||||
Class | Virtual IP Range | Allowed LAN Access | Common Names | ||
Employees | 10.8.0.0/24 | Samba/email server at 10.66.4.4 | [variable] | ||
System Administrators | 10.8.1.0/24 | Entire 10.66.4.0/24 subnet | sysadmin1 | ||
Contractors | 10.8.2.0/24 | Contractor server at 10.66.4.12 | contractor1, contracter2 | ||
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 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/sysadmin1ifconfig-push 10.8.1.1 10.8.1.2 ccd/contractor1ifconfig-push 10.8.2.1 10.8.2.2 ccd/contractor2ifconfig-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-Win32 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 methodsOpenVPN 2.0 includes 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 PluginsScript 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–scripts subdirectory. 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-pam shared object plugin described below. Using Shared Object or DLL PluginsShared 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 login PAM 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:
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 authenticationBy 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 authenticationDual-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. http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html. 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. How to configure cryptographic tokenThe configuration of the cryptographic token is not in the scope of this document. You should follow an enrollment procedure:
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. How to modify an OpenVPN configuration to make use of cryptographic tokensYou should have OpenVPN 2.1 or above in order to use the PKCS#11 features. You can grab the latest beta from http://openvpn.net/beta/ or by using a subversion client to access the OpenVPN source repository at http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn. Finding PKCS#11 provider libraryThe 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. Determine the correct slotEach PKCS#11 provider can support multiple devices, one in each slot. In order to view the slot list you can use the following command: |
$ openvpn --show-pkcs11-slots /usr/lib/pkcs11/
Provider Information:
cryptokiVersion: 2.11
manufacturerID: ...
flags: 0
The following slots are available for use with this provider.
Each slot shown below may be used as a parameter to a
--pkcs11-slot-type and --pkcs11-slot options.
Slots: (id - name)
0 - My reader 00 00
1 - My reader 01 00
$ openvpn --show-pkcs11-objects /usr/lib/pkcs11/
PIN:
Token Information:
label: Token1
manufacturerID: ...
model: ...
serialNumber: 0104524263233729
flags: 0000040d
You can access this token using
pkcs11-slot-type "label" --pkcs11-slot "Token1" options.
The following objects are available for use with this token.
Each object shown below may be used as a parameter to
--pkcs11-id-type and --pkcs11-id options.
Object
Label: AUTH000-20050705B436961C5E5F6D2B
Id:
41 54 5f 4b 45 59 45 58 43 48 41 4e 47 45 1b ed
81 a2 96 62 24 c4 a8 0a f1 42 48 10 e6 5d 00
Type: Certificate
subject: /CN=User1
serialNumber: 2A5F4854000000000032
notBefore: 050705164745Z
Object
Label: AUTH000-20050705B436961C5E5F6D2B
Id:
41 54 5f 4b 45 59 45 58 43 48 41 4e 47 45 1b ed
81 a2 96 62 24 c4 a8 0a f1 42 48 10 e6 5d 00
Type: Private Key
Sign: TRUE
Sign Recover: TRUE
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. CaveatsRedirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:
For more information on the mechanics of the redirect–gateway directive, see the manual page. Running an OpenVPN server on a dynamic IP addressWhile OpenVPN clients can easily access the server via a dynamic IP address without any special configuration, things get more interesting when the server itself is on a dynamic address. While OpenVPN has no trouble handling the situation of a dynamic server, some extra configuration is required. The first step is to get a dynamic DNS address which can be configured to „follow“ the server every time the server’s IP address changes. There are several dynamic DNS service providers available, such as dyndns.org. The next step is to set up a mechanism so that every time the server’s IP address changes, the dynamic DNS name will be quickly updated with the new IP address, allowing clients to find the server at its new IP address. There are two basic ways to accomplish this:
The OpenVPN client by default will sense when the server’s IP address has changed, if the client configuration is using a remote directive which references a dynamic DNS name. The usual chain of events is that (a) the OpenVPN client fails to receive timely keepalive messages from the server’s old IP address, triggering a restart, and (b) the restart causes the DNS name in the remote directive to be re-resolved, allowing the client to reconnect to the server at its new IP address. More information can be found in the FAQ. Connecting to an OpenVPN server via an HTTP proxy.OpenVPN supports connections through an HTTP proxy, with the following authentication modes:
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. Connecting to a Samba share over OpenVPNThis example is intended |
http://openvpn.net/howto.html#pki
Vzorovný konfigurační soubor:
#################################################
# Sample OpenVPN 2.0 config file for #
# multi-client server. #
# #
# This file is for the server side #
# of a many-clients <-> one-server #
# OpenVPN configuration. #
# #
# OpenVPN also supports #
# single-machine <-> single-machine #
# configurations (See the Examples page #
# on the web site for more info). #
# #
# This config should work on Windows #
# or Linux/BSD systems. Remember on #
# Windows to quote pathnames and use #
# double backslashes, e.g.: #
# „C:\\Program Files\\OpenVPN\\config\\foo.key“ #
# #
# Comments are preceded with ‚#‘ or ‚;‘ #
#################################################
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194
# TCP or UDP server?
;proto tcp
; proto udp
# „dev tun“ will create a routed IP tunnel,
# „dev tap“ will create an ethernet tunnel.
# Use „dev tap“ if you are ethernet bridging.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use „dev-node“ for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don’t need this.
;dev-node MyTap
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the „easy-rsa“ directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see „pkcs12“ directive in man page).
ca ca.crt
cert server.crt
key server.key
# This file should be kept secret
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh dh1024.pem
#statický klíč u jednoduchého tunelu, podle kterého se bude šifrovat
;secret /etc/openvpn/secret.key
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
# server 10.8.0.0 255.255.255.0
# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
#ifconfig-pool-persist ipp.txt
# Configure server mode for ethernet bridging.
# You must first use your OS’s bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0. Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push „route 192.168.10.0 255.255.255.0“
;push „route 192.168.20.0 255.255.255.0“
# Push route to client to bind it to our local
# virtual endpoint.
push „route 192.168.100.1 255.255.255.255“
# Push any routes the client needs to get in
# to the local network.
push „route 192.168.1.0 255.255.255.0“
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory „ccd“ for client-specific
# configuration files (see man page for more info).
# EXAMPLE: Suppose the client
# having the certificate common name „Thelonious“
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious‘ private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using „dev tun“ and „server“ directives.
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# the TUN/TAP interface to the internet in
# order for this to work properly).
# CAVEAT: May break client’s network config if
# client’s local DHCP server packets get routed
# through the tunnel. Solution: make sure
# client’s local DHCP server is reachable via
# a more specific route than the default route
# of 0.0.0.0/0.0.0.0.
;push „redirect-gateway“
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
;push „dhcp-option DNS 10.8.0.1“
;push „dhcp-option WINS 10.8.0.1“
# Tady muzes nastavit pro klienta vnitrni DNS a WINS,
# aby mu fungovala vnitrni sit spravne
#
push „dhcp-option DNS 192.168.1.30“
push „dhcp-option WINS 192.168.1.30“
# push „dhcp-option DNS 192.168.1.250“
# push „dhcp-option DNS 192.168.1.240“
# push „dhcp-option WINS 192.168.1.250“
# push „dhcp-option NBDD 192.168.1.250“
# push „dhcp-option NBT 8“
# push „dhcp-option NTP 192.168.1.250“
# Uncomment this directive to allow different
# clients to be able to „see“ each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
;client-to-client
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE „COMMON NAME“,
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
;keepalive 10 120
# For extra security beyond that provided
# by SSL/TLS, create an „HMAC firewall“
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn –genkey –secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‚0‘
# on the server and ‚1‘ on the clients.
;tls-auth ta.key 0 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
# If you built OpenVPN with
# LZO compression, uncomment
# out the following line.
comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
# The server doesn’t need privileges
;user nobody
;group nobody
user openvpn
group openvpn
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
;persist-key
;persist-tun
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
;status openvpn-status.log
status /var/log/openvpn/status-internet.profiltechnik.cz.log
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the „\Program Files\OpenVPN\log“ directory).
# Use log or log-append to override this default.
# „log“ will truncate the log file on OpenVPN startup,
# while „log-append“ will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 9
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
# Tell OpenVPN to be a multi-client udp server
mode server
tls-server
# The server’s virtual endpoints – pro jednouchý tunel
;ifconfig 192.168.100.1 192.168.100.2
# Pool of /30 subnets to be allocated to clients.
# When a client connects, an –ifconfig command
# will be automatically generated and pushed back to
# the client.
#ifconfig-pool 192.168.100.10 192.168.100.254
#ifconfig-pool-persist ipp.txt
# Client should attempt reconnection on link
# failure.
;ping 10
#ping-restart 120
#push „ping 10“
#push „ping-restart 60“
# Delete client instances after some period
# of inactivity.
;inactive 600
# Route the –ifconfig pool range into the
# OpenVPN server.
;route 192.168.100.0 255.255.255.0
#tun-mtu 1500
#tun-mtu-extra 32
#mssfix 1450
Start VPN a test konektivity
Start serveru
Nejprve ověříme, že je OpenVPN server dostupný z internetu:
otevřeme UDP port 1194 na firewallu (nebo který TCP/UDP port budeme používat), nebo
nastavíme pravidla port forwadingu k forwardování UDP portu 1194 z firewalu/brány na stroj s běžícím OpenVPN serverem.
Dále, ujistěte se, že TUN/TAP interface není blokován firewallem.
Při potížích je výhodné spustit OpenVPN server z příkazového řádku (nebo right-click na .ovpn soubor ve Windows), raději než jako službu.
openvpn [server config file]
Normálně výpis startu serveru vypadá nějak takto (odchylky podle platformy):
Sun Feb 6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 5 2005
Sun Feb 6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key
Sun Feb 6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Feb 6 20:46:38 2005 TUN/TAP device tun1 opened
Sun Feb 6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Feb 6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Feb 6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Sun Feb 6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194
Sun Feb 6 20:46:38 2005 UDPv4 link remote: [undef]
Sun Feb 6 20:46:38 2005 MULTI: multi_init called, r=256 v=256
Sun Feb 6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62
Sun Feb 6 20:46:38 2005 IFCONFIG POOL LIST
Sun Feb 6 20:46:38 2005 Initialization Sequence Completed