Torjus Håkestad
870fb3e532
All checks were successful
Run nix flake check / flake-check (push) Successful in 2m4s
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
123 lines
4.7 KiB
Markdown
123 lines
4.7 KiB
Markdown
# Remote Access to Homelab Services
|
|
|
|
## Status: Planning
|
|
|
|
## Goal
|
|
|
|
Enable remote access to some or all homelab services from outside the internal network, without exposing anything directly to the internet.
|
|
|
|
## Current State
|
|
|
|
- All services are only accessible from the internal 10.69.13.x network
|
|
- Exception: jelly01 has a WireGuard link to an external VPS
|
|
- No services are directly exposed to the public internet
|
|
|
|
## Constraints
|
|
|
|
- Nothing should be directly accessible from the outside
|
|
- Must use VPN or overlay network (no port forwarding of services)
|
|
- Self-hosted solutions preferred over managed services
|
|
|
|
## Options
|
|
|
|
### 1. WireGuard Gateway (Internal Router)
|
|
|
|
A dedicated NixOS host on the internal network with a WireGuard tunnel out to the VPS. The VPS becomes the public entry point, and the gateway routes traffic to internal services. Firewall rules on the gateway control which services are reachable.
|
|
|
|
**Pros:**
|
|
- Simple, well-understood technology
|
|
- Already running WireGuard for jelly01
|
|
- Full control over routing and firewall rules
|
|
- Excellent NixOS module support
|
|
- No extra dependencies
|
|
|
|
**Cons:**
|
|
- Hub-and-spoke topology (all traffic goes through VPS)
|
|
- Manual peer management
|
|
- Adding a new client device means editing configs on both VPS and gateway
|
|
|
|
### 2. WireGuard Mesh (No Relay)
|
|
|
|
Each client device connects directly to a WireGuard endpoint. Could be on the VPS which forwards to the homelab, or if there is a routable IP at home, directly to an internal host.
|
|
|
|
**Pros:**
|
|
- Simple and fast
|
|
- No extra software
|
|
|
|
**Cons:**
|
|
- Manual key and endpoint management for every peer
|
|
- Doesn't scale well
|
|
- If behind CGNAT, still needs the VPS as intermediary
|
|
|
|
### 3. Headscale (Self-Hosted Tailscale)
|
|
|
|
Run a Headscale control server (on the VPS or internally) and install the Tailscale client on homelab hosts and personal devices. Gets the Tailscale mesh networking UX without depending on Tailscale's infrastructure.
|
|
|
|
**Pros:**
|
|
- Mesh topology - devices communicate directly via NAT traversal (DERP relay as fallback)
|
|
- Easy to add/remove devices
|
|
- ACL support for granular access control
|
|
- MagicDNS for service discovery
|
|
- Good NixOS support for both headscale server and tailscale client
|
|
- Subnet routing lets you expose the entire 10.69.13.x network or specific hosts without installing tailscale on every host
|
|
|
|
**Cons:**
|
|
- More moving parts than plain WireGuard
|
|
- Headscale is a third-party reimplementation, can lag behind Tailscale features
|
|
- Need to run and maintain the control server
|
|
|
|
### 4. Tailscale (Managed)
|
|
|
|
Same as Headscale but using Tailscale's hosted control plane.
|
|
|
|
**Pros:**
|
|
- Zero infrastructure to manage on the control plane side
|
|
- Polished UX, well-maintained clients
|
|
- Free tier covers personal use
|
|
|
|
**Cons:**
|
|
- Dependency on Tailscale's service
|
|
- Less aligned with self-hosting preference
|
|
- Coordination metadata goes through their servers (data plane is still peer-to-peer)
|
|
|
|
### 5. Netbird (Self-Hosted)
|
|
|
|
Open-source alternative to Tailscale with a self-hostable management server. WireGuard-based, supports ACLs and NAT traversal.
|
|
|
|
**Pros:**
|
|
- Fully self-hostable
|
|
- Web UI for management
|
|
- ACL and peer grouping support
|
|
|
|
**Cons:**
|
|
- Heavier to self-host (needs multiple components: management server, signal server, TURN relay)
|
|
- Less mature NixOS module support compared to Tailscale/Headscale
|
|
|
|
### 6. Nebula (by Defined Networking)
|
|
|
|
Certificate-based mesh VPN. Each node gets a certificate from a CA you control. No central coordination server needed at runtime.
|
|
|
|
**Pros:**
|
|
- No always-on control plane
|
|
- Certificate-based identity
|
|
- Lightweight
|
|
|
|
**Cons:**
|
|
- Less convenient for ad-hoc device addition (need to issue certs)
|
|
- NAT traversal less mature than Tailscale's
|
|
- Smaller community/ecosystem
|
|
|
|
## Key Decision Points
|
|
|
|
- **Static public IP vs CGNAT?** Determines whether clients can connect directly to home network or need VPS relay.
|
|
- **Number of client devices?** If just phone and laptop, plain WireGuard via VPS is fine. More devices favors Headscale.
|
|
- **Per-service vs per-network access?** Gateway with firewall rules gives per-service control. Headscale ACLs can also do this. Plain WireGuard gives network-level access with gateway firewall for finer control.
|
|
- **Subnet routing vs per-host agents?** With Headscale/Tailscale, can either install client on every host, or use a single subnet router that advertises the 10.69.13.x range. The latter is closer to the gateway approach and avoids touching every host.
|
|
|
|
## Leading Candidates
|
|
|
|
Based on existing WireGuard experience, self-hosting preference, and NixOS stack:
|
|
|
|
1. **Headscale with a subnet router** - Best balance of convenience and self-hosting
|
|
2. **WireGuard gateway via VPS** - Simplest, most transparent, builds on existing setup
|