最后这两行指示客户端用OpenVPN作为默认的网关,并用10.8.0.1作为DNS服务器。注意10.8.0.1是OpenVPN启动时自动创建的隧道接口的IP。If the clients were to use any other server for name resolution, then we would have a situation in which all DNS requests were served from a possibly untrustworthy server. To avoid such DNS leaks, we instruct all OpenVPN clients to use 10.8.0.1 as the DNS server.
By default, OpenVPN listens for connections on port 1194/UDP. One way to see that is with the netstat tool:
root@delta:/etc/openvpn# netstat -anup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:54149 0.0.0.0:* 555/dhclient
udp 0 0 0.0.0.0:1194 0.0.0.0:* 3024/openvpn
udp 0 0 0.0.0.0:53 0.0.0.0:* 2756/dnsmasq
udp 0 0 0.0.0.0:68 0.0.0.0:* 555/dhclient
udp6 0 0 :::60622 :::* 555/dhclient
udp6 0 0 :::53 :::* 2756/dnsmasq
All is well, though we have no properly configured DNS server for the clients yet.
### Step 07 -- A DNS service for OpenVPN clients ###
That’s why we’ve installed dnsmasq for. We open up its configuration file
root@delta:/etc/openvpn# nano /etc/dnsmasq.conf
locate this line
#listen-address=
and change it into the following one:
listen-address=127.0.0.1, 10.8.0.1
We also locate this line
#bind-interfaces
and delete the hash character on the left:
bind-interfaces
To make dnsmasq take these changes into account, we just restart the service:
root@delta:/etc/openvpn# service dnsmasq restart
* Restarting DNS forwarder and DHCP server dnsmasq [ OK ]
root@delta:/etc/openvpn#
As it is now, dnsmasq listens for DNS requests from the loopback (lo) and also from the tunnel (tun0) interface. The output of netstat confirms that:
root@delta:/etc/openvpn# netstat -anup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:57219 0.0.0.0:* 638/dhclient
udp 0 0 0.0.0.0:1194 0.0.0.0:* 911/openvpn
udp 0 0 127.0.0.1:53 0.0.0.0:* 1385/dnsmasq
udp 0 0 10.8.0.1:53 0.0.0.0:* 1385/dnsmasq
udp 0 0 0.0.0.0:68 0.0.0.0:* 638/dhclient
udp6 0 0 :::39148 :::* 638/dhclient
### Step 08 -- Router functionality ###
We want the VM/box our OpenVPN server runs on to behave like a router, and that means that IP forwarding must be enabled. To enable it right now, from the root account we just type
> This is crucial: During system startup dnsmasq tries to come up before OpenVPN does. But without OpenVPN there is no tunnel interface (tun0) present so naturally dnsmasq fails. A bit later, when /etc/rc.local is read the tun0 interface is present, so at this point we restart dnsmasq and everything is as it's supposed to be.
### Step 09 -- Client configuration ###
In Step 05 we created the directory ovpn-client inside our user’s home directory (/home/sub0, in our example). In there we have the CA certificate plus the client certificate and private key. There’s only one file missing and that’s the configuration file for the client. A sample file we can use is inside /usr/share/doc/openvpn/examples/sample-config-files:
We open up client.conf for editing and immediately locate the following line:
remote my-server-1 1194
This “my-server-1″ string is a placeholder and we are now going to replace it for our server’s public domain name or public IP. If we do have a public domain name already assigned to the server, then there’s nothing more to do than put it in place of my-server-1. Things get a tiny bit more involved if there’s no public domain name for our server. What’s the public IP for it? One way to find out is by typing the following:
(If instead of a numeric IP address you get an error, just wait a few seconds and try again.) So now we know our server’s public IP, but is it static or dynamic? Well, if we’re dealing with a server at home or even at the office, chances are it has a dynamic IP address. In that case it is advisable to use a free dynamic DNS service, such as the one provided by http://www.noip.com. In the case of NoIP, assuming we have chosen the free domain dnsalias.net then we may end up with a line like this
remote ovpn.dnsalias.net 1194
where “ovpn” is the hostname we’ve given to the server. On the other hand, if our server is hosted in the cloud then it probably has a static public IP address. In that case, the remote directive inside client.conf will look like the following:
remote 1.2.3.4 1194
There are two more lines we need to modify:
cert client.crt
key client.key
In our case, the certificate and private key files for the client are named laptop.crt and laptop.key respectively, so our client.conf contains these two lines:
cert laptop.crt
key laptop.key
After making sure the changes to client.conf are saved, we need to securely transfer the whole ovpn-client directory to the client. One way to do so is by using the scp command (secure copy or copy over SSH). An alternative is provided by the excellent and free FileZilla, which supports FTP over SSH connections (SFTP).
So how do we actually connect to the remote OpenVPN server? It all depends on the type of the device we have in hand and of course on the operating system is runs. In a bit we are going to examine the cases of four different OS families — or OS categories, if you will: Linux, Windows, OS X and iOS/Android. Note though that no matter the device or the OS, for the connection to be successful we need to be outside of the OpenVPN server’s local network. In addition, if there’s a firewall in front of the server –and it probably is– then we ought to put a new rule in place which essentially states something like this:
*Redirect all incoming UDP packets for port 1194 to port 1194/UDP of the server’s public-facing network interface.*
That’s some simple firewall rule, don’t you think? And without further ado, let’s establish our first connection to the fabulous OpenVPN server of ours.
**Linux**. All we need is the openvpn package installed. One way to connect to the remote OpenVPN server is to fire up a terminal, change to the ovpn-client directory and from the root user account –or with the assistance of sudo– type something like this:
/usr/sbin/openvpn --config client.conf
Anytime we want to terminate the connection we just hit [CTRL+C].
**Windows**. A free OpenVPN client is the so called [OpenVPN Desktop Client][3]. The configuration file client.conf must be renamed to client.ovpn and that’s the file we should give to the OpenVPN Desktop Client. The application will read client.ovpn and create a new connection profile for the OpenVPN server.
**OS X**. A free OpenVPN client for OS X is [tunnelblick][4]. There is also [Viscosity][5] which is commercial and happens to be our favorite. Viscosity will read client.conf and create a new connection profile for the remote server.
iOS/Android. An excellent choice is OpenVPN connect. It is free of charge and available from the [App Store][6] as well as the Google [Play store][7].
Regardless of the computing platform, sometimes we’d like to check if we’re actually using the OpenVPN server we think we’re using. One way to do that is by following this simple 4-step procedure:
Prior to connecting to the OpenVPN server we…
- visit a site such as [whatip.com][8] and take note of our public IP
- visit [dnsleaktest.com][10, perform the standard test, take note of the name servers we’re using
After connecting to the OpenVPN server we repeat the above two steps. If we get two different public IPs, this means we do go out on the net through the remote OpenVPN server. In addition, if we get two different sets of name servers, then there are no DNS leaks.
### Final thoughts ###
I use three different OpenVPN servers, all custom-made. One of them runs on the pfSense router at my home office in Thessaloniki, Greece. I use this server when I’m out of office and want secure access to the home LAN. The other two OpenVPN servers are hosted on two different VPSes, one in Reykjavik, Iceland, and the other in New Jersey, USA. Whenever I’m out and about and feel like using a random WiFi hotspot, I don’t even have to think of the security implications: I simply connect to the Reykjavik server and start surfing the web normally. There are also some times when I want to casually check out a service which is geographically restricted to the US. In these not-so-common cases the New Jersey server comes in handy, for when I connect to it I get a public IP from the U, S of A and hence access to that otherwise restricted service. It is worth noting that some service providers maintain blacklists with numerous well-known VPN companies. And that’s *exactly* one of the advantages of setting up your own OpenVPN server on a VPS provider of your choosing: It’s unlikely that this provider is blacklisted.
No matter where the physical location of your server is, OpenVPN ensures that the traffic flow between the client and the server is strongly encrypted. What happens to the traffic leaving the OpenVPN server is another story. Depending on the application-layer protocol it may still be encrypted, but it could be unencrypted as well. So unless you have absolute control of the OpenVPN server and of the local network it belongs to, you cannot fully trust the administrator at the other end. The moral of this is apparent: If you really care about your privacy, then you should keep in mind that your own behavior may indeed undermine it.
One example will hopefully get the point across. You have a well configured OpenVPN server in the cloud. You use any random WiFi hotspot anytime you feel like it and without the slightest bit of worry, thanks to that heroic OpenVPN server. Then you fire up your favorite mail client to get your email from this good, old mail server which still uses plain SMTP. Guess what? Your username and password leave the OpenVPN server in plain text, i.e. unencrypted. At the same time a bored administrator in the vicinity of the OpenVPN server could be easily sniffing-out your credentials and storing them in their ever-growing list named “random happy people.txt”.
So what do you do? Simple. You continue using your OpenVPN server, but refrain from using applications which talk old and/or insecure protocols.
