Preface

In previous articles, I deployed OpenWrt using a virtual machine (see:OpenWrt Soft Router Series: Detailed Tutorial on Deploying OpenWrt (23.05.2) on PVE), in addition to this method, you can also install OpenWrt directly on bare metal or deploy OpenWrt using Docker. Putting bare-metal installation aside, I want to share my thoughts on how to use the Docker version of OpenWrt. After all, the Docker method is the simplest and the preferred choice for most people (I won't write about the specific deployment steps, as there are many tutorials online).

First, let's talk about "bypass gateway" deployment

In the previous article (Soft Router Series: Discussion on the Best Deployment Scheme for iKuai + OpenWrt (Goodbye, Bypass Router)) I mentioned that from a networking perspective, there is no such thing as a "bypass gateway" (routing is routing, don't add qualifiers). From a professional networking standpoint, this implementation should be called: single-IP promiscuous mode packet receiving, forwarding, and NAT simultaneously. In the past, similar requirements appeared in a special deployment method: one-arm mode, such as load balancing devices, which are often deployed in a one-arm configuration. Interested friends can take a look at the diagram below:

In this one-arm mode deployment scenario, the load balancing device connects to the same subnet as the server through only one Layer 3 interface. According to normal configuration logic, the load balancing device needs to perform both DNAT (Destination NAT) and SNAT (Source NAT) on requests accessing the VIP (the virtual IP address published externally for the application that needs load balancing on the server). DNAT is the most basic operation of load balancing, while SNAT depends on the specific situation. For example, if the server requires visibility of the client's real source IP address (some old applications in the past needed to obtain the client IP but did not support getting it from X-Forwarded-For), the load balancing device cannot enable SNAT for requests accessing the VIP. In this case, the server's default gateway must point to the Layer 3 interface IP of the load balancer. For the server, isn't this exactly a "bypass" gateway deployment?

However, although this deployment method is supported, load balancer manufacturers actually never recommend it (they always recommend X-Forwarded-For); it is only used as a last resort. Analyzing it technically in detail is too tedious, but to put it simply: it wastes the performance of the load balancing device, easily triggers strange problems on the server (after all, an extra hop is added inexplicably), and complicates the network structure (making O&M and troubleshooting difficult).

The above conclusion is equally applicable if you replace the load balancing device with OpenWrt.

"The only advantage of a "bypass gateway" is simplicity—you just need the client to point its default gateway to OpenWrt's interface IP. However, it brings a series of problems: if OpenWrt has an issue, the network is interrupted; most of OpenWrt's performance is consumed by processing normal internet traffic rather than scientific internet access; if the main router has port forwarding mapped to the client, it may cause port forwarding to fail; and it requires changing the network structure (modifying the client's default gateway), etc.

Next, let's talk about the Docker deployment method

What are the advantages of the Docker deployment method? A quick search online yields: continuous deployment, version control, portability, isolation, and security. Note that these advantages do not include stability and performance; Docker's stability and performance rely on clustering technologies.

It's not that the performance and stability of a standalone Docker container are necessarily bad, but in my actual use, I feel that with the same deployment method, Docker's stability is slightly worse than deploying directly in Linux. For example, with Cloudflare's Tunnel, the Docker-deployed version occasionally glitches (the higher the traffic, the more likely it happens), while the directly deployed version is rock solid. At the same time, I think Docker deployment is best suited for applications that serve content to the outside (such as Nginx, MySQL), rather than those that need to frequently access the external network from inside the container (such as Lucky, Cloudtunnel, OpenWrt). For instance, look at the explanation from the author of Lucky:

Therefore, from these perspectives, the Docker version of OpenWrt is not very suitable for use as a "bypass gateway," not to mention that the "bypass gateway" concept itself is unscientific.

How to use the Docker version of OpenWrt?

In fact, the average person's need for scientific internet access only accounts for a very small portion of their normal internet needs. Therefore, the most ideal solution is to let normal internet requests go through normally, and let requests requiring scientific internet access go through a special route.

Requests requiring scientific internet access can be further broken down into: browser scientific access, app scientific access, and CLI scientific access.
Browser scientific access
The solution for browser scientific access is browser extensions. For example, Chrome and Edge browsers can use Smartproxy. Aside from needing to click the mouse during the setup phase, using it later is easy and pleasant.
App scientific access
For example, app requirements under macOS and Windows can be solved using Proxifier, see my other article:Home Data Center Series: Using Proxifier to Route Applications That Do Not Support Proxies but Need Them Through a Proxy。
CLI scientific access
This category mainly includes scenarios without a graphical interface, such as scientific access for commands in the Linux terminal. This can be solved using Proxychains, see my other article:Home Data Center Series - A Powerful Local Proxy Tool: proxychains。

These three types of solutions cannot do without a key point: you must have a reliable, high-performance proxy. So at this moment, OpenWrt makes its grand entrance.

For the Docker version of OpenWrt, I think the most suitable role is to provide this kind of proxy. If you already planned to use OpenWrt for scientific internet access, you must already have the prerequisites for it. Once you use OpenWrt to open the door to scientific internet access, you just need to provide proxy services at the same time. As for the method of providing the proxy, if it is OpenClash, it is built-in by default:

Although using a proxy requires more initial preparation compared to the "bypass" gateway method (the only drawback), it also has many benefits:
The workload of the Docker version of OpenWrt is greatly reduced, allowing it to focus more on scientific internet access itself, thereby improving stability.
There is no need to change the original network structure (no need to manually change the client's default gateway or modify the DHCP default gateway pointer). Don't underestimate this point; it is very important when you go to a client's site for implementation, as changing the network structure is much more troublesome.
If the Docker version of OpenWrt has an issue, it does not affect normal internet access (restarting Docker or rebuilding a container takes almost no time).
The traffic logic is clear, making O&M and troubleshooting packet captures very easy (friends with O&M experience will know how important this is).
No need to set the host's network card to promiscuous mode just for one Docker container.
Internet traffic is split locally on the client side, and only traffic that requires scientific internet access is sent to the proxy. This is much more accurate than relying on the traffic splitting of scientific software like Clash itself.

Afterword

Having said so many benefits of the proxy method, the "bypass gateway" deployment is actually not completely useless; it can serve as an emergency measure. For example, if you deploy a brand new Linux system with nothing installed, and you want to run `apt update` and install `openssh-server` but it takes forever, and then you want to edit the `sources.list` file to change to a usable mirror but you are not used to `vi`, and you want to download `vim` but still can't get it (a friend of mine used to encounter this often). In such an awkward situation, if you have a "bypass gateway," you can solve it directly by modifying the default gateway to point to the "bypass gateway" (experts who are proficient in `vi` can just ignore this~~).