diff --git a/HISTORY/2026-09-28_vpn-transit-213-vultr.md b/HISTORY/2026-09-28_vpn-transit-213-vultr.md index 3dfaa86..38f4c80 100644 --- a/HISTORY/2026-09-28_vpn-transit-213-vultr.md +++ b/HISTORY/2026-09-28_vpn-transit-213-vultr.md @@ -94,3 +94,73 @@ No Vultr IP deletion was performed in this work. The secondary address was only ## Important limitations The measurements prove the route worked at test time. They do not guarantee permanent availability: NUBES, Vultr, upstream providers, or network filtering policy can change independently. + +## Later the same day: optimisation attempt and its outcome + +### Automation created + +A reusable, idempotent tool was created outside this repository: + +```text +/home/naeel/nubes/HowTo/vpn-transit/vpn-setup.sh check | apply | verify | passthrough | verify-passthrough | client-config | rollback +/home/naeel/nubes/HowTo/vpn-transit/client-config.json generated client config (chmod 600, contains UUID) +/home/naeel/nubes/HowTo/vpn-transit/README.md description, measurements, rollback +/home/naeel/nubes/HowTo/howto-vpn-transit-213-vultr-2026-09-28.md full report +``` + +Every change is preceded by a timestamped backup and followed by a config test (`nginx -t`, `xray run -test`) with automatic rollback on failure. + +### Changes applied + +| Host | File | Change | Backup | +|---|---|---|---| +| 213 | `/etc/nginx/sites-available/check.kube5s.ru` | `proxy_buffering off;` added inside `location /ws`, marked `# vpn-transit: proxy_buffering off` | `check.kube5s.ru.bak.1790601681` | +| Vultr | `/etc/v2ray-agent/xray/conf/00_log.json` | `loglevel`: `debug` → `warning` (log had grown to 76 MB), service restarted | `00_log.json.bak.1790601723` | +| 213 | `/usr/local/sbin/vpn-transit-dnat.sh`, `/etc/systemd/system/vpn-transit-dnat.service` | DNAT `213:8443 → 95.179.252.111:443` plus FORWARD rules, enabled at boot | none (rules tagged `vpn-transit`) | + +### Measurements after the changes + +- Outbound IP: `95.179.252.111` +- Throughput: `5.6–7.3 MiB/s` (10 MiB in 1.4–1.9 s) +- Per-connection latency: `0.23–0.37 s` +- WebSocket upgrade success rate on 213: `14569 / 14573` (99.97%), one `upstream timed out` error + +### Hypothesis that was disproved: mux + +`verify` compared the tunnel with and without `"mux": {"enabled": true, "concurrency": 8}`: + +| Mode | 10 MiB download | Connection behaviour | +|---|---|---| +| without mux | 7.32 MiB/s in 1.43 s | stable | +| with mux | **0 B/s, failed** | after 4 requests connections hang for 15 s | + +Conclusion: mux is harmful in the `VLESS + WebSocket behind nginx` combination. It is excluded from the client config. The test remains in the script for re-checking on future Xray versions. + +### Optimisation that could not be delivered: removing the second TLS layer + +The intended speed fix was to drop one TLS handshake (`client → 213`, then `213 → Vultr`) by forwarding TCP straight through to Vultr. + +- `ngx_stream_module.so` is absent on 213, so nginx cannot do SNI-based passthrough without installing `libnginx-mod-stream`. +- Kernel-level DNAT on port 8443 was installed instead, but **does not work**: from outside, port 8443 returns `Connection refused` and the DNAT counter on 213 stays at 0 packets — traffic never reaches the machine. +- Cause: the provider firewall in front of 213 exposes only ports 80 and 443. Measured from `3060`: `3001, 8080, 8443, 8766, 8767, 8888, 18080, 40229` are closed. +- Therefore the second TLS layer can only be removed after the provider opens an additional port. The rules are already installed and would start working immediately once that happens. + +### Errors made during this work + +1. **Recommended `mux` before measuring it.** The recommendation was given as the main fix and was later disproved by measurement. Correct order: measure first, recommend after. +2. **Changed server configuration before measuring the benefit.** `proxy_buffering off` has no effect on a WebSocket connection after the `101 Switching Protocols` upgrade, and `loglevel` affects only log size. Neither change improves speed, so from the user's point of view nothing changed. +3. **Changed the client config to port 8443 before verifying the port was reachable from outside.** The config was regenerated back to port 443 immediately. + +### Net result for the user + +Nothing changed for the client: address `5.172.178.213`, port `443`, SNI `check.kube5s.ru`, path `/ws` and the UUID are unchanged, and the previously used link still works. No client-side reconfiguration is required. + +The only actionable finding is client-side: the Xray log on Vultr contained **331** `connect: connection refused` to `127.0.0.1:45987`, i.e. the client requested a loopback address, plus Telegram advertises AAAA records while the tunnel is IPv4-only. The generated `client-config.json` addresses both (remote DNS, `queryStrategy: UseIPv4`), but the device itself was not modified. + +Separately: **10170** `reset by peer` entries to `157.240.0.13` (Meta infrastructure) are blocking by those sites, unrelated to the transit. + +### Scope audit (this action) + +- Repository files changed: this document only. `git status` also showed unrelated pre-existing changes (`DEV_STAND/FullPipe/shturval.tf` deletion, `TMP/*` files) that were **not** touched or committed. +- Server-side files changed: as listed in the table above. +- Temporary test files on 3060: `/tmp/xray-test/*` (no permanent service installed).