initial

drafts/20260616_rssh_routed_egress.txt

@@ -0,0 +1,31 @@
+RSSH routed egress (dev-only VPN over SSH) — source draft
+R0-pre
+severity: low
+state: postponed (finish WireGuard track first)
+
+Problem:
+- PO asked whether RSSH can get a system-wide VPN provider that routes part or all device traffic through the RSSH tunnel (split or full), dev settings only.
+- Today RSSH is reverse SSH (-R) for operator → device shell/SFTP; no VpnService, no WAN egress change.
+- WireGuard already supports hub-only / full-tunnel + all-apps / this-app-only via RemoteAccessVpnRouting.
+
+Why consider RSSH routing at all:
+- TCP 443 only path (no UDP WG) in hostile networks.
+- Single transport for alpha if WG UDP blocked.
+
+Why defer:
+- Alpha RSSH goal = no VPN permission, no key icon, file/shell access.
+- WG full-tunnel solves "egress via hub" for lab now.
+- RSSH+VPN is new subsystem (SOCKS or tun2socks + VpnService + bastion NAT), not a setting.
+
+Options sketched:
+A) Use WG full-tunnel (existing) — recommended near-term for routing.
+B) RSSH + ssh -D SOCKS + VpnService + tun2socks — dev experimental.
+C) ssh -w tun both ends — heavy, skip.
+D) Hybrid: WG packets + RSSH operator — already in proposal doc.
+
+DR should decide: postpone until WG E2E closed; if revived, dev-only sub-mode under RSSH.
+
+Open for PO:
+- Is TCP-only routing worth duplicating WG?
+- Accept VPN icon/consent again for RSSH-routed mode?
+- Bastion egress NAT policy (Minsk) for dev traffic?