ProHoster > Blog > Administration > Speeding up OpenVPN on an Openwrt router. Alternative version without soldering iron and hardware extremism

Speeding up OpenVPN on an Openwrt router. Alternative version without soldering iron and hardware extremism

Speeding up OpenVPN on an Openwrt router. Alternative version without soldering iron and hardware extremism

Hello everyone, I recently read old article about how you can speed up OpenVPN on a router by transferring encryption to a separate piece of hardware, which is soldered inside the router itself. I have a similar case with the author - TP-Link WDR3500 with 128 megabytes of RAM and a poor processor, which does not cope with tunnel encryption at all. However, I categorically did not want to climb into the router with a soldering iron. Under the cut, my experience of moving OpenVPN to a separate piece of hardware with a backup on the router in case of an accident.

Task

There is a TP-Link WDR3500 router and Orange Pi Zero H2. We want Orange Pi to encrypt tunnels in the normal mode, and if something happens to it, VPN processing will return back to the router. All firewall settings on the router should work as before. And in general, in general, the addition of an additional piece of iron should be transparent and imperceptible to everyone. OpenVPN works over TCP, TAP adapter in bridge mode (server-bridge).

Solution

Instead of connecting via USB, I decided to spend one port of the router and connect all subnets that have a VPN bridge to Orange Pi. It turns out that the piece of iron will physically hang in the same networks as the VPN server on the router. After that, we raise exactly the same servers on the Orange Pi, and on the router we set up some kind of proxy so that it sends all incoming connections to the external server, and if the Orange Pi is dead or unavailable, then to the internal fallback server. I took HAProxy.

It turns out like this:

  1. client arrives
  2. If the external server is not available - as before, the connection goes to the internal server
  3. If available, the client is accepted by Orange Pi
  4. VPN on Orange Pi decrypts packets and spits them back to the router
  5. Router routes them somewhere

Implementation example

So, let's say we have two networks on the router - main(1) and guest(2), for each of them there is an OpenVPN server for connecting from the outside.

Network configuration

We need to pass both networks through one port, so we create 2 VLANs.

On the router, in the Network / Switch section, create VLANs (for example, 1 and 2) and turn them on in tagged mode on the desired port, add the newly created eth0.1 and eth0.2 to the appropriate networks (for example, add to brigde).

On Orange Pi we create two VLAN interfaces (I have Archlinux ARM + netctl):

/etc/netctl/vlan-main

Description='Main VLAN on eth0'
Interface=vlan-main
Connection=vlan
BindsToInterfaces=eth0
VLANID=1
IP=no

/etc/netctl/vlan-guest

Description='Guest VLAN on eth0'
Interface=vlan-guest
Connection=vlan
BindsToInterfaces=eth0
VLANID=2
IP=no

And immediately create two bridges for them:

/etc/netctl/br-main

Description="Main Bridge connection"
Interface=br-main
Connection=bridge
BindsToInterfaces=(vlan-main)
IP=dhcp

/etc/netctl/br-guest

Description="Guest Bridge connection"
Interface=br-guest
Connection=bridge
BindsToInterfaces=(vlan-guest)
IP=dhcp

Enable autostart for all 4 profiles (netctl enable). Now, after rebooting, Orange Pi will hang in the two required networks. Interface addresses on Orange Pi are configured in Static Leases on the router.

show ip addr

4: vlan-main@eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-main state UP group default qlen 1000
    link/ether 02:42:f0:f8:23:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:f0ff:fef8:23c8/64 scope link 
       valid_lft forever preferred_lft forever

5: vlan-guest@eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP group default qlen 1000
    link/ether 02:42:f0:f8:23:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:f0ff:fef8:23c8/64 scope link 
       valid_lft forever preferred_lft forever

6: br-main: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:c7:0f:89:71:6e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute br-main
       valid_lft 29379sec preferred_lft 21439sec
    inet6 fe80::50c7:fff:fe89:716e/64 scope link 
       valid_lft forever preferred_lft forever

7: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ee:ea:19:31:34:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.3/24 brd 192.168.2.255 scope global br-guest
       valid_lft forever preferred_lft forever
    inet6 fe80::ecea:19ff:fe31:3432/64 scope link 
       valid_lft forever preferred_lft forever

VPN setup

Next, copy the settings for OpenVPN and keys from the router. The settings can usually be taken from /tmp/etc/openvpn*.conf

By default, openvpn running in TAP mode and server-bridge keeps its interface inactive. To make it work, you need to add a script that runs when the connection is activated.

/etc/openvpn/main.conf

dev vpn-main
dev-type tap

client-to-client
persist-key
persist-tun
ca /etc/openvpn/main/ca.crt
cert /etc/openvpn/main/main.crt
cipher AES-256-CBC
comp-lzo yes
dh /etc/openvpn/main/dh2048.pem
ifconfig-pool-persist /etc/openvpn/ipp_main.txt
keepalive 10 60
key /etc/openvpn/main/main.key
port 443
proto tcp
push "redirect-gateway"
push "dhcp-option DNS 192.168.1.1"
server-bridge 192.168.1.3 255.255.255.0 192.168.1.200 192.168.1.229
status /tmp/openvpn.main.status
verb 3

setenv profile_name main
script-security 2
up /etc/openvpn/vpn-up.sh

/etc/openvpn/vpn-up.sh

#!/bin/sh

ifconfig vpn-${profile_name} up
brctl addif br-${profile_name} vpn-${profile_name}

As a result, as soon as a connection occurs, the vpn-main interface will be added to br-main. For the guest grid, it is similar up to the interface name and address in the server-bridge.

External request routing and proxying

At this step, Orange Pi is already able to accept connections and let clients into the desired networks. It remains to configure proxying of incoming connections on the router.

We transfer router VPN servers to other ports, install HAProxy on the router and configure:

/etc/haproxy.cfg

global
        maxconn 256
        uid 0
        gid 0
        daemon

defaults
        retries 1
        contimeout 1000
        option splice-auto

listen guest_vpn
        bind :444
        mode tcp
        server 0-orange 192.168.2.3:444 check
        server 1-local  127.0.0.1:4444 check backup

listen main_vpn
        bind :443
        mode tcp
        server 0-orange 192.168.1.3:443 check
        server 1-local  127.0.0.1:4443 check backup

Enjoy

If everything went according to plan, clients will go to Orange Pi and the router processor will no longer heat up, and the VPN speed will increase significantly. At the same time, all network rules that are registered on the router will remain relevant. In the event of an accident on the Orange Pi, it will fall off and HAProxy will wrap clients on local servers.

Thank you for your attention, suggestions and corrections are welcome.

Source: habr.com

Add a comment