Files
therealaleph 2c4c0a9a05 docs(tunnel-node): add Persian translation of README (#372)
Mirror of the English README with the same setup paths (Cloud Run /
Docker prebuilt / Docker source / direct binary), env-var table, and
protocol section, plus a Persian-language FAQ section answering the
specific questions users keep filing:

- bandwidth overhead (~25-30% from base64 + JSON envelope + v1.8.0
  random padding)
- whether all Android apps get tunneled (yes in Tunnel mode + VpnService;
  no in Proxy mode)
- realistic per-flow throughput (~50-200 KB/s, bound by Apps Script's
  per-roundtrip floor; horizontal-scale via more deployments)
- whether a VPS is required for Full mode (yes; not required for
  apps_script or google_only)
- which VPS to pick (Hetzner CX11 €4/mo for general use; Cloud Run
  free tier specifically for Iran users hit by #313 since destination
  IP stays Google-internal)

Adds an `MHRV_DIAGNOSTIC` env-var row to both the English and Persian
env-var tables — was added in v1.8.0 but never documented.

Closes #372.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-28 03:09:23 +03:00

131 lines
4.1 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Tunnel Node
> *Persian / فارسی: [README.fa.md](./README.fa.md)*
HTTP tunnel bridge server for MasterHttpRelayVPN "full" mode. Bridges HTTP tunnel requests (from Apps Script) to real TCP connections.
## Architecture
```
Phone → mhrv-rs → [domain-fronted TLS] → Apps Script → [HTTP] → Tunnel Node → [real TCP] → Internet
```
The tunnel node manages persistent TCP and UDP sessions. TCP sessions are real TCP connections to a destination server; UDP sessions are connected UDP sockets to one destination host:port. Data flows through a JSON protocol:
- **connect** — open TCP to host:port, return session ID
- **data** — write client data, return server response
- **udp_open** — open UDP to host:port, optionally send the first datagram
- **udp_data** — send one UDP datagram, or poll for returned datagrams when `d` is omitted
- **close** — tear down session
- **batch** — process multiple ops in one HTTP request (reduces round trips)
## Deployment
### Cloud Run
```bash
cd tunnel-node
gcloud run deploy tunnel-node \
--source . \
--region us-central1 \
--allow-unauthenticated \
--set-env-vars TUNNEL_AUTH_KEY=$(openssl rand -hex 24) \
--memory 256Mi \
--cpu 1 \
--max-instances 1
```
### Docker — prebuilt image (any VPS)
The fastest path. Pull a prebuilt image and run it; no Rust toolchain needed on the VPS.
```bash
# Generate a strong secret. Save it — you'll paste the same value into CodeFull.gs.
SECRET=$(openssl rand -hex 24)
echo "Your TUNNEL_AUTH_KEY: $SECRET"
# Pull + run.
docker run -d \
--name mhrv-tunnel \
--restart unless-stopped \
-p 8080:8080 \
-e TUNNEL_AUTH_KEY="$SECRET" \
ghcr.io/therealaleph/mhrv-tunnel-node:latest
```
The `:latest` tag tracks the most recent release. To pin a specific version (recommended for production), use `ghcr.io/therealaleph/mhrv-tunnel-node:v1.5.0` (or whatever release you're on). Image is available for `linux/amd64` and `linux/arm64`.
**docker-compose.yml** if you prefer:
```yaml
services:
tunnel:
image: ghcr.io/therealaleph/mhrv-tunnel-node:latest
restart: unless-stopped
ports:
- "8080:8080"
environment:
TUNNEL_AUTH_KEY: ${TUNNEL_AUTH_KEY}
```
Then `TUNNEL_AUTH_KEY=your-secret docker compose up -d`.
### Docker — build from source
If you'd rather build the image yourself (or add custom changes):
```bash
cd tunnel-node
docker build -t tunnel-node .
docker run -p 8080:8080 -e TUNNEL_AUTH_KEY=your-secret tunnel-node
```
### Direct binary
```bash
cd tunnel-node
cargo build --release
TUNNEL_AUTH_KEY=your-secret PORT=8080 ./target/release/tunnel-node
```
## Environment Variables
| Variable | Required | Default | Description |
|----------|----------|---------|-------------|
| `TUNNEL_AUTH_KEY` | Yes | `changeme` | Shared secret — must match `TUNNEL_AUTH_KEY` in CodeFull.gs |
| `PORT` | No | `8080` | Listen port (Cloud Run sets this automatically) |
## Protocol
### Single op: `POST /tunnel`
```json
{"k":"auth","op":"connect","host":"example.com","port":443}
{"k":"auth","op":"data","sid":"uuid","data":"base64"}
{"k":"auth","op":"close","sid":"uuid"}
```
### Batch: `POST /tunnel/batch`
```json
{
"k": "auth",
"ops": [
{"op":"data","sid":"uuid1","d":"base64"},
{"op":"udp_data","sid":"uuid2","d":"base64"},
{"op":"close","sid":"uuid3"}
]
}
{"r": [{...}, {...}, {...}]}
```
### Health check: `GET /health` → `ok`
## Performance: deployment count and pipeline depth
The mhrv-rs client runs a pipelined batch multiplexer in full mode. Each Apps Script round-trip takes ~2s, so the client fires multiple batch requests concurrently — the pipeline depth equals the number of configured script deployment IDs (minimum 2, no upper cap).
More deployments = more concurrent batches hitting the tunnel-node = lower per-session latency. With 6 deployments, a new batch arrives every ~0.3s instead of every 2s.
The tunnel-node itself is stateless per-request (sessions are keyed by UUID), so it handles concurrent batches naturally. For best results, deploy 312 Apps Script instances across separate Google accounts and list all their deployment IDs in the client config.