xwPF.sh Realm Forwarding Script

Port Traffic Dog

Relay Network Link Testing Script

===================== Network Link Test — Full Report =====================

✍️ Parameter Test Report
─────────────────────────────────────────────────────────────────
  Initiated from local machine (client)
  Target: 92.112.*.*:5201
  Direction: Client ↔ Server
  Duration per test: 30 seconds
  System: Debian GNU/Linux 12 | Kernel: 6.1.0-35-cloud-amd64
  Local: cubic+htb (congestion control + qdisc)
  TCP receive buffer (rmem): 4096   131072  6291456
  TCP send buffer (wmem): 4096   16384   4194304

🧭 TCP Large-Packet Route Analysis (via nexttrace)
─────────────────────────────────────────────────────────────────
 AS path: AS979 > AS209699
 ISP: Private Customer - SBC Internet Services
 Geo path: Japan > Singapore
 Map: https://assets.nxtrace.org/tracemap/b4a9ec9f-8b69-5793-a9b6-0cd0981d8de0.html
─────────────────────────────────────────────────────────────────
🌐 BGP Peering Analysis (via bgp.tools)
─────────────────────────────────────────────────────────────────
Upstreams: 9 │ Peers: 44

AS979       │AS21859     │AS174       │AS2914      │AS3257      │AS3356      │AS3491
NetLab      │Zenlayer    │Cogent      │NTT         │GTT         │Lumen       │PCCW

AS5511      │AS6453      │AS6461      │AS6762      │AS6830      │AS12956     │AS1299
Orange      │TATA        │Zayo        │Sparkle     │Liberty     │Telxius     │Arelion

AS3320
DTAG
─────────────────────────────────────────────────────────────────
 Image: https://bgp.tools/pathimg/979-55037bdd89ab4a8a010e70f46a2477ba7456640ec6449f518807dd2e
─────────────────────────────────────────────────────────────────
⚡ Link Parameter Analysis (via hping3 & iperf3)
─────────────────────────────────────────────────────────────────────────────────
    PING & Jitter             ⬆️ TCP Upload                        ⬇️ TCP Download
─────────────────────────  ─────────────────────────────  ─────────────────────────────
  Avg: 72.3ms              220 Mbps (27.5 MB/s)             10 Mbps (1.2 MB/s)
  Min: 69.5ms              Total transferred: 786 MB        Total transferred: 35.4 MB
  Max: 75.9ms              Retransmits: 0                   Retransmits: 5712
  Jitter: 6.4ms

─────────────────────────────────────────────────────────────────────────────────────────────
 Direction  │ Throughput               │ Packet Loss              │ Jitter
─────────────────────────────────────────────────────────────────────────────────────────────
 ⬆️ UDP Up   │ 219.0 Mbps (27.4 MB/s)    │ 2021/579336 (0.35%)       │ 0.050 ms
 ⬇️ UDP Down │ 10.0 Mbps (1.2 MB/s)      │ 0/26335 (0%)              │ 0.040 ms

─────────────────────────────────────────────────────────────────
Completed: 2025-08-28 20:12:29 | Source: https://github.com/zywe03/realm-xwPF

For servers with absolutely no network connectivity.

1. Download the following files on a machine that does have internet access

• Main script: xwPF.sh

• Module files (all required): https://github.com/zywe03/realm-xwPF/tree/main/lib

• Realm binary (pick the one matching your architecture):

2. Place the files on the target server

/usr/local/bin/            ← Script install directory (fixed path)
├── xwPF.sh                ← Main script
└── lib/                   ← Create this subdirectory
    ├── core.sh
    ├── rules.sh
    ├── server.sh
    ├── realm.sh
    └── ui.sh

~/                         ← Put the Realm tarball anywhere else
└── realm-xxx.tar.gz

3. Run the offline installation

chmod +x /usr/local/bin/xwPF.sh
ln -sf /usr/local/bin/xwPF.sh /usr/local/bin/pf
bash /usr/local/bin/xwPF.sh

Select 1. Install & Configure, then:

1. When prompted Update script? (y/N): → Press Enter to skip (cannot update offline)
2. When prompted Enter full path for offline Realm installation (press Enter to download automatically): → Provide the full path to the Realm tarball

The relay server runs Realm; the exit server runs your application.

Realm on the relay simply passes packets received on the configured listen IP:port straight through to the exit — encryption and decryption are handled entirely by the application on the exit server.

The encryption protocol for the entire link is therefore determined by the exit server's application.

The relay server runs Realm; the exit server runs both Realm and your application.

An extra Realm-to-Realm encrypted transport layer is added between the two Realm instances.

The relay's encryption type, SNI domain, etc. must match the exit server's — otherwise decryption will fail

• Same port forwarding across multiple exit servers

• Frontend > Multiple Relays > Single Exit

• Round Robin mode (roundrobin)

Continuously rotates traffic across exit servers in the rule group

• IP Hash mode (iphash)

Routes traffic based on a hash of the source IP, ensuring the same client always hits the same exit server

• Weight = allocation probability

• Failover

When an exit is detected as down, it is temporarily removed from the load-balancing pool. Once it recovers, it is automatically added back.

Native Realm does not currently support failover.

• How the script implements it

1. systemd timer fires (every 4 seconds)
   ↓
2. Run health-check script
   ↓
3. Read rule configuration files
   ↓
4. TCP connectivity probe for each target
   ├── nc -z -w3 target port
   └── Fallback: telnet target port
   ↓
5. Atomically update health status file
   ├── Success: success_count++, fail_count=0
   └── Failure: fail_count++, success_count=0
   ↓
6. Evaluate state transitions
   ├── 2 consecutive failures → mark as DOWN
   └── 2 consecutive successes + 120 s cooldown (prevents flapping) → mark as UP
   ↓
7. If state changed, create an update marker file

Monitor IP changes in real time from the client: while ($true) { (Invoke-WebRequest -Uri 'http://ifconfig.me/ip' -UseBasicParsing).Content; Start-Sleep -Seconds 1 } or while true; do curl -s ifconfig.me; echo; sleep 1; done

Q: Does an MPTCP endpoint create a new virtual NIC? No. It tells the MPTCP protocol stack: this IP address is available for MPTCP connections on a specific path — data can flow through this IP and its associated NIC. This lets a single TCP connection use multiple network paths simultaneously.

Q: Why do you need to specify both IP and NIC? NIC: the kernel needs to know which physical interface this IP maps to for routing decisions. IP: the MPTCP stack needs to know which addresses it may use to establish subflows. 192.168.1.100 dev eth0 subflow fullmesh = MPTCP may establish subflows via eth0 at this IP 10.0.0.50 dev eth1 subflow fullmesh = MPTCP may establish subflows via eth1 at this IP

For finer-grained control, consider also configuring signal endpoints on the server side.

Two concepts that are easy to confuse.

In a nutshell

Port forwarding simply relays traffic from one port to another.

A chained (segmented) proxy splits the connection into two separate proxy hops — also called a two-tier proxy. (Detailed setup may be covered in a future guide.)

Each approach has its strengths — it depends on the use case | Note: some regional servers prohibit installing proxy software | That said, chained proxies can be very flexible in certain scenarios