Kosher tunnel organization in OpenWRT

So, we need to organize a tunnel between two linux-hosts, one of which is our soho router with this wonderful firmware on board. Immediately make a reservation that for us the most important thing is the connection speed and reduction of overhead costs. Therefore, we will forget about the installation of packets that implement authentication, encryption of traffic, but occupy a large number of cherished kilobytes in the memory of the router. We will consider only ipv4-tunnels. Standard kernel support:

• ipip - encapsulates only unicast IPv4 traffic
• gre - IPv4 / IPv6 unicast / multicast traffic, in one word - beauty!

The choice is yours, in addition to some natural overhead in the form of reducing speed and increasing the load on the system, your provider can serve as arguments in favor of one or another, he can simply block one of the protocols. As for the reduction in speed, I have such a sign iperf testing with standard settings, values ​​in megabits:

tunnel	the average	minimum	maximum
without tunnel	30.9	29.8	31.9
ipip	24.8	24.4	25.3
gre	24.0	22.3	24.9

System preparation

opkg update #    opkg install ip #    ,    iproute2 - "must have"-   linux- opkg install kmod-gre # gre-(№47,  ,        iptables) opkg install kmod-ipip # ipip-(№4) 

In OpenWRT, the network interface settings are described in the /etc/config/network file. I propose to adhere to the style characteristic of this system, we will set up the settings there, but what a bad luck - there is no standard possibility to describe the tunnel, with the same ease as it can be done for ifup. A manual comes to our rescue in which it is described in detail how to define a new protocol.

Interface Description

So, in the end, I have a description of our tunnel, in my case - gre:

 #      -  config 'interface' 'gretunnel' option 'proto' 'tunnel' #,        option 'tunnel_end' '1.2.3.4' #    option 'tunnel_start' '5.6.7.8' option 'remote_address' '192.168.0.1' #   - option 'local_address' '192.168.0.2' option 'mtu' '1476' option 'mode' 'gre' #gre/ipip #option 'gateway' '192.168.0.1' #        

Again in the standard way, in my case for the ubuntu server, we raise the second end of the tunnel:

 auto gretunnel iface gretunnel inet static address 192.168.0.1 netmask 255.255.255.255 #,     ,      ? pointopoint 192.168.0.2 mtu 1476 pre-up ip tunnel add gretunnel mode gre remote 5.6.7.8 local 1.2.3.4 post-down ip tunnel del gretunnel 

Define a new protocol

The guide describes four procedures that fully describe the life cycle of a network interface. Although they can be added to any of the files located in the /lib/network/ directory, I propose to create a separate tunnel.sh so that with a possible upgrade of the system or individual packages, the changes are preserved.

Scan

Protocols that create virtual interfaces (for example, PPP, 6in4, or our IP tunnel) must implement the scan procedure to synthesize the ifname attribute of our interface configuration required for the ifup/ifdown event handlers on the hotplug system. In fact, you can directly register in the configuration option ifname tunnel_name , but why?)

 scan_tunnel() { config_set "$1" ifname "$1" } 

That is, we simply give the interface the same name as the configuration name.

Coldplug

By default, only the interfaces present in /proc/net/dev/ rise when the system boots. It is here that we create our interface, almost completely configuring it - we do not specify only point-o-point addresses, since they will still be reset in the prepare_interface procedure defined in /lib/network/config.sh .

 coldplug_interface_tunnel() { local mtu, tunnel_start, tunnel_end, mode, ifname config_get mode "$1" mode ([[ "$mode" == "ipip" ]] && insmod ipip) || insmod ip_gre config_get mtu "$1" mtu config_get tunnel_end "$1" tunnel_end config_get tunnel_start "$1" tunnel_start config_get ifname "$1" ifname ip tunnel add "$ifname" mode "$mode" local "$tunnel_start" remote "$tunnel_end" } 

Setup

Here the interface rises and is configured to the end.

 setup_interface_tunnel() { local alocal, aremote, mtu, defroute config_get alocal "$2" local_address config_get aremote "$2" remote_address config_get mtu "$2" mtu ip link set dev "$1" up mtu "$mtu" ip address add dev "$1" "$alocal" peer "$aremote" config_get defroute "$2" gateway [[ -n "$defroute" ]] && ip route add default via "$aremote" dev "$1" env -i ACTION="ifup" INTERFACE="$2" DEVICE="$1" PROTO=tunnel /sbin/hotplug-call "iface" & } 

The last line launches a mechanism that sets an important attribute up in the boolean truth, which in turn allows you to work with the interface in a regular firewall, and you can also assign routes through this interface.

Stop

Omit the interface

 stop_interface_tunnel() { local ifname "$1" ifname ip link set dev "$ifname" down } 

Work with firewall

By default, the filter table is set to the default DROP policy, as well as on any normal linux system. We need to describe the work with walking traffic through the above gretunnel interface. To do this, create a zone in the /etc/config/firewall file:

 config 'zone' option 'name' 'gretunnel' option 'output' 'ACCEPT' option 'forward' 'ACCEPT' option 'mtu_fix' '1' option 'input' 'ACCEPT' 

Whose name coincides with the name of the interface, do not forget about mtu different from the standard 1500 bytes. I didn’t work through -j MASQUERADE (can someone tell me why?), So we’ll SNAT' packets, the faster it is. To do this, we describe the corresponding rule:

 config redirect option src lan option dest gretunnel option src_dip 192.168.0.2 option proto 'udp icmp tcp' option target SNAT 

You may have an obvious question - “why not put all in the proto option?” - unfortunately, I don’t have the answer, it doesn’t work with this option, although it seems that it should: (Finally, forward' allow forward' traffic from the local network to the second end of the tunnel.

 config 'forwarding' option 'src' 'lan' option 'dest' 'gretunnel' 

Routing or why all this was necessary

Let's start with the canonical case - the union of two geographically separated host / networks into one local network. I anticipate attacks by security-specialists, saying that the traffic is not protected, and I don’t care, I’m just interested in simplicity and speed, we’ll leave encryption for another topic. Writing something like this in /etc/config/network :

 config 'route' option 'interface' 'gretunnel' option 'target' '192.168.2.0' option 'netmask' '255.255.255.0' option 'gateway' '192.168.0.1' 

And at the second end, we perform similar manipulations, everything — networks / hosts are connected. Now let's consider the case that personally pushed me to reflash my dlink-320. My ISP doesn’t physically disconnect subscribers from the network — on the switch port — instead, it leaves full access to the local network, while restricting access to Internet resources and some internal ones. Well, let's proceed as follows - we will route all the “legal traffic” to the provider's gateway, and everything else to our tunnel. Local old-timers are advised to watch your provider 's network here . We start, in the /etc/config/network file we comment on the option indicating the default route assigned to the provider's gateway:

 config 'interface' 'wan' option 'ifname' 'eth0.1' option 'proto' 'static' option 'ipaddr' '5.6.7.8' option 'netmask' '255.255.255.252' # option 'gateway' '5.6.7.7' option 'defaultroute' '0' option 'peerdns' '0' option 'dns' '8.8.4.4' 

and uncomment the appropriate option in our tunnel description

 option 'gateway' '192.168.0.1' 

Not forgetting the "legal" traffic

 config 'route' option 'interface' 'wan' option 'target' '5.6.7.6' option 'netmask' '255.255.255.252' option 'gateway' '5.6.7.7' #   config 'route' option 'interface' 'wan' option 'target' '10.0.0.0' option 'netmask' '255.0.0.0' option 'gateway' '5.6.7.7' 

Everything, now we have a free Internet :) In fact, the “freebie” provided by my provider is not infinite, alas. After 45 days, the port is still blocked, but due to the fact that they are not customer-oriented, they also do the recalculation - I can only pay for half a month using their services. This is how I have, “free” 8-megabits) After reading this article, you may again have a question - “why should it be so, if the same could be done in 10th lines in any initscript? "- fortunately, I have an answer to this question, although it is arguably controversial - I believe that the system should be worked within the framework of the ideology adopted there, trying to do without hacks, kosherno, so to speak) Oh, yes, there is also" free " television, but this is a topic for another topic.