mirror of
https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
synced 2026-05-19 08:04:39 +03:00
vahidlazio
b73bbe2106
Adds a new `mode: full` that tunnels ALL traffic end-to-end through Apps Script → a remote tunnel node. Browser does TLS directly with the destination. No MITM, no CA installation needed on the client device. Ships as part of the 3-PR series: #93 (tunnel-node service + CodeFull.gs, merged) + this (Rust-side Mode::Full + batch tunnel client) + #95 (Android UI dropdown, now rolled into this PR post-rebase). ### Architecture - Client → mhrv-rs → script.google.com (Apps Script fetch) → tunnel-node on user's VPS → real destination - Apps Script is the transport to reach the VPS; works even when the ISP blocks direct VPS IPs - Batch multiplexer collects data from all active sessions and ships one Apps Script request per tick ### Safety properties of this merge - AppsScript + GoogleOnly dispatch paths are **unchanged**; Full mode is an additive branch at the top of `dispatch_tunnel`. - `tunnel_client.rs` is a new isolated module (387 LOC). - `tunnel_request()` is a new method on `DomainFronter`, no change to `relay()` / `relay_parallel_range()`. - Config: additive `Mode::Full` variant + validation tests (2 new); existing validation rules untouched. - Local build: clean compile. `cargo test --quiet`: 75 passed (73 → 75 with 2 new config tests). ### Closes Unblocks the feature requested in #61, #69, #100, #105, #110, #111, #113, #116. ### Testing vahidlazio has iterated on prior review feedback. End-to-end testing with a real tunnel-node deployment will follow post-merge from @Feiabyte (volunteered in #61). Post-merge CI will exercise compile + full test matrix across all targets; any regression caught there gets a fast-follow fix.
90 lines
2.7 KiB
Markdown
90 lines
2.7 KiB
Markdown
# Tunnel Node
|
||
|
||
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 sessions. Each session is a real TCP connection to a destination server. Data flows through a JSON protocol:
|
||
|
||
- **connect** — open TCP to host:port, return session ID
|
||
- **data** — write client data, return server response
|
||
- **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 (any VPS)
|
||
|
||
```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":"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 (clamped 2..12).
|
||
|
||
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 3–12 Apps Script instances across separate Google accounts and list all their deployment IDs in the client config.
|