Preface

Actually, CF Zero Trust was originally a feature set that I valued highly and prepared to spend a lot of space introducing. After all, it can provide comprehensive security protection for enterprises, and with its important component warp+ (originally, you could use warp+ for free after using warp to link to your own Zero Trust's My Team), I can easily think of many useful scenarios.

Unfortunately, after June, warp(+) for Free plan users is basically completely useless in China, and individual users mostly don't need some enterprise-level features, so I didn't have much motivation to write. In the end, the only parts with practical significance left are Zero Trust's Network and Access.

Zero Trust

Additional Knowledge: About Zero Trust

What is Zero Trust?

“Zero Trust” is a security concept based on the assumption that:No person or device, whether inside or outside the network, should be trusted by default. Unlike the traditional “verify and trust” security model, the Zero Trust model advocates Never trust, always verify. Even if a user or device has been authenticated, their identity and permissions must be re-verified every time they access resources.

Key principles of Zero Trust include:

1. Continuous verification: All access requests must be verified, regardless of whether the requester is an internal or external user.
2. Principle of least privilege: Users or devices can only access the minimum permissions required for their work, avoiding the risk of unnecessary expansion of access privileges.
3. Fine-grained control: Access control based on multiple factors such as user identity, device health status, and geographic location, ensuring that only requests verified through multiple dimensions can obtain access permissions.

This approach reduces the risk of relying on traditional perimeter defenses (such as firewalls) and is better suited to address modern complex security threats and distributed environments. The Zero Trust concept has been widely applied across various industries, especially in remote work and cloud computing environments, ensuring that no matter where users are, access to corporate resources is strictly verified and controlled.

Comparison between Traditional VPN-based Solutions and Zero Trust Solutions

1. Trust Model

• Traditional VPN: Trusts the internal network by default. After connecting to the VPN, users can typically access the entire internal network resources. This model assumes the internal network is secure.
• Zero Trust: Never trusts any user or device, regardless of their location. Every access request must be authenticated and authorized.

2. Access Control

• Traditional VPN: Access control is based on user identity and network location, typically providing broad network access permissions.
• Zero Trust: Adopts the principle of least privilege, ensuring that users and devices can only access the specific resources they need, limiting the potential attack surface.

3. Authentication

• Traditional VPN: Typically uses static usernames and passwords for authentication, and may lack multi-factor authentication (MFA).
• Zero Trust: Emphasizes strong authentication and multi-factor authentication, ensuring that every access request is strictly verified.

4. Monitoring and Response

• Traditional VPN: Less network traffic monitoring, making it difficult to identify abnormal activities in real time.
• Zero Trust: Continuously monitors the behavior of users and devices, enabling rapid detection and response to suspicious activities.

5. Network Architecture

• Traditional VPN: Typically relies on a centralized network architecture, where users access the core network via VPN.
• Zero Trust: Adopts a distributed architecture, segmenting the network to reduce the attacker's lateral movement range within the network.

6. Adaptability

• Traditional VPN: May face security vulnerabilities in scenarios where remote work and cloud computing are prevalent.
• Zero Trust: Designed to adapt to modern work environments, better protecting cloud services and remote access.

As can be seen from the previous comparison, traditional VPN solutions are suitable for relatively simple network environments, but have significant limitations in security and flexibility, especially with the increasing prevalence of remote work scenarios today. In contrast, the Zero Trust solution provides more stringent security measures for modern complex IT environments, effectively addressing today's evolving threats.

Network

The Network section of Zero Trust has two functions: Tunnels and Routes. The most important is Tunnels, which is currently the most critical supporting technology for making my "home data center solution" feasible in China, and naturally, it is the core focus of this article.

CF Tunnel

What is CF Tunnel?

CF Tunnel (formerly known as Argo Tunnel) is a secure, lightweight network tunnel technology that allows users to expose internal services or applications to the internet through CF's global network without exposing the server's public IP address or opening ports. Its basic functions are as follows:

1. Establishing a Secure Connection：

• CF Tunnel creates an encrypted tunnel based on the TCP protocol between your server and the CF edge network, meaning all traffic will be routed through the CF network, thereby avoiding direct exposure of your server.
• When a client (such as a browser) accesses the application, traffic first passes through CF's network and is then transmitted to the internal server through the tunnel. This ensures that network requests are processed through CF's security protection.

2. No Need to Expose Public IP Addresses：

• Traditionally, exposing an application requires opening firewall ports and exposing the server's public IP address. However, CF Tunnel securely proxies all traffic, eliminating the need to open inbound ports on the firewall.

Note: The above two points are a massive blessing for friends in China who want to build a website but do not have an ICP-filed domain name or a public IP address (this applies not only to home data centers but also to domestic cloud hosts).

3. Dynamically Generating Tunnels：

• CF Tunnel uses a client tool (such as cloudflared) to initiate a bidirectional tunnel with CF. Users can easily expose any internal service to CF, whether it is HTTP, SSH, or other protocols.
• The tunnel is dynamically generated with flexible configuration capabilities, allowing the tunnel connection to be started or terminated at any time as needed.

4. High Availability and Load Balancing：

• CF Tunnel can automatically load balance traffic and provide high availability in the event of a tunnel failure. CF's global network ensures efficient and redundant traffic routing through multiple edge nodes, thereby improving application availability.

Note: Point 4 actually doesn't mean much to average users, but it provides many potential advanced features worth exploring.

Detailed Introduction and Practical Operation of CF Tunnel Related Technical Points

---

FBI Warning: Because CF Tunnel can achieve many advanced features, sorting them out clearly requires a lot of professional knowledge and dry theoretical analysis, which can easily cause discomfort (dizziness, blurred vision, sleepiness). Since general routine use does not require those so-called advanced features, friends who are not interested in technical details can skip some parts.

---

tunnel

What is a tunnel?

We already explained the concept of CF Tunnel in the previous section, and the actual configuration representation of CF Tunnel in Zero Trust is the tunnel.

When actually creating a tunnel, I like to use physical location as the standard. For example, "wudihome" in the figure below represents my home data center, "tencentcloud" represents my Tencent Cloud server, and "aliyuncloud" represents my Alibaba Cloud server (tunnels are identified using a tunnel ID):

Note: Using location as a standard to create a tunnel is very easy to understand in general scenarios: a logical tunnel connects CF's network and a physical location. However, in non-general scenarios (where a logical tunnel connects CF's network and multiple physical locations simultaneously), it is actually not very appropriate. Therefore, when a tunnel involves multiple locations, from an operations perspective, a more reasonable naming convention (such as project name) should be considered for the tunnel, though I am too lazy to bother with that here.

Common use cases for tunnel

• Scenario 1: One tunnel contains only one location

This is probably the use case for the vast majority of people, either their own home broadband or a cloud host. The commonality is that to CF Tunnel, they are both a single location (a single source IP). This is the most basic tunnel use case, and the configuration is very simple, with nothing much to say, so it is not the focus of this article.

• Scenario 2: One tunnel contains more than one location, and the service delivery performance of these locations is similar

Possible scenarios include: the egress broadband of the home data center can perform multi-dialing (and each dial has an independent public IPv4 address), so each dial counts as a location (my home data center has 3 dials, and I used 2 dials as ingress/egress for the tunnel), with each location having the same delivery performance (since they all correspond to the main WordPress site, just coming in from different locations); or having multiple cloud servers simultaneously with similar performance (for example, all are 2-core 2G 4Mbps).

• Scenario 3: One Tunnel contains more than one location, and there is a significant difference in the service delivery performance of these locations

Taking myself as an example again, my home data center itself contains 2 locations, and also includes a Tencent Cloud server node, totaling 3 locations. However, the service delivery performance of these 3 locations varies greatly: the 2 locations in the home data center have the same performance, but the Tencent Cloud Lighthouse server (2-core 2G 4Mbps) is barely adequate, just barely enough.

However, when there is high-volume traffic (such as during a DDoS attack), the difference becomes very obvious: the machine hosting my WordPress at home has stronger performance (base model M1 Mac mini), and there are WAF and load balancing devices at the frontend for preprocessing. Consequently, when facing attack traffic that has already been scrubbed once by CF (DDoS protection and WAF), the abnormal attack traffic that ultimately reaches my main WordPress site is estimated to be only around 1%. Additionally, even if my main WordPress site goes down, requests can be automatically redirected to the backup WordPress site (deployed on an Intel CPU mini host) via local load balancing devices. Therefore, for me, the performance and security of the home data center WordPress site far exceed those of a bare Tencent Cloud server.

Precisely because Scenario 3 is the actual scenario I encounter, I would consider a disaster recovery solution where "the Tencent Cloud server automatically takes over the blog only when the home data center fails" (see the latter part of the article for details).

Note: Conversely, a single location can also run multiple different tunnels, but I won't go into detail here to avoid confusing everyone. If needed, you can think about this scenario on your own.

connector

What is a connector?

A connector is actually a concept subordinate to a tunnel, corresponding to the "location" in the tunnel: when the same tunnel is composed of multiple different physical locations, the tunnel needs to use connectors to distinguish between different locations.

Similar to how tunnels are identified using a tunnel ID, connectors are represented using a connector ID.

So how are the same locations and different locations distinguished? It relies on the "source IP address" of the different locations seen by CF when they connect to the CF network using their own connectors.

---

The reason "source IP address" is in quotes is that the perception is different for locations with a public IP and locations without a public IP.

For locations with a public IP (such as my home data center), I can clearly define which egress link the device running the connector goes out of. Since each of my 3-dial links has a public IPv4 address (the chosen one, what can I say? How many people can still do multi-dialing now and get a public IPv4 for each dial? Not to mention IPv6!), theoretically, I can have up to 3 different devices running connectors simultaneously going out from different egress links, thereby creating the effect of having 3 different locations (if I add my 5G CPE router, I can create 4 locations~). Of course, under normal circumstances, two are enough. After all, in this scenario which is originally just one physical location, multiple connectors are mainly used for redundancy to prevent blog access interruption caused by a problem with one of the connectors:

On the other hand, if a location does not have a fixed, dedicated public IP (for example, running a tunnel on home broadband without a public IP), then the "source IP" of the location seen on the CF edge network is uncontrollable, so it can only be left to fate. Normally, within a certain period of time, it will definitely only correspond to one public IP (which could be an IPv4 address or an IPv6 address, depending mainly on the ISP's NAT policy).

---

When there are multiple connectors in the same tunnel, the advanced feature of "multi-site load balancing and automatic redundancy" will be automatically activated: origin-pull requests will automatically choose different connectors to send through (if using the free plan, this feature is uncontrollable), and at the same time, when a connector goes down, origin-pull requests will automatically be sent through the remaining normally running connectors. These features actually provide many potential high-end playstyles, including: multiple WordPress sites providing services simultaneously to achieve global load balancing and redundancy, disaster recovery sites that can automatically take over business when the main WordPress site fails, etc. (just using WordPress as an example, any website building method works).

Note: Regarding the choice of origin pull (for the specific concept of origin pull, please refer to Part 3 of the CF Series Tutorial:Home Data Center Series Cloudflare Tutorial (Part 3): How to Enter CF's Edge Network and How to Choose a Suitable Origin Pull Method) method, if the origin host is in China, regardless of the environment (cloud host, home broadband), I only recommend using the tunnel method for origin pull: 1. The domain name does not need to be registered/ICP-filed (the disadvantage is that domestic CDNs cannot be used, but CF itself has a free CDN, which can be optimized to get by), 2. No public IP is required (it doesn't matter whether the home data center has a public IP or not), 3. No need to configure reverse proxy and SSL certificates (as it directly connects the intranet and the application's HTTP port for communication), 4. Absolutely no risk of exposing the origin server's IP (if the origin server has a public IP), which is safe and hassle-free. Why not?

Common configurations for connector

Actually, the deployment of the connector is very simple. You can see the created tunnel in CF's "Zero Trust"–"Networks"–"Tunnel":

Enter the existing tunnel, taking wudihome as an example:

Choose the installation method that suits you:

Deploying connectors in different locations is essentially the same (if it is the same system, such as Debian, the commands run are the same). The different connector IDs displayed in the tunnel in the end are just because CF sees different origin IPs for these locations (if there are multiple connectors but the origin IP is the same, my test results show that the access speed will drop significantly, as if the tunnel cannot correctly choose the origin pull connector in this situation).

Public Hostname

The two concepts of tunnel and connector described above combined only provide a logical basic channel to connect the CF network with our own internal network (as the saying goes: "To get rich, build roads first", but having roads is not enough, you also need to transport agricultural products out by vehicles to sell them to get rich). The final step is to securely publish internal services or applications to the Internet through a domain name, which is the role of the "public hostname" function (here comes the vehicle!). However, in actual deployment, depending on the environment, the setting method of the public hostname (mainly the IP address of the application in the URL part) varies.

Single Tunnel, Single Connector (Common Scenario)

This is the scenario encountered by the vast majority of personal webmasters. The public hostname can be added by configuring it according to the steps in the image below:

For personal webmasters, it is usually a single-tunnel, single-connector (only one location) deployment method, and the connector and the application are deployed on the same device. In this case, the URL can just be set to localhost:port.

Note 1: For detailed configuration steps in this scenario, please refer to my previous article:Home Data Center Series: Using Tunnel Technology to Enable Home Broadband Without Public IP to Leverage Cloudflare for Free to Achieve Rapid Website Setup (Recommended)。

Note 2: Do not replace localhost with 127.0.0.1.

Single Tunnel, Multi-connector (Advanced Scenario)

For personal webmasters, this scenario is relatively rare (probably only a small number of high-end users will encounter it~). In addition to multiple connectors corresponding to multiple locations, it is highly likely that the connector and the application are not deployed on the same device. In this case, you cannot just blindly fill in localhost:port in the URL like in the previous scenario.

However, whether you can achieve "multi-site load balancing and automatic redundancy" for multiple sites, correctly setting the URL in the final step is the most critical, and may even require a bit of trickery:

Actually, the key is what address should be filled in the red box in the image above. Strictly speaking, it should be: "From the perspective of the node where the connector is deployed, what is the IP address of the application?" Below we discuss three scenarios.

• Multiple connectors, and the application and connector are on the same device

If more than one device deploys a connector, for example, an Alibaba Cloud server and a Tencent Cloud server, which respectively deploy 2 connectors corresponding to the same tunnel (corresponding to 2 connector IDs in the tunnel), and the applications (such as WordPress) deployed on both servers use the same port (such as port 80), then "localhost:80" should be filled in the red box. In this way, no matter which connector the access request is allocated to by CF and which server it reaches, it can access its own installed WordPress through "localhost:80". This is the most basic "multi-site load balancing and automatic redundancy" deployment method.

Note: It seems some people also use this method to treat multiple home broadbands as multiple connectors connected under the same tunnel, using multiple connectors to disperse traffic and requests during DDoS attacks. However, in my opinion, this is actually treating the symptoms rather than the root cause. For a "true home data center" solution, a free WAF and an open-source load balancing software can easily handle the slip-ups after CF DDoS protection and WAF double-layer filtering. I will write about this after I clear the article tasks in my queue; after all, this can be considered an advanced version of the home data center security solution.

• Multiple connectors, but the application and connector are not on the same device

This situation is actually the scenario of my home data center: I used two Debian LXCs (assuming the IP addresses are 172.16.0.1 and 172.16.0.2 respectively) in my home data center to deploy connectors, and only connectors are deployed on these two LXCs.

The real address of my WordPress is 172.16.0.3 (actually it's not, this is the WAF address, but from the outside it can be considered the WordPress address), so at this time, I should fill in 172.16.0.3 in the red box above, because from the perspective of deploying the connector (no matter which one), WordPress can only be accessed through 172.16.0.3:80.

Note: When the connector and the application are not on the same device, the range of addresses that can be filled in the URL depends on the routing of the device where the connector is deployed. Any address that is routable can be filled in.

• Under the same tunnel, both scenarios 1 and 2 exist

Still taking my home data center as an example: now I have also deployed the connector for the "wudihome" tunnel on the Tencent Cloud server. In this case, the localhost:80 writing method of the first scenario applies; but at the same time, there is also the connector of the home data center, which requires the 172.16.0.3 writing method of the second scenario. How to resolve this contradiction?

In this scenario, you need to flexibly use the loopback interface. You only need to create a new loopback interface on the Tencent Cloud server and configure its IP address as 172.16.0.3. At this time, access reaching the Tencent Cloud server with the destination address of 172.16.0.3 will be considered by the Tencent Cloud server as access to itself, thereby processing the request normally.

Of course, in a real environment, I will not enable all connectors at the same time (as mentioned earlier in the article, the performance and security of the home data center's main WordPress site are incomparable to those of the Tencent Cloud server). Therefore, by default, the connector on the Tencent Cloud server is turned off, and only when the home data center fails (power outage, network disconnection) will the connector be automatically turned on to take over the services of the main WordPress site (friends who are interested in the specific implementation details and related operations of this solution can refer to the article:Home Data Center Series: Flexibly utilizing Cloudflare Tunnel to achieve automatic takeover by disaster recovery site when the main WordPress site fails)。

Note 1: A loopback interface is a special interface in a network, usually used for testing, debugging, and local host communication. Its most common IP address is 127.0.0.1, which is known as the “localhost” address. However, in addition to the localhost address, loopback addresses have many other uses. The most common is in local enterprise networks, where Layer 3 devices configure dynamic routing protocols (RIP, OSPF, IS-IS) to use it as a Router ID, which can achieve network-wide reachability of the loopback address, making it very convenient for managing Layer 3 devices or troubleshooting routing issues. The usage in this article is just the most basic use of the loopback interface, but it is an important technical puzzle piece that ultimately enables my disaster recovery solution mentioned above to be realized.

Note 2: Using the loopback address as a Router ID to achieve network-wide reachability has certain similarities with the effects achieved by Anycast IP in terms of "network-wide accessibility" and "virtualization and stability", which can help everyone understand the implementation principles of Anycast IP technology.

Multi-protocol Support

For public hostnames, it is not limited to publishing applications based on the http(s) protocol; it also supports publishing many applications based on other protocols:

However, these applications based on non-http(s) protocols mainly achieve single-point connection through CF Tunnel, and unlike http(s) applications, they do not support multi-point access or optimization across multiple locations (because they cannot use the Anycast technology provided by CF by default), which leads to rather limited use cases for these applications.

However, CF Zero Trust can still provide security features such as authentication, access control, and logging for these non-http(s) applications, so it still has some value (better than nothing~).

Routes

---

Note: You only need a basic understanding of this part. It was originally meant to be used in conjunction with warp+ and the My Team feature. Unfortunately, Free plan users in China can no longer use warp+. However, since the Network section already covers Tunnel, omitting this would make the article structure feel incomplete, which doesn't fit my aesthetic.

---

"Routes" is the section used to configure network traffic routing rules. It allows you to define how to handle traffic when users access internal resources through the CF network. This is one of the key components of implementing a Zero Trust architecture, ensuring that all traffic is monitored and controlled.

Core features of the Routes function:

1. Traffic Control: Through Routes, you can define which traffic should be processed through CF's Zero Trust network. This includes the connection path from the user's device to the target resource, thereby ensuring that network access complies with Zero Trust security policies.
2. Policy Application: Routes allows specifying policy rules applied to traffic, such as forcing VPN usage, verifying identity, or applying access control policies. This helps enhance security, ensuring that only verified users and devices can access internal resources.
3. Fine-grained Configuration: You can create fine-grained routing rules based on different subnets, IP address ranges, or DNS names to adapt to network access needs in different scenarios.

To briefly explain a practical use case: back when warp+ could be used with the My Team feature, if I had multiple locations, such as a home data center (subnet 192.168.10.x/24) corresponding to the tunnel "wudihome", and a Tencent Cloud server (subnet 10.0.0.3/32) corresponding to the tunnel "tencentcloud", I could set up Routes as follows:

Once successfully connected to warp+ (which must be correctly associated with My Team), you could directly access 192.168.10.x inside the home data center as well as 10.0.0.3. This was much more advanced than the old IPsec VPN point-to-point access. However, now that warp+ is unusable, we can no longer enjoy this. Of course, although I have this need, I don't use warp+ to achieve it anyway—with Tailscale available, who needs anything else?

Note: For those who are interested in how to use warp and whose environment allows it, you can refer to my previous article:Home Data Center Series: Make Rational Use of Cloudflare WARP to Improve Your Website Access Speed (Desktop Version)和Home Data Center Series: Deploy Cloudflare WARP on Cloud Servers to Improve Network Access Speed (Linux CLI Version)。

Access

What is Access?

Zero Trust's Access feature is to provide enterprises with secure access control solutions based on a Zero Trust architecture. It ensures that only authenticated and authorized users can access specific applications and resources, regardless of whether these resources are located in on-premises data centers or the cloud.

In plain English: through Access, you can publish internal applications directly to the public internet, and use various authentication methods and security measures to ensure application security while allowing those who truly need it to access the application quickly.

Main Features:

1. Authentication Integration：

• Supports integration with multiple identity providers (such as Google, GitHub, Facebook) to achieve Single Sign-On (SSO) and Multi-Factor Authentication (MFA), ensuring that only verified users can access protected resources.

2. Policy-Based Access Control：
   • Administrators can create fine-grained access policies to control who can access specific applications and resources based on conditions such as user identity, location, and device attributes. This policy-driven access control improves security and flexibility.

3. VPN-less Access：

• CF Access provides a VPN-free alternative, allowing users to directly access internal corporate resources through CF's global network, thereby reducing VPN complexity and latency while improving security.

4. Auditing and Logging：

• Access provides detailed logging and auditing features, allowing administrators to track who accessed which resources and when, enhancing visibility and auditing capabilities for access activities.

Unfortunately, most of the authentication features in the Access section either require third-party integration (such as Google, GitHub, Facebook, etc., mentioned earlier) or need to be integrated with corporate website development (such as various Tokens). For individual users, the only truly simple and practical authentication method is basically receiving an OTP (one-time pin) via email.

Using Access to Add Authentication to Your Published Web Applications

Select the web application to be published

An application is needed for demonstration, so I created a new domain "ac86u.tangwudi.com" and linked it to the login interface of my intranet Asus AC86U. At this point, access can open normally:

Create an Access Group in advance

When adding an application, the application needs to belong to a certain "Access Groups" (access group), so it needs to be created in advance:

---

The Selector also has an email option "Emails ending in":

This method is suitable for cases where multiple email addresses share the same email suffix (such as corporate emails). However, friends who have configured the CF Email Routing feature (see article: ) and have their own domain suffix emails can also use this method. In this case, as long as you assign a domain suffix email account to each friend (linked to their real email), you can set up just this one authentication rule, and all friends can access the application you published that requires verification.

---

Add application

To use Access to add authentication features to your own web application, just follow the process below.

Add an application (Application):

Select Self-hosted:

Configure parameters for the application:

Other options on this page can be left at their defaults to save trouble, but you can also spend some effort on certain options, such as the logo:

After configuring, select Next to continue to the next page of settings:

Set up the application's policy name and policy action:

Then directly click "Next" in the bottom right corner to continue to the next page of settings:

Finally, add the application:

Application creation completed:

Test the authentication effect

Reopening "ac86u.tangwudi.com", the interface becomes like this:

It instantly looks much more professional. Enter the email address configured earlier in the Email box and send the verification code:


Then you can see the real application interface, and the address is also the real address (it was the my team address during authentication earlier):

Additional Knowledge: OAuth

In fact, for individual users, besides using email to get OTP codes for verification (simple and practical but a bit low-tech), they can also use OAuth for third-party authentication (Google, GitHub, Facebook, etc.).

What is OAuth?

OAuth (Open Authorization) is an open standard that allows users to authorize third-party applications to access their information on a certain service without sharing their username and password. It is commonly used for secure access between social media, online services, and applications.

Basic Concepts:

1. Resource Owner : User, who owns the resources (such as personal information, photos, etc.).
2. Client : The application or service (such as a social media app) that requests access to resources.
3. Authorization Server : The server that authenticates the user's identity and issues access tokens (such as Google or Facebook's authentication service).
4. Resource Server : The server that stores user resources (such as the server storing user photos).

Workflow:

1. The user clicks the “Log in with XXX” button on the client application.
2. The client redirects the user to the authorization server, where the user logs in and authorizes the client to access their resources.
3. After the authorization server authenticates the user's identity, it returns an authorization code to the client.
4. The client uses the authorization code to request an access token from the authorization server.
5. The authorization server validates the authorization code and returns the access token to the client.
6. The client uses the access token to request the user's resources from the resource server.

This is actually something everyone often uses in daily life in China, which is authorizing via QQ or WeChat accounts when logging into an app.

How to add third-party OAuth?

Follow these steps to add third-party OAuth:

Select an IdP (Identity Provider), taking GitHub as an example (provided you have a GitHub account):

Then just follow the tutorial on the right to set it up:

Finally, after success, an additional GitHub verification option will appear:

The result of using this method is that any user with a GitHub account can pass verification. If you want to further control which people with GitHub accounts can access your application, you need to configure additional access control policies in Zero Trust, such as finer-grained control based on user groups, roles, etc. If you are interested, you can look into this; I won't bother with it as it's not very useful for me. The settings location is right here:

Of course, a single GitHub authentication is not very impressive, so you can add others as well. This way, having an account with any IdP allows directly initiating a login request (making it look very high-end, like having many allies~). However, whether you can ultimately pass authentication depends on the conditions you set.

Afterword

In itself, although the CF Tunnel feature is very powerful, it is just one of the two conventional origin-pull options coexisting with public IP origin-pull. From the perspective of pulling origin from a single origin server, compared to the public IP origin-pull method, it can only be said that each has its own advantages and disadvantages:
Encrypted Tunnel

For networks in other countries, whether to use an encrypted tunnel or not doesn't matter. In the public IP origin-pull method, using HTTPS to pull from the origin server can similarly guarantee the security of the origin-pull.
No Public IP

For networks in other countries, if there is no IPv4, there is always IPv6. Even if there isn't, applying for one is not difficult. At worst, finding any domestic cloud host will provide a public IP (at least IPv6), so the public IP issue is very easy to solve for building websites.

However, for building websites in a domestic environment, using the public IP address origin-pull method requires ICP filing, regardless of whether a domain name or pure IP is used:

Coupled with the difficulty of obtaining public IPs and home broadband operators frequently clearing inbound HTTP(S) access to unregistered domains, the public IP origin-pull method has basically been rendered completely useless. Therefore, at this time, the origin-pull method provided by CF Tunnel, which is based on fully encrypted TCP tunnels and does not require a public IP, is simply unbeatable, isn't it?

Of course, using CF Tunnel to build a website also has disadvantages by default:
Slow origin-pull

If the origin server is in China, the slow origin-pull cannot be solved because it pulls from overseas data centers, crossing the Pacific back and forth; it would be strange if it were fast.
Slow access

For applications published after enabling the orange cloud, the resolved IPs are all overseas IPs (for webmasters on the Free plan), so it is considered overseas website hosting. At this time, the speed of direct access from China is painfully slow.

These two reasons combined mean that before optimization, access from China can only be considered barely usable. Therefore, if your primary target is seriously domestic users and you require a good domestic access experience, you should honestly go through the ICP filing process and then use the acceleration services provided by domestic CDN providers. This ensures a good access experience without hassle. Of course, the subsequent issues of paid CDN traffic being maliciously consumed and expensive DDoS protection costs are also things you must face.

So, is it possible to use CF Tunnel to build a website while also wanting the domestic access experience to not be too bad?

It's not impossible; the answer is hidden in the previous Cloudflare tutorial series~.