TC-85: tunnel relay MVP -- remote reachability for local nodes (+ TC-244 batch)

[samgbafa]

What

TC-85 (tunnel relay MVP): nodes open one outbound WebSocket to wss://api.tinycloud.link/v1/tunnel/<name>, authenticate with the same signed-payload scheme as every other write (action: "tunnel", subject must own the name, strictly-increasing sequence), and the relay proxies HTTPS requests for https://<name>.tinycloud.link down the socket as JSON request/response frames.

• src/tunnel/protocol.ts — HTTP-over-WS framing (request/requestBody/response/responseBody/error, base64 bodies, multiplexed by request id). Source of truth for the Rust node client; the README documents the full contract (frames, auth, close codes, lifecycle).
• src/tunnel/upgrade.ts — WS handshake: 5s auth timeout, ownership + signature verification, sequence bump before going live (same bump-before-side-effect pattern as the cert flow), ping/pong heartbeat with dead-peer termination.
• src/tunnel/registry.ts — one live socket per name, newest wins (a reconnecting node evicts its own stale socket, close code 4410).
• src/tunnel/host-router.ts — Host-header routing middleware: API_HOSTNAME (default api.tinycloud.link) gets the normal /v1 API, any other <name>.tinycloud.link host is proxied through its tunnel (502 no tunnel / 504 timeout). Opt-in via ServerConfig.tunnelRegistry; existing behavior is unchanged when unset.

TC-244 batch:

• ECDSA P-256 CSRs are now accepted: assertCsrMatchesDomain parses with @peculiar/x509 instead of node-forge (forge cannot parse EC CSRs at all — "OID is not RSA"). RSA still works; both are tested end-to-end through the fake ACME client.
• README documents the bump-before-ACME sequence semantics (why the bump precedes the slow, non-idempotent ACME round trip, and the retry-with-higher-sequence consequence).

Ingress/TLS finding (design honesty)

Per-name relay certificates are a dead end in the Phala deployment model: dstack-ingress (HAProxy L4) terminates all of the CVM's :443 with certificates it obtained itself at bootstrap — this process never sees the TLS handshake and has no way to serve certs it might obtain. Shipped design instead: one wildcard cert via DOMAIN=*.tinycloud.link on dstack-ingress (native wildcard DNS-01 support) + Host-header routing behind it. Open item before deploy: dstack-ingress's wildcard mode requires dstack-gateway wildcard TXT resolution (dstack#545) — must be verified on a staging CVM; fallback is DOMAIN=api.tinycloud.link (API unaffected, tunnels dark). Details in README "Ingress and TLS for tunnels".

Not in this PR

• No deploy. The running api.tinycloud.link service is untouched; deploying the tunnel-enabled image (and the wildcard DNS record + gateway verification) is a separate reviewed step.
• Node-side (Rust) client — separate ticket, consumes the documented contract.

Validation

• tsc --noEmit clean
• 66/66 tests pass (was 51; +9 tunnel tests: auth ownership/signature/sequence, framing roundtrip vs a mock ws node, newest-socket-wins; +3 tunnel-auth unit tests; +3 ECDSA CSR tests)
• No live network in tests (in-memory DNS/ACME/name stores, real WS over loopback)

[samgbafa]

Review round complete: security-review fixes applied

Addressed all four items from the round-1 security review, pushed as two commits (6e45067, 7d7834d) on feat/tunnel-relay.

1. Body/frame size limits — src/tunnel/host-router.ts's readLimitedBody streams and caps proxied request bodies (413 past the cap, no unbounded buffering); src/tunnel/proxy.ts now tracks accumulated response-body bytes and aborts with 502 + an error frame to the node past the cap. Default 25MB both directions, overridable via TUNNEL_MAX_BODY_BYTES. The relay's WebSocketServer now sets maxPayload (MAX_FRAME_PAYLOAD_BYTES, 1MB); request bodies are chunked into <=256KB requestBody frames (BODY_CHUNK_BYTES) so the relay's own sends respect it. Also added a ws 'error' listener in upgrade.ts — without one, a maxPayload violation's unhandled error event crashes the whole process (found this the hard way: it was an uncaught exception in the new maxPayload test before the fix).

2. Rate/connection limiting — src/tunnel/upgrade.ts (new src/tunnel/rate-limit.ts) now enforces a per-IP connection-attempt limiter (30/min), a per-name churn limiter (10/min), and a global concurrent-tunnel cap (1000, env TUNNEL_MAX_CONCURRENT), all checked in the raw HTTP upgrade handler — before the WS handshake and before authenticate()'s nameStore.get Postgres read. Deliberately in-memory rather than reusing the Postgres-backed cert rate limiter: these are short per-minute windows checked on every single upgrade attempt, and adding a Postgres round trip there would defeat the point.

3. Headers as ordered pairs — TunnelRequestFrame/TunnelResponseFrame.headers changed from Record<string,string> to Array<[string,string]> (breaking protocol change; no version marker exists to bump, and nothing consumes the protocol yet per the PR description). host-router.ts rebuilds the outgoing client Response via repeated Headers.append() calls so multiple Set-Cookie entries survive end to end. Covered by an explicit two-Set-Cookie roundtrip test.

4. README — documented shared per-name sequence coordination across claim/cert/delete/tunnel, max frame/body sizes and the chunking contract, unknown-id frames being ignored, and the pair-array header format.

Validation: tsc --noEmit clean; 75/75 tests pass (66 + 9 new covering each fix: request/response body caps, multi-chunk body reassembly, WS maxPayload enforcement, per-IP/per-name/global connection limits, header-pair passthrough, duplicate-Set-Cookie roundtrip).