Preface

In the previous article, I deployed openwrt using a virtual machine (see:OpenWrt soft router series PVE deployment OpenWrt (23.05.2) detailed tutorial), in addition to this method, you can also install openwrt directly on a bare metal machine and use docker to deploy openwrt. Without talking about the bare metal installation, I would like to talk about my views on the use of the docker version of openwrt. After all, the docker method is the simplest and is the first choice that more people are willing to adopt (I will not write about how to deploy it specifically, there are many tutorials on the Internet).

Let’s talk about “bypass routing” deployment first

In the previous article (Discussion on the best deployment scheme of soft router series iQuick+openwrt (goodbye, bypass router)) I mentioned that from a network perspective, there is no such thing as "bypass routing" (routing is routing, don't add any qualifiers). From a network professional perspective, this implementation effect should be called: single IP promiscuous mode packet receiving, forwarding and NAT at the same time. In the past, similar requirements have appeared in a special deployment mode: one-arm mode (one-arm). For example, load balancing devices often have one-arm deployment. Interested friends can take a look at the following picture:

In the deployment of single-arm mode, the load balancing device is only connected to the same network segment of the server through a three-layer interface. According to the normal configuration logic, the load balancing device needs to perform dnat (destination address nat) and snat (source address nat) for requests to access vip (the virtual IP address published by the application on the server that needs to load). dnat is the most basic operation of load balancing, and snat needs to be configured according to the specific situation. For example, the server requires to see the real source IP address of the client (some old applications need to obtain the client IP but do not support obtaining it from X-Forwarded-For), so the load balancing device cannot enable snat for requests to access vip. At this time, the server's default gateway must point to the three-layer interface IP of the load balancer. For the server, isn't this the deployment method of "bypass" routing?

However, although this deployment method is supported, from the perspective of load balancing manufacturers, this deployment method is never recommended (X-Forwarded-For is always recommended). There is no other way. The specific technical analysis is too cumbersome. The simple summary is: it wastes the performance of load balancing equipment, easily causes some strange problems on the server (after all, there is an extra hop for no reason), and complicates the network structure (which is not conducive to operation and maintenance and troubleshooting).

The above conclusion is also applicable if the load balancing device is replaced with openwrt.

The only advantage of "bypass routing" is its simplicity. The client only needs to point the default gateway to the interface IP of openwrt, but it brings a series of problems: the network will be interrupted if there is a problem with openwrt, most of the performance consumption of openwrt is not scientific but the normal Internet traffic processing, if the main router has a port mapped to the client, the port mapping may fail, and the network structure needs to be changed (modify the client's default gateway), etc.

Let’s talk about Docker deployment

What are the advantages of Docker deployment? Just search online: continuous deployment, version control, portability, isolation and security. Please note that these advantages do not have stability and performance, and Docker's stability and performance are achieved through cluster technology.

It's not that the performance and stability of Docker alone are necessarily bad, but in my actual use, I feel that the stability of Docker is a little worse than that of Linux deployment. For example, Cloudflare's tunnel, which is deployed in Docker mode, will occasionally fail (the larger the traffic, the more likely it is to happen), while the direct deployment is very stable. At the same time, I think Docker deployment is most suitable for applications that provide content to the outside world (such as nginx, mysql), rather than those that need to frequently access the external network from the container (such as lucky, cloudtunnel, openwrt). For example, see the description of the lucky author:

Description of "shellspec/openwrt" on docker hub (most docker versions of openwrt are installed with this version):

So from these perspectives, the Docker version of OpenWRT is not suitable for use as a "bypass routing" gateway, not to mention that "bypass routing" itself is unscientific.

How to use the docker version of openwrt?

In fact, the general population's demand for science only accounts for a small part of the normal Internet access demand, so the most ideal solution is to allow normal Internet access requests to proceed normally, and to allow scientific requests to proceed specially.

The requests that require science are broken down into: browser science, app science, and cli science.
1. Browser Science
The scientific solution for browsers is Internet plug-ins. For example, Chrome and Edge browsers use smartproxy. Except for the learning stage when you need to click the mouse, it will be easy and pleasant to use afterwards.
2. App Science
For example, the needs of apps under macos and win can be solved by using proxifier, see my other article:The home data center series uses proxifier to allow applications that do not support but need to use a proxy to use a proxy.
3. CLI Science
This type mainly includes situations where there is no graphical interface, such as the science of commands in the Linux terminal. This can be solved using proxychains, see my other article:Home data center series of powerful local proxy tools: proxychains.

These three types of solutions are inseparable from one key point: you need a reliable and high-performance agent, so at this time, openwrt comes on the scene.

I think the docker version of openwrt is the most suitable to provide this kind of proxy. If you originally intend to use openwrt for science, you must have the prerequisites for science. At this time, after using openwrt to open the door to science, you only need to provide proxy services at the same time. As for the way to provide a proxy, if it is openclash, it comes with it:

I am not familiar with other plugins. I remember that the previous scientific Internet plugin also provided socks5 proxy by default. Even if it is not provided, it can be achieved by installing gost (for a detailed tutorial on how to use gost, see:Home data center series uses gost to build its own proxy server and forwarding proxy chain).

Although the proxy approach requires more preparation work than the "side" routing approach (the only disadvantage), it also has many advantages:
1. The workload of the Docker version of OpenWRT is greatly reduced, so you can focus more on science itself, so the stability is also improved
2. There is no need to change the original network structure (no need to manually change the client default gateway or modify the direction of the DHCP default gateway). Don't underestimate this point. It is very important when you go to the customer to implement it. Changing the network structure will be a lot of trouble.
3. If there is a problem with the docker version of openwrt, it will not affect normal Internet access (restarting docker or rebuilding a docker will not waste any time)
4. The traffic logic is clear, and operation and maintenance and fault capture and troubleshooting are very easy (friends with operation and maintenance experience know how important this is)
5. No need to set the host network card to promiscuous mode for a docker
6. Internet traffic is diverted locally on the client, and the traffic sent to the proxy needs to be scientific, which is much more accurate than relying on the diversion of scientific software such as Clash.

Afterword

Having said so many benefits of the proxy method, in fact, the "bypass router" deployment is not completely useless. It can be used as an emergency measure. For example, if you deploy a brand new Linux system with nothing installed, and want to use apt update and install openssh-server, but it is so slow that you have to wait for a long time. Then you want to edit the sources.list file to change the available sources, but you are not used to using vi, and you want to download vim, but it still cannot be downloaded (a friend of mine has often encountered this before). If you encounter such an embarrassing situation, if you have a "bypass router", you can directly modify the default gateway to point to the "bypass router" to solve it (experts who are proficient in using vi can just pretend not to see it~~).