Table of Contents
VPN setup that’ll always work-even in China

Censorship gets craftier every year. What worked last summer gets throttled or fingerprinted this winter. The point of this guide and the script it ships with is simple: stop playing whack-a-mole. Build a transport that looks like web browsing from the outside, but runs a fast, private tunnel underneath. Just TLS’ing it, nothing to see over here.

The idea in one breath

  • Client ↔ Edge (entry hop): VLESS + REALITY over TCP. From the wire’s perspective, it’s just TLS 1.3 to a normal website (your chosen SNI).
  • Edge ↔ Egress (exit hop): WireGuard over UDP for speed (Yay).
  • Egress ↔ Internet: NAT out to the open web.

REALITY makes your ClientHello look like a legit browser going to a real site (e.g., google.com). The edge box terminates that while binding all outbound to WireGuard, which carries your packets to the egress box. The egress then talks to the internet. No gaudy signatures, no flashy ports. Governments cannot block that without collateral damage aka (Breaking normal websites).

[Device] --(TLS1.3/REALITY over TCP)--> [Edge/Entry]
                                 (WireGuard/UDP)
                          ----------------------------->
                                         [Egress/Exit] --(NAT)--> Internet

This is not magic, and it won’t definitely beat a targeted investigation, That’s what I2P is for (kinda). But for day-to-day censorship and noisy DPI boxes, it’s boring in all the right ways.

Who this is for

  • You need a reliable connection through heavy-handed filtering (e.g., Great Firewall) without spending weekends swapping configs.
  • You want one script that handles IPv4/IPv6, sane defaults, idempotent setup, and a clean purge switch when things get wedged.
  • You prefer TCP at the edge (harder to block without breaking normal web) and UDP speed where it’s safe—between your own servers.

Not your use-case if you want a click-once consumer VPN or you don’t control at least the first hop VPS. You can use a commercial VPN as the second hop but pick one that gives you plain WireGuard configs. If you insist on NordVPN, it works, just messier.

What you get (features)

  • Double-hop by design: TCP camouflage at the edge, WireGuard performance underneath.
  • REALITY: Browser-like TLS 1.3 handshake toward a real host (SNI must be an actual DNS name with a valid SAN).
  • IPv4/IPv6 modes: v4-only, dual-stack, or v6-preferred.
  • Systemd hardening option: Run sing-box as a dedicated singbox user with restricted capabilities.
  • nftables/iptables awareness: Uses iptables by default; logs which backend you’re on so you’re not surprised on Ubuntu 24.04+.
  • Health probe: A tiny checker to confirm SNI, TLS 1.3, and key exchange sanity.
  • Purge mode: --purge nukes the service, configs, user, and logs; --flush-iptables optionally restores your pre-install rules.

Threat model (short and honest)

  • Beats mass filtering (DPI based on known VPN fingerprints, weak SNI/JA3 blocking, naive port blocks).
  • Won’t beat targeted endpoint compromise or powerful, bespoke analysis against your exact servers.
  • Operational security matters: Don’t reuse boxes for unrelated services; keep OS and kernel updated; pin versions when you can.

Requirements

  • Two Linux servers (Ubuntu 22.04/24.04 work great).
    • Edge (entry): public IP reachable from the client (This should be a VPS on your home country). Governments usually do not apply full restrictions to cloud companies.
    • Egress (exit): public IP with UDP allowed; this is your internet breakout.
      The exit hop can also be a WireGuard config provided by your VPN Provider, although only a few provide wg configs.
  • Ability to open ports on your provider firewall/security groups:
    • Edge: a TCP port for REALITY (e.g., 443 or an inconspicuous high port).
    • Egress: a UDP port for WireGuard (e.g., 51820).
  • A real SNI (hostname) present in the target site’s certificate SAN (e.g., google.com).
    This is the website you want to look like you are browsing.

Quickstart (two hops, minimal prompts)

1) Egress (2nd hop)

This is your WireGuard server and NAT out to the internet.

Bash
# Example: listen on UDP 51820
wget https://raw.githubusercontent.com/abdessalllam/SuperSpeedVPN/refs/heads/main/installer.sh
chmod +x installer.sh
# ReadME for Links: https://github.com/abdessalllam/SuperSpeedVPN
sudo ./installer.sh --role 2nd --wg-port 51820 --silent

What it does:

  • Installs WG, sets up the server, enables IPv4/IPv6 forwarding, basic firewall rules, and NAT.
  • Prints a small bundle you can copy to the edge.

After you are done, Move wg-link-bundle.tar.gz file to your 1st hop ~ (/root/).

2) Edge (1st hop)

This is where your client connects with REALITY over TCP. The edge uses WG as its outbound.

Bash
# Example: TCP 443 for REALITY, SNI is a real hostname (must be DNS, not an IP)
wget https://raw.githubusercontent.com/abdessalllam/SuperSpeedVPN/refs/heads/main/installer.sh
chmod +x installer.sh
# ReadME for Links: https://github.com/abdessalllam/SuperSpeedVPN
# Use an SNI that's not blocked in your country
sudo ./installer.sh --role 1st --reality-port 443 --sni google.com
# The script will only allow domains that support TLS 1.3

Notes:

  • If you don’t provide a handshake target, it defaults to SNI:443.
  • The edge binds its outbound to wg0, so everything exits through the egress hop.

3) Client

Use any modern client that supports VLESS + REALITY (e.g., sing-box). The script outputs a ready-to-import snippet.

How to use with a VPN Provider as 2nd Hop

  1. Skip 2nd Hop Install as you do not have access to the second server.
  2. Get WireGuard Config keys and use your 1st hop server if the VPN provider asks for Device IP.
  3. Create a Tar Gz file named wg-link-bundle with 3 files h2_publickey with plain wg public key, h1_privatekey with plain wg private key, vars with the following details:
Text Editor
Get the following from your WG Config and create 3 files.
# h2_publickey file: 
EXAMPLEPUBLICKEYHGHD78HD

#h1_privatekey file: 
EXAMPLEPRIVATEKEYHGHD78HD

# vars file: 
WG_PORT=53133
WG_IF=wg0
WG_H1_V4=10.43.0.1/32
WG_H1_V6=fd00:43::1/128
WG_H2_V4=10.43.0.2/32 # From AllowedIPS list in your WG Config
WG_H2_V6=fd00:43::2/128 # From AllowedIPS list in your WG Config
H1_V4_POOL=10.43.0.0/24
H1_V6_POOL=fd00:43::/64
IPV6_MODE=dual # or ipv4only, dual means ipv4/ipv6
H2_ENDPOINT=IP:53133 # WG Config endpoint

Next, Tar them and upload them to /root/ and run the 1st-hop script.

Purge & reinstall (your “big red button”)

If something weird occured, or you just want a clean slate:

Bash
# Remove sing-box service, configs, binary, logs, and singbox user
sudo bash installer.sh --purge

Then run the Quickstart again. The purge routine is idempotent; use it whenever you need to reset.

IPv6 modes (and when to care)

  • Dual-stack (default): Best reachability and performance when both v4 and v6 are available.
  • v4-only: Handy when v6 paths are flaky or trigger site-specific “VPN” heuristics.
  • v6-preferred: Great in regions where v6 routes are less congested.

The script guards against an empty v6 WAN interface when setting accept_ra=2, so you don’t end up with broken sysctls.

Firewall backend reality check

Ubuntu 24.04 leans on nftables even when you install iptables-persistent. The script logs which backend is active before applying lockdown rules. If you’re a purist, swap the rule writer to native nftor keep iptables for portability; just be aware of the translation layer.

Health checks (trust but verify)

After provisioning, run the probe to confirm the camouflage layer is behaving:

Bash
./installer.sh --probe --sni google.com

You want to see:

  • TLS 1.3 negotiated
  • X25519 (or another sane ECDH group)
  • SNI listed in the certificate SAN

If the probe fails, double-check that your SNI is a DNS hostname and reachable, and that your REALITY port is open.

Performance tips that matter

  • Use TCP BBR on both servers: echo "net.core.default_qdisc=fq" | sudo tee /etc/sysctl.d/99-bbr.conf echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.d/99-bbr.conf sudo sysctl --system
  • Pick a quiet WireGuard UDP port (not 51820 if your provider shape-detects it).
  • Right-size MTU: WG defaults are good, but if you see fragmentation, experiment (e.g., 1280-1380).
  • Pin versions and avoid curl | sh for production. Download, verify checksums/signatures, then install.

Troubleshooting (fast path)

  • Client can’t connect to edge: Is the REALITY TCP port open on your provider firewall? Is SNI a real hostname, not an IP?
  • Edge can’t reach egress: Check that WG UDP is reachable from edge to egress. If you’re behind a strict upstream, try a different port or enable UDP-over-UDP hole-punching if your provider supports it.
  • It’s “connected” but no internet: Look at NAT/forwarding on the egress. IP forwarding must be on; MASQUERADE rules must exist.
  • Weird geo/streaming behavior: If certain sites are touchy about IPv6, temporarily flip the edge to v4-only and retest.
  • WG port shows closed from the outside: Some clouds block by default. Verify security groups, NACLs, host firewall, then ss -ulpn. You might not recieve traffic due to provider-side UDP policies.

Why this holds up under pressure

  • Camouflage over confrontation: It’s easier to pass through the filter if you look like normal TLS. REALITY leans into that.
  • Damage control: You don’t lose everything if the egress IP is flagged; swap egress, keep the edge/SNI stable.
  • Operational toggles: IPv6/IPv4 modes, purge, and idempotent reruns make maintenance boring—exactly what you want.

This guide focuses on privacy and reliability “not breaking laws”.

Closing

Brittle setups die by a thousand papercuts. This one embraces boring: TLS on top, UDP under the hood, clean defaults, and a panic button when you need it. Set it, verify it, document your chosen ports/SNI, and move on with your life. Censors will keep innovating; so will we—but we’ll do it the lazy, maintainable way.

Categorized in:

Cybersecurity, Guides,