Tailscale Access Guide¶

This guide covers how to access services via Tailscale VPN, providing secure access without requiring Proxmox port forwarding.

Overview¶

Tailscale is installed on the Docker VM (not the Proxmox host) and provides: - Secure VPN access using WireGuard protocol - Direct connectivity to services without port forwarding - MagicDNS for easy service discovery - Zero-trust networking with device authorization

Installation Status¶

Location: Installed in Docker VM (Ubuntu 24.04 LTS)
Node Name: dockerhost
Tailscale IP: 100.98.20.43
MagicDNS Domain: tail92c8e3.ts.net

Accessing Services¶

1. SSH Access¶

# Via Tailscale IP
ssh [email protected]

# Via MagicDNS name
ssh [email protected]

# Traditional method (requires port forwarding)
ssh [email protected]

2. Web Services¶

All web services remain accessible via their public URLs for end users: - https://supabase.rbnk.uk - https://litellm.rbnk.uk - https://openwebui.rbnk.uk

For admin access via Tailscale:

# Access any service directly via Tailscale IP
http://100.98.20.43  # Will hit Traefik

# With Host header for proper routing
curl -H "Host: supabase.rbnk.uk" http://100.98.20.43

3. Admin Interfaces¶

These interfaces are NOT exposed publicly but accessible via Tailscale:

Traefik Dashboard:

http://100.98.20.43:8080

Portainer (if installed):

http://100.98.20.43:9000

Direct PostgreSQL Access:

psql -h 100.98.20.43 -p 5432 -U postgres -d postgres

4. Docker Management¶

# SSH via Tailscale
ssh [email protected]

# Then use Docker commands normally
docker ps
docker compose -f /srv/dockerdata/traefik/docker-compose.yml logs -f

DNS Considerations with AdGuard¶

Using AdGuard as Tailscale DNS¶

Configure Tailscale to use AdGuard:

# Set AdGuard as the DNS server for Tailnet
tailscale up --accept-dns=false
# Then configure your system to use AdGuard at 100.98.20.43:53

Split DNS Configuration:
Configure Tailscale to handle *.ts.net domains
Let AdGuard handle all other DNS queries
Useful for internal service resolution

Custom Internal Domains:

# In AdGuard, create DNS rewrites:
# service.internal → 100.98.20.43
# db.internal → 100.98.20.43

Common Access Patterns¶

Development Workflow¶

Connect to Tailscale:
```
tailscale up
```
Access services directly:
SSH: ssh [email protected]
Traefik Dashboard: http://100.98.20.43:8080
Database: psql -h 100.98.20.43 -p 5432
No port forwarding needed - Everything works through Tailscale!

Production Access¶

End users: Continue using public URLs (*.rbnk.uk)
Admins: Use Tailscale for secure management access
Monitoring: Access internal dashboards via Tailscale

Emergency Access¶

If Tailscale is down: 1. SSH is still available via public IP (port 22 is forwarded) 2. Web services remain accessible via public URLs 3. Use SSH tunneling for admin interfaces:

ssh -L 8080:localhost:8080 [email protected]
# Then access http://localhost:8080 for Traefik dashboard

Security Benefits¶

1. Reduced Attack Surface¶

No public admin interfaces: Traefik dashboard, Portainer, etc. are not exposed
No database port exposure: PostgreSQL remains completely private
Selective access: Only authorized devices can connect

2. Zero-Trust Architecture¶

Device authorization: Each device must be approved to join Tailnet
User authentication: Tailscale identity tied to email/SSO
Granular ACLs: Control which devices can access which services

3. Encrypted Communications¶

WireGuard protocol: Modern, fast, secure VPN technology
End-to-end encryption: All traffic encrypted between devices
Perfect forward secrecy: Compromised keys don't affect past traffic

4. Audit Trail¶

Connection logs: Track all Tailscale connections
Device inventory: See all authorized devices
Access patterns: Monitor usage and detect anomalies

Best Practices¶

1. Regular Access¶

Use Tailscale for all administrative tasks
Keep public ports to minimum (80, 443, 22)
Document which services require public access

2. Service Configuration¶

# Example: Expose service only on Tailscale interface
services:
  admin-panel:
    ports:
      - "100.98.20.43:9000:9000"  # Only accessible via Tailscale

3. Backup Access Methods¶

Maintain SSH access via public IP for emergencies
Document alternative access methods
Test recovery procedures regularly

4. DNS Configuration¶

Use MagicDNS for convenience
Configure custom domains in AdGuard for services
Document DNS dependencies

Troubleshooting¶

Cannot Connect via Tailscale¶

Check Tailscale status:
```
tailscale status
```
Verify device authorization:
```
tailscale netcheck
```
Check if service is listening:
```
ss -tlnp | grep :8080
```

DNS Resolution Issues¶

Test MagicDNS:
```
nslookup dockerhost.tail92c8e3.ts.net
```
Check DNS configuration:
```
tailscale dns
```
Verify AdGuard is running:
```
docker ps | grep adguard
```

Stale Tailscale DNS in Containers¶

Problem: After disconnecting Tailscale, Docker containers may retain the old Tailscale DNS resolver (100.100.100.100) in their /etc/resolv.conf, causing DNS resolution failures even when the host network is fine.

Symptoms: - Container logs show "Temporary failure in name resolution" - External API calls fail within containers - Host can resolve DNS fine, but containers cannot

Diagnosis:

# Check which containers have stale Tailscale DNS
for c in $(docker ps -q); do
  if docker exec $c grep -q "100.100.100.100" /etc/resolv.conf 2>/dev/null; then
    echo "Stale DNS: $(docker inspect --format '{{.Name}}' $c)"
  fi
done

# Check a specific container
docker exec <container_name> cat /etc/resolv.conf

Solution: Restart affected containers to get fresh DNS configuration from Docker:

# Restart specific container
docker restart <container_name>

# Or restart entire stack
docker compose -f <service>/docker-compose.yml restart

Prevention: When disconnecting Tailscale, consider restarting long-running containers or using Docker's DNS configuration options:

# In docker-compose.yml - explicit DNS servers
services:
  myservice:
    dns:
      - 1.1.1.1
      - 8.8.8.8

Note: This issue typically occurs when Tailscale has been connected for an extended period and then disconnected. Containers that were started while Tailscale was active will have inherited its DNS configuration.

Service Not Accessible¶

Verify service is running:
```
docker ps
```
Check if bound to correct interface:
```
docker port <container_name>
```
Test local connectivity first:
```
curl http://localhost:8080
```

Advanced Configuration¶

Tailscale ACLs¶

Example ACL for fine-grained access control:

{
  "acls": [
    {
      "action": "accept",
      "users": ["[email protected]"],
      "ports": ["*:*"]
    },
    {
      "action": "accept", 
      "users": ["[email protected]"],
      "ports": ["dockerhost:22", "dockerhost:80", "dockerhost:443"]
    }
  ]
}

Exit Node Configuration¶

Use the Docker VM as an exit node for full traffic routing:

# Enable exit node
tailscale up --advertise-exit-node

# On client device
tailscale up --exit-node=dockerhost

Subnet Routing¶

Access Docker networks directly:

# Advertise Docker subnets
tailscale up --advertise-routes=172.18.0.0/16,172.19.0.0/16

Summary¶

Tailscale provides a secure, convenient way to access your infrastructure without the complexity and security risks of port forwarding. By running Tailscale on the Docker VM, you get:

Direct access to all services without Proxmox configuration
Enhanced security through zero-trust networking
Simplified operations with no port forwarding maintenance
Better monitoring with comprehensive access logs

This approach keeps public-facing services accessible to end users while providing administrators with secure, direct access to all infrastructure components.