How to use WireGuard to build asymmetric routes

On October 15, 2022October 15, 2022

This article is transferred from the blog, original: https://aoyouer.com/posts/wireguard-asymmetric-routing/, copyright belongs to the original author.

Scheme 2 personally feels that it is a better configuration scheme, and the wireguard configuration method is also used in Scheme 1, and the steps are more concise and clear. Therefore, it is recommended that students who do not have the patience to read it directly see the second plan.

Strange environment creates strange demand – now there is a machine only mobile direct connection to the outbound journey, telecom and Unicom will go around the sun ntt(tnt), once at night will produce violent jitter and serious packet loss, so is there a way to optimize it? Using a mobile network machine as a transit is one way, but in this case, all traffic will pass through the transit machine, the speed of this machine becomes the bottleneck in the network, and the traffic will be doubled. Since we are only going to the outbound detour, is there a way to optimize only the outbound route and keep the original return route? In the actual Internet, “asymmetric routing” is very common, that is, A to B and B to A take different paths, and to achieve this effect, we need to build a virtual network first, and then configure routes in this network, I used wireguard here as a tool to build a virtual intranet.

Three machines were used in this experiment:

The effect that needs to be achieved is that A accesses the C path as A->B->C->A

After installing wireguard, you need to generate a key and turn on packet forwarding:

The following is directly pasted with the wireguard configuration of the three machines, noting that you need to set Table=off, that is, it is forbidden for wireguard to directly modify the routing table, and the connection established by the link-local address is used here. In addition, the three machines should be connected to each other in pairs (corresponding to a single configuration file), that is, they need to write 6 configuration files themselves

Node A and Node B configuration files:

Node A and Node C configuration files:

Node B and Node A configuration files :

Node B and Node C configuration files:

Node C and Node A configuration files:

Node C and Node B configuration files:

After establishing a connection between the two, we also need to create a dummy network card (which can also be written to postup) on each machine to get the packages sent to ourselves.

Taking machine A as an example, the same operation should be performed on BC (remember to change ip)

At this point 192.168.50.5(A) to 192.168.50.2(C) is not yet routed, but we want to go through node B, so we set up a static route on A:

Then you also need to set up a static route to C on node B:

At this point, pingC on A and grasping packets on B, we can get the following results:

Only one-way traffic can be seen on B, and A can get a response, and then grab the packet on C to see:

Look at the interfaces of the two interfaces B-C and C-A separately

It can be found that in fact, when B is forwarded as a route, it doesn’t matter what the source ip is, only the destination ip needs to be used, and the routing mode of the destination ip is specified through a static route, then on C it will receive a packet from A’s link-local address (169.254.1.5), and C is directly connected to A, and wireguard creates a connection to 169.254.1.5, so C’s response can go directly to A without going through B. This results in an asymmetric route. Under the current setup, A will go through B when actively accessing C, and C cannot actively connect to A, because there is no static route from C to A has not been set, we can repeat the previous steps, specify the static route to A on C and B, or directly let C access A without going through A. However, since I only need A to be able to actively access C in this requirement, I will no longer make these settings.

Why is an address that starts with 169 used in the configuration file instead of establishing a connection directly with an address that starts with 192 and participating in subsequent routing setup? Because (at least in my configuration), ip addr add xxx peer xxx establishes a point-to-point connection, automatically adding a routing rule that conflicts with the manual routes we add later. So I can only take a step back, use another address to establish a point-to-point connection, and then set up a static route with the new address. wireguard works at the network layer, probably does not support not setting the ip directly through the mac to connect ?

The previous section realizes the asymmetric routing of the network composed of three machines, so can we go a step further and realize the asymmetric route of two machines with the help of the existing “traffic forwarding” service? In this way, we no longer need a third server to forward the outbound journey, and high-quality lines are also common in the traffic forwarding service, and because only the outbound forwarding is gone, it actually does not cost much money.

Tested individually, this scheme is also easy to implement. Taking local machine A and remote machine C as an example, two wireguard interfaces must be set up on each machine, corresponding to the wireguard established by port forwarding and the wireguard established by direct connection.

The names are as follows:

The configuration file is as follows, note that there is no command to add peer with ip addr, but it is implemented entirely by static routes, and the dummy device is no longer required, but the IP that needs to be used later is used directly. Yes, it is not written wrong, in fact, it is not stipulated that an ip can only be assigned to one interface, just need us to write the static route behind it without writing it wrong, the previous section can also be configured in this way using the three-server scheme, instead of using the dummy interface.

a1 configuration

A2 Configuration a1 and a2 only have endpoint IPs and ports are different

c1, c2 configuration, note that c1 and c2 only the port is not the same

Then configure the static route

On the local machine, outbound via a1 (via traffic forwarding) ip route add 192.168.51.2/32 dev a1

On the remote machine, the backhaul directly connects to the ip route add 192.168.51.2/32 dev c2

After that we try ping 192.168.51.2 locally to see how it works

The delay is reduced to 30ms, compared to the previous outbound circumnavigation ntt delay of 70ms, and the jitter is violent, which can be seen that the effect is still obvious.

The current solution still feels that it is not the optimal solution, with the link local address to establish a connection and then add dummy equipment is somewhat cumbersome, there are many things on the computer network that I have not figured out, and this network node is less, in the case of more (>3) routing nodes, whether it can be directly such a simple configuration is still a problem. However, there is too little information about this aspect, and the current configuration method is more troublesome, but it is not unusable, and I hope that everyone will give more advice, there is a better way to connect, please leave a comment to give me a little tip.

The summary above is for scenario 1, and for scenario 2 configuration, I think it can be a good implementation of this requirement, and the effect is quite good, and only need to be configured on both local and remote servers.

This article is reproduced from: “Cloud Native Lab”, original: https://url.hi-linux.com/DLB7T, copyright belongs to the original author. Welcome to contribute, submission email: editor@hi-linux.com.

Recently, we set up a WeChat group for technical exchanges. At present, the group has joined a lot of gods in the industry, interested students can join us to exchange technology, in the “wonderful Linux world” public account directly reply to “add group” to invite you to join the group.