🛡️ Sovereign Network Resilience Architecture #

Author: Piotr Klepuszewski
Date: November 24, 2025
Status: Technical Report / Implementation Blueprint
Entity: cybersentinel.pl

📑 Executive Summary #

Contemporary distributed system architecture increasingly relies on centralized edge service providers, such as Cloudflare. While they offer a high level of reliability, they constitute a critical Single Point of Failure (SPOF). A systemic provider outage renders dependent services, including cloudflared tunnels, completely inaccessible.

This report provides an analysis for constructing a sovereign “Active-Passive” failover system. The objective is to automatically redirect traffic to a private exit node (VPS)—connected to the origin server via an open-source tunnel (FRP or Rathole)—the moment a primary channel failure is detected.

1. Theoretical Foundations of Infrastructural Independence #

1.1 The Paradox of Centralized Reliability #

Cloudflare provides geographic redundancy that protects against localized outages but introduces the risk of “logical” failures (e.g., BGP routing errors, control plane outages). When the Cloudflare network stops responding, the cloudflared tunnel collapses, and the origin server is cut off from the internet. This necessitates the implementation of a “Lifeboat Protocol”.

1.2 “Break-Glass” Topology #

It is imperative to build a parallel access path that shares zero critical resources with the primary path:

• Primary Path (Cloudflare): User -> Cloudflare Edge -> Cloudflare Tunnel -> Origin Server.
• Failover Path (Self-Hosted): User -> VPS (Exit Node) -> FRP/Rathole Tunnel -> Origin Server.

1.3 DNS Mechanics and Latency (TTL) #

The system’s reaction time depends on Health Check frequency and the DNS Time-To-Live (TTL) record. To minimize the Recovery Time Objective (RTO), the domain’s TTL value must be strictly set to 60 seconds.

2. Tunnel Engineering: Technology Selection #

Replacing Cloudflare Tunnel requires deploying Reverse Proxy software with robust NAT Traversal capabilities.

2.1 Comparative Analysis: FRP vs. Rathole #

Selection: FRP is the more versatile solution for this architecture due to its mature ecosystem and native support for Virtual Hosts (VHOST).

2.2 Resilience: KCP and QUIC #

Standard TCP tunnels are highly sensitive to packet loss. FRP offers support for the KCP (Fast Reliable UDP) protocol. KCP sacrifices bandwidth to minimize latency via ARQ (Automatic Repeat Request), which is a critical trait for connection stability during a failover scenario.

3. Exit Node Implementation #

The exit node (VPS) assumes the role of the edge servers and must be rigorously hardened.

3.1 Network Security: UFW and Fail2Ban #

We block all inbound traffic except for essential ports: SSH (22), HTTP (80), HTTPS (443), and the tunnel control port (7000). The Fail2Ban daemon monitors Nginx logs and dynamically bans IPs exhibiting malicious activity (e.g., HTTP Floods, vulnerability scanners).

3.2 The Role of Nginx as a Reverse Proxy #

Nginx serves as the frontend on the VPS, handling:

• SSL/TLS Termination.
• Buffering and compression (Gzip/Brotli).
• Injection of security headers (HSTS, X-Frame-Options).

4. SSL Certificate Management: DNS-01 Validation #

Standard HTTP-01 validation (Let’s Encrypt) will fail during a Cloudflare outage because the ACME server cannot reach the VPS. The solution is DNS-01 validation. The certbot client contacts the DNS provider’s API to create a _acme-challenge TXT record. This method is independent of the domain’s A record, allowing the VPS to maintain a valid, up-to-date certificate while in standby mode.

5. System Configuration #

5.1 FRP Server (frps.ini on VPS) #

[common]
bind_port = 7000
kcp_bind_port = 7000
vhost_http_port = 8080
authentication_method = token
token = ComplexAuthKey!123

5.2 Nginx Configuration (VPS) #

server {
    listen 443 ssl http2;
    server_name mydomain.com;

    ssl_certificate /etc/letsencrypt/live/[mydomain.com/fullchain.pem](https://mydomain.com/fullchain.pem);
    ssl_certificate_key /etc/letsencrypt/live/[mydomain.com/privkey.pem](https://mydomain.com/privkey.pem);

    location / {
        proxy_pass [http://127.0.0.1:8080](http://127.0.0.1:8080);
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_buffering off;
    }
}

5.3 FRP Client (frpc.ini on Origin Server) #

[common]
server_addr = 203.0.113.10
server_port = 7000
token = ComplexAuthKey!123
protocol = kcp

[web-failover]
type = http
local_ip = 127.0.0.1
local_port = 8123
custom_domains = mydomain.com
use_encryption = true

6. Failover Automation (DNS Failover) #

6.1 Python Watchdog #

A script running on an independent machine periodically polls the website. Upon detecting Cloudflare edge errors (e.g., 502, 522), the script interfaces with the Cloudflare API, updates the A record to the VPS IP, and disables the “proxied” flag (Grey Cloud).

6.2 AWS Route53 (Enterprise Option) #

For mission-critical systems, utilizing Authoritative DNS in AWS Route53 is recommended:

• Health Check: Cloudflare endpoint monitoring.
• Primary Record: A Record (Alias) pointing to Cloudflare.
• Secondary Record: A Record pointing to the VPS IP (Failover routing policy).

7. Testing Procedures #

• Chaos Engineering: Manually editing the /etc/hosts file to simulate routing failures and verify the watchdog script’s reaction.
• Manual Failback: While automatic failover to the VPS is recommended, returning to Cloudflare (failback) should be executed manually only after confirming the sustained stability of the provider’s services.

8. Conclusion #

The presented architecture eliminates dependency on a single vendor. By combining FRP, Nginx with DNS-01 validation, and DNS automation, it is possible to build a sovereign system that guarantees service continuity. In an era of internet centralization, the capability to independently maintain connectivity is a core competency in ensuring business resilience.

# AUTHORIZATION AND SIGN-OFF
Prepared by:
[+] Piotr Klepuszewski  | SRE & Infrastructure Security Lead
Entity: CyberSentinel Solutions LTD
Status: Architecture Blueprint Verified