Setting up DoubleVPN based on OpenVPN on your own VPS.

Nowadays, it is often necessary to hide your real IP in order not to be repressed by the authorities for likes on social networks and expressing your own opinion that does not coincide with the official one. In addition, thousands of websites are blocked today for various reasons, both political and for no particular reason. To have access to censored sites, VPNs are also often used.

Here we will not discuss the legality of blocking circumvention, but if blocking prevents the normal operation of the Internet, then every user, after all, has the right to free access to information. We are not encouraging the user to do anything here. All information is given here for educational purposes, and is not a call to commit illegal actions (so to speak, a disclaimer).

A VPN as such encrypts the traffic between the user and the VPN server. This allows you to ensure that the provider will not try to interfere with user traffic and block anything (for example, through deep packet inspection systems, DPI). In addition, sites will see the IP of their VPN instead of the user's native IP. Even more secure is the integration of multiple VPNs into a chain. Your PROVIDER will see you connecting to the input VPN, and sites on the Internet will see you exiting from the IP of the output VPN. Therefore, it will be more difficult to link site data and provider data. That is, it gives you more anonymity and privacy.

I do not recommend using free public VPN providers, as well as paid ones. These providers often promise not to keep logs, not to collect information about the user, but in fact many of them do not fulfill their promises. Moreover, there have already been several precedents of "draining" databases with user logs, i.e., confidential data has been made publicly available. Therefore, for those who really care about their privacy and confidentiality, I recommend setting up a VPN yourself, or, at least, order a setup from a freelancer, on the same kwork.ru .

Here we will look at setting up a dual VPN by a user on their own VPS/VDS. VPS/VDS is a virtual machine that is completely at the user's disposal. To set up a VPN, and we will consider setting up a VPN based on OpenVPN, almost any VPS with minimal characteristics (512 MB — 1 GB of memory and 5 GB of disk) running Linux is suitable. The only thing worth considering is that this VPS allows you to configure the tun interface. Tun is a Linux kernel driver that is used to address the ends of a tunnel between two machines — the client and the server. Often, on very cheap VPS based on OpenVZ containers, the option to activate the tun module is not available. On some OpenVZ-based VPS hosting sites, there is a special check mark in the control panel to download the tun module. But this is not the case everywhere. Therefore, it is better to take a VPS based on full-fledged virtualization, such as QEMU/kvm, or VMware or Xen. And it is better to bypass OpenVZ, or, at least, check whether there is an option to download the tun module or not.

You should also choose a VPS hosting location so that there are no locks. For example, in the EU or the USA/Canada. If we want sites to see us in a certain country (i.e., our visible IP was in that country), and we should choose a VPS on a hosting that has this country in the list of locations. For dual VPNs, for example, you can have an input VPS in Europe and an output one in the USA. In other words, you will need two separate VPS located in two different locations. We will combine them into a chain. That is, the first VPS connects to the second via a VPN. Similarly, you can make chains of three or more VPS.

By default, OpenVPN uses tcp/udp ports 1194 to forward its traffic, but these ports may be blocked by providers. Therefore, we recommend using port 443/tcp or 53/udp. These ports are usually always open. 443/tcp is used for secure web traffic (https), and 53/udp is the DNS port. Https traffic is always encrypted, so if you hang OpenVPN on this port, it will be difficult to distinguish it from regular https traffic.

For convenience, I recommend installing the following programs on each of the VPS:

apt install mc nano screen net-tools

Here mc is Midnight Commander — a convenient two-panel file manager for the Unix/Linux console. Nano is a user—friendly editor for text files, providing a user-friendly interface. Screen is a terminal multiplexer program. It allows you to run a set of programs on several screens, switch between them and restore a session after a connection is lost. A very convenient thing, I recommend it. Net-tools is a package with the commands netstat, ifconfig, telnet, etc., very useful for diagnosing problems. For some reason, it has not been included in the default set of installed programs lately, and it must be installed separately. There are helpers for these programs on the Internet, so we will not dwell on them in detail.

Let's assume that we have two servers with IP 1.1.1.1 and IP 2.2.2.2. The first server is the input, the second is the output. In this article, we will use a VPS running Debian. Let's assume that the Debian version is 9 (stretch) or 10 (buster). First, we go to the first server and execute the commands:

apt update
apt upgrade
cd /root

— Here we have updated the package cache and updated the system from the repository. Now our system has been updated to the latest version. We will use the script for convenience openvpn-install.sh . The following command will download the script from his website and run it on our machine:

wget https://git.io/vpn -O openvpn-install.sh && bash openvpn-install.sh

— We answer all questions in the affirmative and select "client" as the name of the client being created. The necessary keys and certificates will be created and OpenVPN will be installed. Next, open the main server config in our favorite editor:

nano /etc/openvpn/server.conf

Delete all the lines (Ctrl-k) and paste this:

port 443
proto tcp
dev tun
tls-server
server 192.168.100.0 255.255.255.0
keepalive 10 120
persist-key
persist-tun
# status openvpn-status.log
push redirect-gateway
push "route 192.168.100.0 255.255.255.0"
duplicate-cn
#comp-lzo
mssfix 0
auth-nocache
auth SHA512
cipher AES-256-CBC

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0

max-clients 50

verb 0
log /dev/null
status /dev/null
log-append /dev/null

Save (Ctrl-x), click "Y" and agree with the default file name. Rename the tc.key file to ta.key. Also, open the /root/client.ovpn file and change <tls-crypt> and </tls-crypt> to <tls-auth> and </tls-auth> in it. Here we use the tls-auth option in the configs instead of tls-crypt, because there were problems with the openvpn Windows client with the latter (it refused to import the configuration file with the latter option). Therefore, we decided to use the more compatible tls-auth option. After that, we nail OpenVPN with the kill command and run it again:

# ps ax | grep vpn
15696 pts/4    S      1:09 openvpn --config server.ovpn

kill 15696
# ps ax | grep vpn
5625 pts/12   S+     0:00 grep vpn

cd /etc/openvpn/server
nohup openvpn --config server.conf &
# ps ax | grep vpn
15697 pts/4    S      1:09 openvpn --config server.ovpn

Our server has restarted. Now let's move on to the 2nd server. As in the first one, we execute the commands:

apt update
apt upgrade
cd /root
wget https://git.io/vpn -O openvpn-install.sh && bash openvpn-install.sh

— We updated the system from the repository and installed openvpn using a script openvpn-install.sh . Also, we answer in the affirmative everywhere and select "client" as the client's name. Editing the config:

nano /etc/openvpn/server.conf

We delete all the lines and insert this piece:

port 53
proto udp
dev tun
tls-server
server 192.168.101.0 255.255.255.0
keepalive 10 120
persist-key
persist-tun
# status openvpn-status.log
push "route 192.168.101.0 255.255.255.0"
duplicate-cn
comp-lzo yes
mssfix 0
auth SHA512
cipher AES-256-CBC

ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0

verb 0
log /dev/null
status /dev/null
log-append /dev/null

Restarting the server (exactly as we did on the first server). Now look at the /root/client.ovpn file. It should start like this:

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 178.33.86.165 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
mssfix 0
auth-nocache
verb 3
<ca>
-----BEGIN CERTIFICATE-----
MIIDKzCCAhOgAwIBAgIJAI9xq8rqEEWfMA0GCSqGSIb3DQEBCwUAMBMxETAPBgNV
...

Now we delete all the lines up to <ca> and insert them instead:

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 2.2.2.2 53
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
#comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3
comp-lzo yes
auth-nocache
mssfix 0
script-security 2
#script-security 2 system
up /etc/openvpn/route_rules.sh

Here, instead of 2.2.2.2, there should be the IP of the 2nd server. Save and exit. Copy the client.ovpn file from the 2nd server to the 1st under the name /etc/openvpn/to_another_server.conf. Create a file in the same place /etc/openvpn/route_rules.sh:

nano /etc/openvpn/route_rules.sh

and insert the script:

#! /bin/sh
#

echo '150 vpn.out' >> /etc/iproute2/rt_tables
ip rule add from 192.168.100.0/24 table vpn.out
ip route add default dev tun1 table vpn.out
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o tun1 -j MASQUERADE

The script adds routing and firewall rules (masquerading) when raising the link. This is necessary so that VPN users hide behind the IP of the 1st server (this is masquerading). Next, we make the script executable:

chmod 777 route_rules.sh

We start on Mon from the 1st server to the 2nd:

nohup openvpn --config /etc/openvpn/to_another_server.ovpn &

We check with the ifconfig command, it should show two interfaces tun0 and tun1. This means that both VPNs have risen. Also, to automatically raise the VPN to the second server after reboot, go to /etc/default/openvpn and write the line:

AUTOSTART="to_another_server"

Now we are editing the client config on the 1st machine:

nano /root/client.ovpn

— here we also delete the lines before the <ca> line and insert the following instead:

client
dev tun
proto tcp
sndbuf 0
rcvbuf 0
remote 1.1.1.1 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
#comp-lzo
# --- windows ---
setenv opt block-outside-dns
ignore-unknown-option block-outside-dns
block-outside-dns
# --- windows ---
# --- linux ---
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
# --- linux ---
key-direction 1
verb 3

Replace 1.1.1.1 with the IP of the 1st server in the above config. The resulting client config can be copied to your local machine. Lines marked as "— windows —" are suitable for clients running Windows and macOS. Lines marked as "— linux —" are suitable for Linux (Unix). If you have windows, then it is better to comment out the lines needed for Linux, and vice versa. These lines are necessary to raise DNS through the tunnel (so that there is no "DNS leak" and the DNS provider is not used). Now you should switch back to the 2nd machine and configure the firewall rules:

apt install iptables-persistent

We agree to save the firewall settings in the files /etc/iptables/rules.v4 (IPv4) and /etc/iptables/rules.v6 (IPv6). Here we will leave the configuration for IPv6 outside the scope of our article. Let's open the file for IPv4:

nano /etc/iptables/rules.v4

Delete all the lines and insert the next piece:

# Generated by iptables-save v1.6.0 on Thu Oct 17 21:23:19 2019
*filter
:INPUT ACCEPT [560:118664]
:FORWARD ACCEPT [30:1800]
:OUTPUT ACCEPT [548:110691]
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.101.0/24 -j ACCEPT
COMMIT
# Completed on Thu Oct 17 21:23:19 2019
# Generated by iptables-save v1.6.0 on Thu Oct 17 21:23:19 2019
*nat
:PREROUTING ACCEPT [49511:4242962]
:INPUT ACCEPT [10052:625143]
:OUTPUT ACCEPT [33:2315]
:POSTROUTING ACCEPT [33:2315]
-A POSTROUTING -s 192.168.101.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Oct 17 21:23:19 2019

It should be noted here the rules for masquerading and for prohibiting ping (ICMP type 8 — echo reply). Using the masquerading rule, the 1st machine hides behind the IP of the 2nd machine. It is advisable to prohibit ping so that sites like Google cannot determine the presence of a tunnel by the difference in delays when pinging from the user's browser and from the site to the user's external IP. This is also called "two-way ping".

Now let's go here:

cd /etc/network/if-pre-up.d
nano iptables

And we insert this script:

#! /bin/sh
#

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables-restore </etc/iptables/rules.v4
exit 0

Now we make this file executable:

chmod 777 iptables

This file writes "1" to the service file /proc/sys/net/ipv4/ip_forward, which includes IP forwarding, in other words, packet routing between the network interfaces of the machine, for example, tunX and ethX. Next, using the iptables-restore command, firewall rules are restored from the /etc/iptables/rules file.v4. This script will be executed before raising the eth0 network interface.

Note: in some VPS, the main network interface may not be called eth0, but, for example, ens3. What it is actually called is easy to determine with the ifconfig command (when running without parameters, it outputs a complete list of interfaces). If this is your case, then you need to correct the /etc/iptables/rules.v4 file (replace eth0 with your interface name).

Now we are trying to connect the openvpn client to the server. When it's ready, we check if there is a ping. If there is no ping, then there is an error somewhere. A common mistake happens when you forget to turn on masquerading on the 2nd car. It also happens that they forgot to turn on compression on one side of the tunnel, and turned it on on the other. Accordingly, the link does not rise. In this case, it may be useful to enable logs on the client and/or server side and see more details. A useful diagnostic method can still be the command:

# traceroute 192.168.101.1
traceroute to 192.168.101.1 (192.168.101.1), 30 hops max, 60 byte packets
 1  192.168.100.1 (192.168.100.1)  37.444 ms  112.117 ms  112.081 ms
 2  192.168.101.1 (192.168.101.1)  227.136 ms  291.842 ms  291.819 ms

Here we trace packets along a chain of two tunnels (the first connects the client and the 1st VPS, and the second the 1st VPS with the 2nd). It can be seen from the trace above that the trace has reached the 2nd VPS (IP 192.168.101.1). If the trace is interrupted on the 1st VPS (IP 192,168.100.1), it will mean that there are problems with communication between the 1st and 2nd VPS. This way you can determine at what stage the plug is.

You should also notice the "mssfix 0" option in the configs of all VPNs. This option removes the "VPN fingerprint" ("fingerprint", which is the MTU of the VPN channel). MTU is the maximum packet size that can pass through a communication channel without fragmentation. Ethernet mtu is usually equal to 1500 bytes. Since VPN packets are encapsulated in packets of the same ethernet, VPN mtu is usually less. And by mtu, you can indirectly determine the tunnel. I.e., the mtu serves as a "fingerprint" by which you can determine the VPN. So, the mssfix option changes the channel MTU. When setting "mssfix 0", the maximum size is selected for the MTU. Thus, it becomes impossible to identify a tunnel by its mtu.

If there is a ping, then the next step will be to check anonymity on sites like whoer.net or 2ip.ru/privacy /. These sites should show possible errors that need to be fixed. For example, the presence of a VPN fingerprint, two-way ping, DNS leaks and other problems.