Record project continuation changes

2026-05-12 21:02:29 +03:00
parent 3059d1d7a3
commit 8f69d53193
339 changed files with 101111 additions and 1769 deletions
@@ -0,0 +1,79 @@
+# VPN baseline 0.2.87
+
+Date: 2026-05-05
+
+This document freezes the current near-working VPN state. Treat it as the
+rollback and comparison point before changing the Android VPN dataplane,
+gateway assignment, mesh route intents, or packet relay behavior.
+
+## Baseline components
+
+- Android client: `0.2.87` / version code `87`
+- APK path: `web-admin/deploy/html/downloads/rap-android-rdp-vpn-latest-release.apk`
+- Known-good APK path: `web-admin/deploy/html/downloads/rap-android-rdp-vpn-known-good-0.2.87.apk`
+- Versioned APK path: `web-admin/deploy/html/downloads/releases/0.2.87/rap-android-rdp-vpn-0.2.87-release.apk`
+- APK sha256: `bc44304658df7cd0ad627660c9e7b37af68910cdb13b310314ab99a049ff3b8d`
+- APK size: `1187103`
+- Backend image: `rap-backend:vpn-dataplane-contract-0.2.86`
+- Node/host agents: `0.2.86`
+- Cluster: `cfc0743d-d960-49fb-9de8-96e063d5e4aa`
+- VPN connection: `7cc94b0d-9cc2-4492-956a-cb0913b887e2` (`home-full-tunnel`)
+- Entry node: `home-1` (`8ad04829-cd30-4290-913d-1ce5c7ef7bb3`)
+- Exit node: `home-1` (`8ad04829-cd30-4290-913d-1ce5c7ef7bb3`)
+- DNS from exit side: `192.168.200.210`
+- Client tunnel: full tunnel, `0.0.0.0/0`, VPN address `10.77.0.2/24`
+- Active gateway lease: home-1, generation `8`
+- Active relay transport: `backend_http_packet_relay`
+
+## Current working behavior
+
+- General web traffic passes through the VPN.
+- External sites open through the configured home exit.
+- Telegram can connect, but initial connection may be delayed.
+- RDP can connect through the tunnel, but long-lived sessions can still drop.
+- Speed is the best observed so far, but speed-test pages may delay loading
+  their plugin/script parts.
+
+## Observed diagnostics
+
+Latest phone diagnostics for device `37574bd4-b944-440f-bbd5-87f2980d22c4`
+reported Android app version `0.2.87`.
+
+Packet relay counters showed both directions are active:
+
+- `client_to_gateway`: no queue drops observed, queue depth returned to `0`
+- `gateway_to_client`: queue depth was observed at `48-55`
+- `gateway_to_client`: `246` dropped packets were observed
+- Android side recorded downlink traffic, uplink traffic, and several uplink
+  sender errors
+- Android source validation dropped packets whose source was not the VPN
+  address; keep this guard enabled
+
+Interpretation: the active path is real and carries traffic, but downlink
+backpressure or Android TUN drain stalls can still interrupt long-lived TCP
+flows. This explains delayed Telegram startup, speed-test plugin loading
+delays, and RDP sessions that connect and later drop.
+
+## Guardrails
+
+- Do not reduce Android `TUN_WRITE_MAX_RETRIES` below `1000` without a
+  controlled regression test.
+- Do not relax Android VPN source-address validation.
+- Do not re-enable the home-1 `vpn_packets` fabric mesh route intent for this
+  connection until the Android client can intentionally use the fabric entry
+  path. The current working baseline relies on `backend_http_packet_relay`.
+- Do not change the active entry/exit away from home-1 without saving packet
+  counters before and after.
+- Do not change DNS away from `192.168.200.210` without checking full-tunnel
+  DNS and direct-IP traffic separately.
+- Keep the 0.2.87 APK available as a known-good rollback artifact.
+
+## Next safe work
+
+1. Stabilize `gateway_to_client` downlink queue draining and Android TUN write
+   backpressure.
+2. Add clearer per-flow counters for long-lived TCP flows such as RDP.
+3. Add a small repeatable smoke test: DNS, direct IP HTTP, 2ip.ru, Telegram-like
+   long connection, and RDP port reachability.
+4. Only after this baseline is stable, move Android entry traffic from backend
+   relay to fabric mesh.