Bypassing Blocks with Double…

Preface

The article will consider three independent options for passing traffic in transit using:

1. Double openVPN

2. openVPN + vtun

3. openVPN + tun2proxy via socks5 proxy

My provider blocked my openvpn. First a regular provider, and then a mobile one too. It was a regular vds server abroad with openvpn. Used exclusively for personal purposes. After blocking, I just decided to check if doublevpn would work, since I also had a server in Russia. It turned out that everything works fine with double. The essence of this technology is that Internet traffic passes through two servers instead of one. This well-forgotten tool will be discussed in the article, perhaps it will be useful to someone. Just in case, I also considered options for tunneling traffic using vtun or socks5 proxy in the article.

Option I. DoubleVPN

Of course, the first thing that came to mind was to simply connect two servers in Russia and in another country using openvpn. And it worked without problems. Here is my solution:

Step One: Install openVPN on Both Servers

Everything I write is suitable one way or another for any *nix servers, be it ubuntu, centos, fedora, rocky, etc.

You can install openvpn using a ready-made script, for example, like this:

https://github.com/Nyr/openvpn-install

Once you have run the script on both servers, you can move on to the settings for each of them.

Step two. Setting up on a foreign VDS

On the server in country X the setup is very simple. After you have run the above script and openvpn is installed, all you need to do is edit the configuration file, replace it with the following content.

port XXXX # Порт на котором у вас работает openvpn
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt tc.key
remote-cert-tls client
server 10.100.39.0 255.255.255.0
keepalive 10 120
persist-key
persist-tun
verb 3
sndbuf 0
rcvbuf 0
push "route 10.100.39.0 255.255.255.0"

Next, restart the openvpn server:

systemctl restart openvpn-server@server.service

And copy the client key that was generated when installation to a Russian VDS. For example, using scp.

That's all. The foreign server setup is complete.

Step three. Setting up Russian VDS.

On the Russian vds after installing openvpn from the script, the vpn server (10.8.0.0/24) is already running. We will not touch it. All we need to do is to launch a foreign open-vpn client on the Russian vds.

Editing /etc/sysctl.conf

We insert the following lines:

net.ipv4.ip_forward=1
net.ipv4.conf.tun0.rp_filter=0
net.ipv4.conf.tun1.rp_filter=0

Lines net.ipv4.conf.tun0.rp_filter=0 And net.ipv4.conf.tun1.rp_filter=0 disable reverse path filtering check for tun0 and tun1 interfaces respectively. You can reboot the server or enter the appropriate commands.

Editing the file:

/etc/iproute2/rt_tables

And add the line to it:

150     vpn_net

Now we need to create two scripts that will be executed when the foreign openvpn client starts and when it stops.

/etc/openvpn/server1_up.sh

/sbin/ip rule add from 10.8.0.0/24 table vpn_net
/sbin/ip route add default dev tun1 table vpn_net

/etc/openvpn/server1_down.sh

/sbin/ip rule del from 10.8.0.0/24 table vpn_net
/sbin/ip route del default dev tun1 table vpn_net

We hang it on both scripts

chmod +x /etc/openvpn/server1_up.sh And chmod +x /etc/openvpn/server1_down.sh

Now we need to take the client config that we took from the foreign server. Change its extension: instead of .ovpn write .conf

mv my_client.ovpn my_client.conf

Put in folder: /etc/openvpn/client and edit it something like this:

client
dev tun
proto udp
remote XX.XX.XX.XX YY YY # IP и порт зарубежного VDS
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
verb 3
script-security 2
up "/etc/openvpn/server1_up.sh"
down /etc/openvpn/server1_down.sh

# До этого место. Дальше не трогаем.
<ca>
-----BEGIN CERTIFICATE-----
wIBAgIJAL0WnyzV8N87MA0
......

We specify that our scripts will be launched when the client is started and stopped.

Launch the openvpn client

systemctl start openvpn-client@my_client

Adding a new iptables rule

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE

And the old nat rule that the installer added Nyr/openvpn-installdelete. Save iptables in the way that is in your *nix, so that they work after loading. And make autostart of our client:

systemctl enable openvpn-client@my_client

We check that everything works using commands

ip route show table all|grep vpn_net
ip rule list| grep vpn_net
ip address

By using openvpn install we create the required number of openvpn keys.

Option II. OpenVPN + Vtun

In the first option we had openvpn + openvpn, but nothing prevents us from connecting, for example, a Russian VDS and a foreign one using the old and good vtun. And tunnel traffic in the same way

Step one. Install vtun on both servers

Vtun can be compiled from sources. Let's assume that you have installed vtun and openvpn on both servers. Packet forwarding is enabled, see the settings for option #1.

Step two. Launching vtun server on a foreign server

For the server, you can take approximately this config and put it in a file /etc/vtund.conf:

options {
   port 5000;
   ifconfig   /sbin/ifconfig;
}

# Default session options
default {
   proto tcp;     # TCP protocol
   compress no;   # Compression is off
   encrypt no;    # ssh does the encryption
   speed 0;       # By default maximum speed
   keepalive yes;
   stat yes;
}

my_tunnel {
   passwd MY_STRONG_PASS;    # Password
   type  tun;                # IP tunnel
   proto tcp;                # TCP protocol
   up {
      ifconfig "%% 10.3.0.2 pointopoint 10.3.0.1 mtu 1500";
   };
   down{
      ifconfig "%% down";
   };
}

Open port 5000 and add SNAT rules, where to-source XX.XX.XX.XX This is a white IP in country X.

-A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT
-A POSTROUTING -s 10.3.0.0/24 -j SNAT --to-source XX.XX.XX.XX

Let's launch:

vtund -s

We check, the tun and ip interface should appear.

ip address

Step three. Launching vtun client and openvpn in Russia

We install OpenVPN as usual, see option 1.

And here are the vtun settings on the Russian server

options {
   port 5000;

   # Path to various programs
   ifconfig   /sbin/ifconfig;
   ip  /sbin/ip;
}

# Default session options
default {
   compress no; 
   encrypt no; 
   speed 0; 
   keepalive yes;
   stat yes;
}


my_tunnel {
   passwd  PASS;      # Password
   type  tun;         # IP tunnel
   proto udp;         # TCP protocol

   up {
      # 10.3.0.1 локальный ip 
      # 10.3.0.2 удаленный ip
      ifconfig "%% 10.3.0.1 pointopoint 10.3.0.2 mtu 1500";
      ip "rule add from 10.8.0.0/24 table vpn_net";
      ip "route add default dev %% table vpn_net";

       

   };
   down{
      ip "rule del from 10.8.0.0/24 table vpn_net";
      ip "route del default dev %% table vpn_net"; 
      ifconfig "%% down";
   };
}

Run the command:

vtund  my_tunnel ip_адрес_вашего_зарубежного_сервера

Just like with openvpn we masquerade traffic:

iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE

After that everything should work. If it doesn't work, make sure that pings are between 10.3.0.1 and 10.3.0.2 and look at the logs.

The vtun configuration is given as an example. There, if desired, you can also transmit traffic via udp, encrypt, compress, etc.

Option III. OpenVPN + tun2proxy

In the third option, we will throw openvpn traffic into socks5 and also release it outside. Although with the help of tun2proxy you can tunnel into an http proxy, so even a foreign VDS is not necessary, it is enough to have ssh access in country X or some http proxy.

https://github.com/tun2proxy/tun2proxy

Tun2proxy – is a tunnel interface for HTTP and SOCKS proxies on Linux, Android, macOS, iOS and Windows:

• HTTP proxy (no authentication, basic and digest authentication)

• SOCKS4 and SOCKS5 support (no authentication, username and password authentication)

• SOCKS4a and SOCKS5h support (via virtual DNS function)

• Minimal configuration setup to route all traffic

• IPv4 and IPv6 support

• GFW bypass mechanism for specific use cases

• SOCKS5 UDP support

• Built-in support for DNS proxying over TCP

Installation and configuration

All installation and configuration is done on a server in Russia. On the first server. On the second (foreign server) you only need an ssh account to create a socks5 proxy.

I put it rust latest version

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

And then I launched the installation

$HOME/.cargo/bin/cargo install tun2proxy

And it installed successfully, I checked that everything was ok:

$HOME/.cargo/bin/tun2proxy --help

I read the help on usage. Then I created a dynamic proxy for checking ssh socks5 tcp with the following command:

ssh -D 14017 -q -C -N my-socks5-user@my-remote-server.com

Hung it on port 14017. In a good way, it should have been udp socks5 to do (but we are not looking for easy ways), and it is more interesting for the test.

Then I launched tun2proxy with the command:

$HOME/.cargo/bin/tun2proxy --tun tun1 --proxy "SOCKS5://127.0.0.1:14017"

Then I raised the network interface, since it is disabled by default:

ifconfig tun1 up

This is the tun2roxy feature, that it creates a network interface. That is, if you type, for example, ifconfig, then with tun2roxy enabled you can see another “network card” that it created based on the proxy. And if there is tun1, then you can do whatever you want, almost the same as in the previous options.

I checked that everything works with this command:

curl --interface tun1 ifconfig.me

In response I received the IP address of my foreign server. Everything is OK, the traffic was wrapped in tun1 and came out from abroad.

Now we need to make openVPN do the same thing to release openVPN traffic through tun1 & socks5.

net.ipv4.ip_forward=1
net.ipv4.conf.tun0.rp_filter=0
net.ipv4.conf.tun1.rp_filter=0
net.ipv4.conf.all.route_localnet=1

To file:

/etc/iproute2/rt_tables

Added a line:

150     vpn_net

And entered the commands:

/sbin/ip rule add from 10.8.0.0/24 table vpn_net
/sbin/ip route add default dev tun1 table vpn_net

And then the joke is, if you just disguise the traffic with a command iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE then DNS requests will not work, because they do not go via TCP. As I wrote above, the usual socks5 tcp proxy doesn't really fit. So before I masqueraded, I had to put dnsproxy and run it with the command:

./dnsproxy -u 8.8.8.8:53

And this time tun2proxy itself was launched with the command specified above, but with an additional key --dns direct and also changed the client openvpn settings so that it would go to my server locally with DNS requests.

After that everything worked and openvpn The client came out through this tunnel.