e2e: demux testcontainers exec stream, fix mtls proxy flags, add rtcp filter test

- Add ExecOutput helper to demultiplex the raw Docker exec stream so test
  output assertions see clean stdout+stderr instead of framed bytes.
- Wait for container readiness via exposed port or "listening on" log line
  when no ports are exposed.
- Use curl --proxy-* TLS options for the mTLS HTTPS-proxy test.
- Relax the http_cache first-request assertion (shared backend counter).
- Add gost#898 rtcp forwarder filter.host e2e test (multi-service one tunnel).
- Bump x to v0.15.7.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
ginuerzh
2026-08-26 22:27:52 +08:00
co-authored by Claude
parent ecf14b8459
commit 5e40415ac9
9 changed files with 216 additions and 28 deletions
+51
View File
@@ -0,0 +1,51 @@
# Internal client behind NAT: binds a reverse tunnel (tunnel.id matches the
# server's ingress endpoint) and forwards tunneled connections to per-hostname
# target services via filter.host node matching. There is deliberately NO
# fallback node — routing must come from the hostname.
#
# node example → tcp-echo:5678 (the real echo HTTP server)
# node other → tcp-echo:5679 (nothing listens here; must never be hit by
# example.local traffic)
services:
- name: service-0
addr: ":0"
handler:
type: rtcp
listener:
type: rtcp
chain: chain-0
forwarder:
nodes:
- name: example
addr: tcp-echo:5678
filter:
host: example.local
- name: other
addr: tcp-echo:5679
filter:
host: other.local
# Dummy TCP service on a fixed port: the rtcp reverse-tunnel listener binds
# remotely through the chain and opens no local port, so this gives the e2e
# harness a stable port to wait on.
- name: service-1
addr: ":8423"
handler:
type: http
listener:
type: tcp
chains:
- name: chain-0
hops:
- nodes:
- addr: gost-server:8421
connector:
type: tunnel
metadata:
tunnel.id: 6be39003-f4fa-49e4-a6ef-1997684d160e
dialer:
type: tcp
log:
level: debug
+25
View File
@@ -0,0 +1,25 @@
# Public-facing gost: tunnel handler with an ingress table mapping two
# hostnames to the SAME tunnel endpoint (multi-TCP-service sharing one tunnel
# ID — the gost#898 scenario). Requests to the HTTP entrypoint are routed by
# their Host header through the ingress table to the matching tunnel.
services:
- name: service-0
addr: ":8421"
handler:
type: tunnel
metadata:
entrypoint: ":8420"
ingress: ingress-0
listener:
type: tcp
ingresses:
- name: ingress-0
rules:
- hostname: example.local
endpoint: 6be39003-f4fa-49e4-a6ef-1997684d160e
- hostname: other.local
endpoint: 6be39003-f4fa-49e4-a6ef-1997684d160e
log:
level: debug
+3
View File
@@ -7,3 +7,6 @@ services:
sniffing: true
listener:
type: tcp
log:
level: debug