80 lines
3.6 KiB
Markdown
80 lines
3.6 KiB
Markdown
# 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.
|