If you want more than just pre-shared keys OpenVPN makes it easy to setup and use a Public Key Infrastructure (PKI)
to use SSL/TLS certificates for authentication and key exchange
between the VPN server and clients.
OpenVPN can be used in a routed
or bridged VPN mode and can be configured to use either UDP or TCP. The
port number can be configured as well, but port 1194 is the official
one. And it is only using that single port for all communication. VPN
client implementations are available for almost anything including all
Linux distributions, OS X, Windows and OpenWRT based WLAN routers.
Server Installation
To install openvpn in a terminal enter:
sudo apt-get install openvpn
Public Key Infrastructure Setup
The first step in building an OpenVPN configuration is to establish a PKI (public key infrastructure). The PKI consists of:
- a separate certificate (also known as a public key) and private key for the server and each client, and
- a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates.
OpenVPN supports bidirectional authentication based on certificates,
meaning that the client must authenticate the server certificate and the
server must authenticate the client certificate before mutual trust is
established.
Both server and client will authenticate the other by first verifying
that the presented certificate was signed by the master certificate
authority (CA), and then by testing information in the now-authenticated
certificate header, such as the certificate common name or certificate
type (client or server).
Certificate Authority Setup
To setup your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients
first copy the easy-rsa directory to /etc/openvpn. This will ensure that any
changes to the scripts will not be lost when the package is updated.
From a terminal change to user root and:
mkdir /etc/openvpn/easy-rsa/ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/
Next, edit /etc/openvpn/easy-rsa/vars adjusting the following to your environment:
export KEY_COUNTRY="US" export KEY_PROVINCE="NC" export KEY_CITY="Winston-Salem" export KEY_ORG="Example Company" export KEY_EMAIL="steve@example.com"
Enter the following to generate the master Certificate Authority (CA) certificate and key:
cd /etc/openvpn/easy-rsa/ source vars ./clean-all ./build-ca
Server Certificates
Next, we will generate a certificate and private key for the server:
./build-key-server myservername
As in the previous step, most parameters can be defaulted. Two other
queries require positive responses, "Sign the certificate? [y/n]" and "1
out of 1 certificate requests certified, commit? [y/n]".
Diffie Hellman parameters must be generated for the OpenVPN server:
./build-dh
All certificates and keys have been generated in the
subdirectory keys/. Common practice is to copy them to /etc/openvpn/:
cd keys/ cp myservername.crt myservername.key ca.crt dh1024.pem /etc/openvpn/
Client Certificates
The VPN client will also need a certificate to authenticate
itself to the server. Usually you create a different certificate for
each client. To create the
certificate, enter the following in a terminal while being user
root:
cd /etc/openvpn/easy-rsa/ source vars ./build-key client1
Copy the following files to the client using a secure method:
- /etc/openvpn/ca.crt
- /etc/openvpn/easy-rsa/keys/client1.crt
- /etc/openvpn/easy-rsa/keys/client1.key
As the client certificates and keys are only required on the client machine, you should remove them from the server.
Simple Server Configuration
Along with your OpenVPN installation
you got these sample config files (and many more if if you check):
root@server:/# ls -l /usr/share/doc/openvpn/examples/sample-config-files/ total 68 -rw-r--r-- 1 root root 3427 2011-07-04 15:09 client.conf -rw-r--r-- 1 root root 4141 2011-07-04 15:09 server.conf.gz
Start with copying and unpacking server.conf.gz to /etc/openvpn/server.conf.
sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/ sudo gzip -d /etc/openvpn/server.conf.gz
Edit /etc/openvpn/server.conf to make sure the following lines are pointing to the certificates and keys you created in the section above.
ca ca.crt cert myservername.crt key myservername.key dh dh1024.pem
That is the minimum you have to configure to get a working
OpenVPN server.
You can use all the default settings in the sample server.conf file. Now
start the server. You will find logging and error messages in your
syslog.
root@server:/etc/openvpn# /etc/init.d/openvpn start * Starting virtual private network daemon(s)... * Autostarting VPN 'server' [ OK ]
Now check if OpenVPN created a tun0 interface:
root@server:/etc/openvpn# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
[...]
Simple Client Configuration
There are various different OpenVPN client implementations
with and without GUIs. You can read more about clients in a later section.
For now we use the OpenVPN client
for Ubuntu which is the same executable as the server. So you have to
install the openvpn package again on the client machine:
sudo apt-get install openvpn
This time copy the client.conf sample config file to /etc/openvpn/.
sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/
Copy the client keys and the certificate of the CA you created in the section above to e.g. /etc/openvpn/ and edit /etc/openvpn/client.conf to make sure the following lines are pointing to those files. If you have the files in /etc/openvpn/ you can omit the path.
ca ca.crt cert client1.crt key client1.key
And you have to at least specify the OpenVPN server name or address.
Make sure the keyword client is in the config. That's what enables
client mode.
client remote vpnserver.example.com 1194
Now start the OpenVPN client:
root@client:/etc/openvpn# /etc/init.d/openvpn start * Starting virtual private network daemon(s)... * Autostarting VPN 'client' [ OK ]
Check if it created a tun0 interface:
root@client:/etc/openvpn# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
Check if you can ping the OpenVPN server:
root@client:/etc/openvpn# ping 10.8.0.1 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. 64 bytes from 10.8.0.1: icmp_req=1 ttl=64 time=0.920 ms
The OpenVPN server always uses the first usable IP address in
the client network and only that IP is pingable. E.g. if you configured a
/24 for the client network mask, the .1 address will be used. The P-t-P
address you see in the ifconfig output above is usually not answering
ping requests.
Check out your routes:
root@client:/etc/openvpn# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.42.1 0.0.0.0 UG 0 0 0 eth0
First trouble shooting
If the above didn't work for you, check this:
- Check your syslog, e.g. grep -i vpn /var/log/syslog
- Can the client connect to the server machine? Maybe a firewall is blocking access? Check syslog on server.
- Client and server must use same protocol and port, e.g. UDP port 1194, see port and proto config option
- Client and server must use same config regarding compression, see comp-lzo config option
- Client and server must use same config regarding bridged vs routed mode, see server vs server-bridge config option
Advanved configuration
Advanced routed VPN configuration on server
The above is a very simple working VPN. The client can access services
on the VPN server machine through an encrypted tunnel. If you want to
reach more servers or anything in other networks, push some routes to
the clients. E.g. if your company's network can be summarized to the
network 192.168.0.0/16, you could push this route to the clients. But
you will also have to change the routing for the way back - your servers
need to know a route to the VPN client-network.
Or you might push a default gateway to all the clients to send all
their internet traffic to the VPN gateway first and from there via the
company firewall into the internet. This section shows you some possible
options.
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/24)
back to the OpenVPN server.
push "route 10.0.0.0 255.0.0.0"
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 or your central firewall may need to NAT
the TUN/TAP interface to the internet in order for this to work properly).
push "redirect-gateway def1 bypass-dhcp"
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.
server 10.8.0.0 255.255.255.0
Maintain a record of client to 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
Push DNS servers to the client.
push "dhcp-option DNS 10.0.0.2" push "dhcp-option DNS 10.1.0.2"
Allow client to client communication.
client-to-client
Enable compression on the VPN link.
comp-lzo
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 1 second, assume that remote
peer is down if no ping received during
a 3 second time period.
keepalive 1 3
It's a good idea to reduce the OpenVPN daemon's privileges after initialization.
user nobody group nogroup
OpenVPN 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.
# client config! auth-user-pass
This will tell the OpenVPN server to validate the
username/password entered by clients using the login PAM module.
Useful if you have centralized authentication with e.g. Kerberos.
plugin /usr/lib/openvpn/openvpn-auth-pam.so login
Please read the OpenVPN hardening security guide for further security advice.
Advanced bridged VPN configuration on server
OpenVPN can be setup for
either a routed or a bridged VPN mode. Sometimes this is also referred
to as OSI layer-2 versus layer-3 VPN. In a bridged VPN all layer-2
frames - e.g. all ethernet frames - are sent to the VPN partners and in a
routed VPN only layer-3 packets are sent to VPN partners.
In bridged mode all traffic including traffic which was traditionally
LAN-local like local network broadcasts, DHCP requests, ARP requests
etc. are sent to VPN partners whereas in routed mode this would be
filtered.
Prepare interface config for bridging on server
Make sure you have the bridge-utils package installed:
sudo apt-get install bridge-utils
Before you setup OpenVPN in bridged mode you need to change your
interface configuration. Let's assume your server has an interface eth0
connected to the internet and an interface eth1 connected to the LAN you
want to bridge. Your /etc/network/interfaces would like this:
auto eth0 iface eth0 inet static address 1.2.3.4 netmask 255.255.255.248 default 1.2.3.1 auto eth1 iface eth1 inet static address 10.0.0.4 netmask 255.255.255.0
This straight forward interface config needs to be changed into a
bridged mode like where the config of interface eth1 moves to the new
br0 interface. Plus we configure that br0 should bridge interface eth1.
We also need to make sure that interface eth1 is always in promiscuous
mode - this tells the interface to forward all ethernet frames to the IP
stack.
auto eth0 iface eth0 inet static address 1.2.3.4 netmask 255.255.255.248 default 1.2.3.1 auto eth1 iface eth1 inet manual up ip link set $IFACE up promisc on auto br0 iface br0 inet static address 10.0.0.4 netmask 255.255.255.0 bridge_ports eth1
At this point you need to restart networking. Be prepared that this
might not work as expected and that you will lose remote connectivity.
Make sure you can solve problems having local access.
sudo /etc/init.d/network restart
Prepare server config for bridging
Edit /etc/openvpn/server.conf changing the following options to:
;dev tun dev tap up "/etc/openvpn/up.sh br0 eth1" ;server 10.8.0.0 255.255.255.0 server-bridge 10.0.0.4 255.255.255.0 10.0.0.128 10.0.0.254
Next, create a helper script to add the tap interface to the bridge and to ensure that eth1 is promiscuous mode. Create /etc/openvpn/up.sh:
#!/bin/sh BR=$1 ETHDEV=$2 TAPDEV=$3 /sbin/ip link set "$TAPDEV" up /sbin/ip link set "$ETHDEV" promisc on
sumber:https://help.ubuntu.com
0 comments:
Post a Comment