Files
MasterHttpRelayVPN-RUST/tunnel-node
dazzling-no-more 4d2ce91c04 fix(docker): cargo-chef so tunnel-node builds without BuildKit (#620, #1117)
Fixes #620 — `tunnel-node/Dockerfile` used BuildKit-only `RUN --mount=type=cache` directives, breaking on Cloud Run's `gcloud run deploy --source .` path (the underlying `gcr.io/cloud-builders/docker` builder doesn't enable BuildKit, and `--set-build-env-vars DOCKER_BUILDKIT=1` doesn't flip it on either).

Reworked to use **cargo-chef**: a dedicated planner stage emits `recipe.json` for dependency metadata, a `cargo chef cook` stage builds just the deps in their own Docker layer, the final build stage adds `src/` on top. Docker's regular layer cache handles dependency reuse — warm rebuilds where only `src/` changes still skip the slow crate compile.

## Changes (`tunnel-node/Dockerfile`-only)

- Dropped `# syntax=docker/dockerfile:1` parser directive and all `RUN --mount=type=cache,...` blocks
- Added cargo-chef multi-stage build (`chef` → `planner` → `builder`)
- Pinned `cargo-chef` to exact `0.1.77` with `--locked` for reproducible installs
- Bumped base from `rust:1.85-slim` → `rust:1.90-slim` (cargo-chef's transitive deps require rustc 1.86+; tunnel-node's `Cargo.toml` has no `rust-version` pin so the bump is internal-only)
- Removed `ARG TARGETPLATFORM` per-platform cache-id workaround — Docker's regular layer cache is already arch-scoped

## Non-changes (deliberate)

- `tunnel-node/Cargo.toml` left alone — the old Dockerfile comment claimed "matches MSRV in Cargo.toml" but no `rust-version` field actually exists. The Docker base bump is internal build-env, not a declared MSRV.
- Base image digest pinning left on tag refs — without Renovate/Dependabot to keep digests fresh, pinning trades automatic glibc/openssl/ca-certificates CVE patching for a reproducibility property this repo doesn't currently need.

## Verified locally

- `cd tunnel-node && cargo build --release`: clean (binary side unchanged)
- `cd tunnel-node && cargo test --release`: 36/36
- Local `docker build` couldn't run (daemon not started on the dev machine); the PR author's test plan documents successful build under classic Docker daemon.

Reviewed via Anthropic Claude.

Co-Authored-By: dazzling-no-more <noreply@github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 13:55:03 +03:00
..

Tunnel Node

Persian / فارسی: 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

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.

# 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:

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):

cd tunnel-node
docker build -t tunnel-node .
docker run -p 8080:8080 -e TUNNEL_AUTH_KEY=your-secret tunnel-node

Direct binary

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

{"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

{
  "k": "auth",
  "ops": [
    {"op":"data","sid":"uuid1","d":"base64"},
    {"op":"udp_data","sid":"uuid2","d":"base64"},
    {"op":"close","sid":"uuid3"}
  ]
}
 {"r": [{...}, {...}, {...}]}

Health check: GET /healthok

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.