98 lines
3.6 KiB
Markdown
98 lines
3.6 KiB
Markdown
# Remote Access V1 Proposal
|
|
|
|
## Goal
|
|
Create a simple, production-sane remote access model that is easy to understand, easy to operate, and does not depend on four overlapping paths.
|
|
|
|
## Current problem
|
|
Remote access is currently spread across:
|
|
- Tailscale
|
|
- ZeroTier
|
|
- Pangolin
|
|
- Cloudflare reverse proxy / Zero Trust tunnel
|
|
|
|
This creates overlap, unclear defaults, and more failure modes than necessary.
|
|
|
|
## V1 recommendation
|
|
Use **two lanes only**:
|
|
|
|
1. **Admin / maintenance lane:** Tailscale
|
|
2. **User / app access lane:** one public reverse-proxy path, preferably Cloudflare tunnel for now
|
|
|
|
## What to do with the current tools
|
|
- **Keep Tailscale** as the default admin path
|
|
- **Deprecate ZeroTier** unless a concrete need appears that Tailscale cannot solve
|
|
- **Do not make Pangolin the primary edge yet**
|
|
- **Keep Cloudflare tunnel / reverse proxy** as the primary app-access layer for V1
|
|
|
|
## Why this is the right V1
|
|
- Tailscale is strong for operator access, SSH, dashboards, and maintenance
|
|
- Cloudflare is strong for controlled public exposure and gradual publishing of apps
|
|
- Pangolin may still be interesting later, but using it now as both edge and auth adds moving parts before the platform is stable
|
|
- ZeroTier is redundant unless it solves a specific problem better than Tailscale in your setup
|
|
|
|
## V1 policy
|
|
### Lane 1 — admin / maintenance
|
|
Use Tailscale for:
|
|
- SSH / terminal access
|
|
- Grafana
|
|
- OpenClaw admin access
|
|
- internal dashboards
|
|
- Proxmox management
|
|
- Home Assistant admin
|
|
- anything that should not be publicly exposed
|
|
|
|
### Lane 2 — app access
|
|
Use Cloudflare tunnel / reverse proxy for:
|
|
- selected apps intended for normal browser access
|
|
- family / friend access later
|
|
- controlled public-facing entrypoints
|
|
|
|
### Lane 3 — not part of V1
|
|
- Pangolin as primary platform edge
|
|
- ZeroTier as parallel mesh
|
|
|
|
These should stay out of the critical path for now.
|
|
|
|
## Identity recommendation
|
|
Do **not** introduce Authentik as a broad central dependency yet.
|
|
First simplify access paths.
|
|
Then, once the app map is stable, decide whether Authentik should sit behind Cloudflare, alongside it, or only protect selected internal apps.
|
|
|
|
## Backup / off-site implication
|
|
The parents' Synology NAS is a strong future off-site backup target.
|
|
That is strategically more valuable right now than adding another access product.
|
|
|
|
## Suggested architecture
|
|
```mermaid
|
|
flowchart LR
|
|
Admin[Claudio admin access] --> TS[Tailscale]
|
|
Users[Claudio / family / friends app access] --> CF[Cloudflare tunnel / reverse proxy]
|
|
|
|
TS --> PMX[Proxmox host and internal services]
|
|
TS --> DELL[Debian backup / Home Assistant host]
|
|
TS --> NAS[Synology production services]
|
|
TS --> VPS[Netcup VPS]
|
|
|
|
CF --> NAS
|
|
CF --> PMX
|
|
CF --> VPS
|
|
|
|
NAS -. backups later .-> PNAS[Parents' Synology NAS]
|
|
DELL -. backup orchestration .-> PNAS
|
|
```
|
|
|
|
## Concrete V1 rules
|
|
- Every service must have one **primary access path**
|
|
- If a service is admin-only, it should default to Tailscale-only
|
|
- If a service is user-facing, expose it through Cloudflare only if there is a clear reason
|
|
- Avoid exposing the same app through multiple remote-access products unless documented
|
|
- Record every published service in the architecture notes
|
|
|
|
## First implementation steps
|
|
1. Create a service inventory with one owner host and one primary access path per service
|
|
2. Decide which current services are strictly internal/admin vs user-facing
|
|
3. Remove ZeroTier from the default plan and treat Pangolin as experimental only
|
|
|
|
## Opinion
|
|
The cleanest V1 is not the fanciest one. It is the one you can explain on one page and recover under stress.
|