Preface

In the previous article, I used Cloudflare Tunnel to implement ”load balancing”, ”multi-active”, and ”automatic redundancy” functions for multi-node WordPress. However, this method is not suitable for me because my requirement is that when my home data center is normal, all access traffic should go to the main WordPress in the home data center, and only when the home data center experiences a power outage or network disconnection should it automatically go to the WordPress site in the disaster recovery center (Tencent Cloud server).

Requirements Analysis

Currently, I have 2 different tunnels:

In another article of mine (see:Home Data Center Series Cloudflare Tutorial (9) Introduction to Common Zero Trust Features and Multi-Scenario Usage Tutorial), I mentioned that only 1 connector under the same tunnel can be run in the same location, but connectors of different tunnels can be run. That is to say, Tencent Cloud servers can originally run 2 tunnel connectors at the same time. The only point to note is that different deployment methods need to be used. For example, I deployed ”tencentcloud” using the service method, so ”wudihome” must be deployed in a way other than service. Here, I used the Docker method.

The next difficulty is that under normal circumstances, requests to access the blog should only be accessed through the connector of the ”wudihome” tunnel connecting to the home data center, and only switch to the connector connecting to Tencent Cloud when there is a problem with the home data center. In other words, under normal circumstances, the connector of the ”wudihome” tunnel on the Tencent Cloud server is closed; otherwise, access requests would also access the WordPress site from the Tencent Cloud server normally, which conflicts with my requirements.

Solution Idea

Deploying the ”wudihome” tunnel connector via Docker

To fully realize my requirements, we first need to deploy the connector on the Tencent Cloud server via Docker, with a command similar to the following:

docker run --name cloudflare -d --restart=always \
cloudflare/cloudflared:latest tunnel  run --token xxxxxxxxxx #token替换成自己的

Then use the commanddocker stop cloudflareto disconnect this connector. In the future when needed, you only need to rundocker start cloudflareto enable the connector.

Periodically detecting the reachability of the home data center

Then I need a fast way to detect whether the home network is normal. At this time, I have to rely on Tailscale again: directly use the Tailscale address of the main WordPress site (macmini) as the detection target (assuming it is 100.100.100.100).

Note: Why not directly ping the IPv4 public IP address of the WAN port? Actually, it is also possible, but because Telecom's IPv4 public IP addresses are all dynamic public IPs that change every few days, when a change occurs, it is hard to say how long you have to wait when using the dynamic domain name of the WAN port for detection (due to the impact of DNS caching). Tailscale's fixed private IP will quickly adjust to maintain reachability based on changes in the public IP, so it is definitely faster to recover than pinging the WAN port's public IP.

Then, I just need to write a script and run it periodically (for example, every 3 minutes), so I can detect a home data center network outage within 3 minutes at most.

How to enable WordPress on Tencent Cloud to use the access method configured in the ”wudihome” tunnel

This issue is also very important. In the article (Home Data Center Series Cloudflare Tutorial (9) Introduction to Common Zero Trust Features and Multi-Scenario Usage Tutorial), I mentioned that to configure the ”multi-active”, ”mutual redundancy”, and ”load balancing” functions of multiple sites in a single-tunnel, multi-connector environment, you need to correctly configure the correspondence between domain names and applications. Generally, the connector needs to be directly deployed on the host where the WordPress site is located, because only in this way can they be accessed uniformly usinghttp://localhost:80method.

However, my current situation is unusual because the topology of my home data center is quite special. In the public hostname, my ”blog.tangwudi.com“ points to port 50080 of my WAF:

It is definitely impossible to have this IP on Tencent Cloud, so what should we do? Actually, it is very easy to handle, which is to use a loopback address. Just add a loopback interface on the Tencent Cloud server, and then configure the IP address to be the same as my home data center WAF IP (this way, the Tencent Cloud server will think 192.168.1.1 is also its own address, and will accept request packets whose destination address is this address; otherwise, it will discard them directly). You only need to run the following command:

ifconfig lo:1 192.168.1.1/32 up #假设192.168.1.1是我的waf地址

And when it is not needed, you only need to run the following command:

ifconfig lo:1 down

Here I want to complain about Alibaba Cloud Debian 12. It uses nmcli by default, and my most familiar /etc/network/interfaces file is gone. I originally wanted to add a loopback interface once and for all, but after researching for a long time, I still couldn't figure out how to do it... You know, what I hate most is spending a lot of time researching how to add interfaces and how to change IP addresses, which are low-tech operations... I remember a certain version of Ubuntu also suddenly canceled this, making me very uncomfortable, so I switched to Debian~~.

Now that we have the IP, what about port 50080? It's also simple: directly create a blog.tangwudi.com:50080 site, and then use a reverse proxy to point tohttp://localhost:80I'll take a shortcut here and use aaPanel to get it done directly:

Automatically enabling the connector when a home data center network outage is detected

Now only the last step is left: how to automatically start the connector and add the loopback address when a home data center network outage is detected. This will be achieved using a shell script:

#!/bin/bash TARGET_IP &> /dev/null; then(pgrep -f CLOUDFLARE_PROCESS_NAME | wc -l)PROCESS_COUNT -eq 1 ]; then CLOUDFLARE_PROCESS_NAME"(date) - Stopped cloudflare container" >> LOG_FILE(pgrep -f CLOUDFLARE_PROCESS_NAME | wc -l)PROCESS_COUNT -lt 1 ]; then CLOUDFLARE_PROCESS_NAME"(date) - Started cloudflare container" >> $LOG_FILE

The logic is very simple: if it can be pinged and there is cloudflared in the process, it means the home data center was down before but is now connected, so disable the connector of the ”wudihome” tunnel and disable the loopback interface; if it cannot be pinged, it means the home data center is down now, so enable the connector and enable the loopback interface.

To clarify the format and logic of this script, I even spent a whole day brushing up on bash shell basics...

Finally, just set this script to run once every 3 minutes. Whether to use cron or other methods depends on your habits. Since I have aaPanel, I'll take another shortcut:

Advanced Requirements (New)

Because I did the experiment on a newly acquired server from Alibaba Cloud, which didn't have any tunnel running on it originally, the script from the previous section could be used directly. However, it became inappropriate when I applied it to the Tencent Cloud server, because a ”tencentcloud” tunnel was already running on Tencent Cloud. Therefore, it is necessary to further determine the number of processes named "cloudflared" in the process list. If it equals 2 (or is greater than 1), it means both tunnels are enabled in the processes (indicating the main site has gone down, causing a switch). Other cases (equal to 1) are normal, so the script is modified as follows:

#!/bin/bash TARGET_IP &> /dev/null; then(pgrep -f CLOUDFLARE_PROCESS_NAME | wc -l)# Define target IP address CLOUDFLARE_PROCESS_NAME"(date) - Stopped cloudflare container" >> LOG_FILE(pgrep -f CLOUDFLARE_PROCESS_NAME | wc -l)TARGET_IP="100.100.100.100" CLOUDFLARE_PROCESS_NAME"(date) - Started cloudflare container" >> $LOG_FILE

Actually, if more tunnels are running on the same host, you can also modify it by taking the above script as an example. You just need to consider how many tunnels there are under normal circumstances and how many under abnormal circumstances. However, there is a prerequisite that the tunnel processes are running normally; if some are disconnected, the judgment logic above will have issues.

Afterword

Since this is relatively simple, I won't provide the verification process. Anyway, it's just temporarily disconnecting Tailscale on the Mac mini, and then observing whether the scheduled script on Tencent Cloud can start the Cloudflare container, correctly enable the lo:1 interface, and set the IP; then restoring Tailscale on the Mac mini, and observing whether the scheduled script on Tencent Cloud can disable the Cloudflare container and disable lo:1.

Note: The solution in this article and the idea of ”using Cloudflare tunnel to build a multi-active redundant site with traffic load balancing for dynamic blogs” are actually two different solutions (see article:Home Data Center Series Cloudflare Tutorial (9) Introduction to Common Zero Trust Features and Multi-Scenario Usage Tutorialmulti-scenario description), which correspond to ”local data center + same-city disaster recovery data center” and ”local + same-city active-active data center” respectively. The foundation of both solutions isHome Data Center Series: WordPress Multi-Node ”Semi-Automatic”, ”Near” Real-Time Synchronization Solution。

I have always wanted to write this series, but my knowledge reserve was insufficient in the past. Now it is finally completed, which fulfills a wish of mine. However, I estimate that not many people will be interested in these three articles~~.