obsidian-vault/Infra-Network/SPEC-055-PROXMOX-CF-TUNNEL-ACCESS-PLAN.md

# SPEC-055 — Plano: Proxmox WebUI via Cloudflare Tunnel + Access (big1)

**Criado:** 2026-09-11  
**Operador:** Roger  
**Status:** 📋 PLANO (não implementado — aguarda OK + token CF adequado)  
**Âmbito:** **só Proxmox WebUI** (`:8006`) no **big1**  
**Fora de âmbito (agora):** pfSense GUI/SSH · SSH do host `:4422`  
**Relacionado:** `SPEC-054` · `ACCESS-BIG1.md` · `SPEC-053` · (referência túneis no BIG) `RENTCHARGE_CLOUDFLARE_TUNNEL.md`

---

## Objectivo

Permitir abrir a WebUI do Proxmox **de qualquer sítio só com browser**, **sem** abrir `:8006` na WAN e **sem** exigir Tailscale nesse device — com **Cloudflare Access** à frente (Zero Trust).

Tailscale **mantém-se** como canal de emergência / Spec 054.

---

## Decisão de arquitectura

```text
Browser (mundo)
  → https://pve.itecnologys.com
  → Cloudflare Access (login obrigatório — email Roger)
  → Cloudflare Tunnel (cloudflared no big1)
  → http://127.0.0.1:8006   (pveproxy local; TLS termina no CF)
```

| Escolha | Valor | Porquê |
|---------|--------|--------|
| Hostname | **`pve.itecnologys.com`** | Novo; não reutilizar `big1.itecnologys.com` (hoje A→`95.216.14.146` proxied = WAN pfSense) |
| Origin | `http://127.0.0.1:8006` | Túnel só no loopback; WAN `:8006` continua DROP |
| Auth | **Cloudflare Access** (One-time PIN / IdP) | Sem Access = não publicar |
| Connector | `cloudflared` **systemd no big1** | Simples; um serviço dedicado `cloudflared-pve-admin` |
| Config | Remota no Zero Trust dashboard **ou** YAML local | Preferir dashboard CF (`config_src: cloudflare`) como no BIG |
| pfSense | **Não** neste SPEC | Fase 2 (SPEC futuro) |

---

## Pré-requisitos (bloqueadores)

1. **Token / permissões Cloudflare** com:
   - Account → Cloudflare Tunnel: Edit  
   - Account → Access: Apps & Policies Edit  
   - Zone `itecnologys.com` → DNS: Edit  
   - (O token DNS actual de zona **não basta** para criar túneis / Access.)
2. Email(s) autorizados (proposta): `admin@itecnologys.com` (+ outros que Roger indicar).
3. Confirmar que Zero Trust / Team domain está activo na conta CF.

**Não implementar** até Roger fornecer token (ou criar no dashboard) e confirmar o email Access.

---

## Passos de implementação (quando aprovado)

### A — Cloudflare Zero Trust (dashboard ou API)

1. Criar Tunnel nome: `big1-pve-admin`.
2. Public hostname:
   - Hostname: `pve.itecnologys.com`
   - Service: `https://127.0.0.1:8006` **ou** `http://127.0.0.1:8006`  
     - Preferir **HTTP** para origin (evita cert self-signed do PVE no conector); CF termina TLS no edge.  
     - Se PVE forçar HTTPS no loopback, usar `https://127.0.0.1:8006` + `noTLSVerify: true` no ingress.
3. DNS: CNAME `pve` → `<tunnel-id>.cfargotunnel.com` (proxied).
4. **Access Application**:
   - Application: `pve.itecnologys.com`
   - Policy: Allow → Emails → lista Roger  
   - Session duration: ex. 24h  
   - (Opcional) Country lock / Device posture — fase 2.

### B — big1 (host)

1. Instalar `cloudflared` (pacote oficial Cloudflare).
2. Unit: `cloudflared-pve-admin.service`  
   - Token do túnel (credentials JSON em `/etc/cloudflared/` mode 600).  
   - DNS resolv dedicado `1.1.1.1` / `8.8.8.8` (lição do BIG / Error 1033).  
   - Metrics em porta **única** (ex. `127.0.0.1:20245`) para não colidir com futuros túneis.
3. **Não** abrir iptables `:8006` à WAN — origin só `127.0.0.1`.
4. Validar: `curl -s http://127.0.0.1:20245/ready` e login Access → UI PVE.

### C — Documentação / Obsidian

1. Actualizar `ACCESS-BIG1.md` com URL canónica **browser remoto**: `https://pve.itecnologys.com` (Access).  
2. Manter Tailscale `https://100.116.138.100:8006/` como break-glass.  
3. Guardar tunnel id / policy id neste SPEC (sem secrets em claro se possível — path do credential file).

### D — Testes de aceitação

| Teste | Esperado |
|-------|----------|
| Sem login Access | Redirect / bloqueio CF Access |
| Email não autorizado | Deny |
| Email Roger + OTP | WebUI PVE |
| `https://95.216.14.162:8006` de fora | Continua **timeout/DROP** |
| Tailscale `:8006` | Continua **200** |
| Reboot big1 | `cloudflared-pve-admin` volta `active` |

---

## Riscos e mitigação

| Risco | Mitigação |
|-------|-----------|
| Túnel sem Access | **Proibido** — Access App obrigatório antes do DNS público |
| Comprometer email | 2FA no IdP / só emails da org; session curta |
| Error 1033 (túnel down) | Watchdog opcional (como RentCharge no BIG); Tailscale break-glass |
| Confundir com `big1.itecnologys.com` | Hostname dedicado `pve.` |
| Expor API PVE demais | Só WebUI; não publicar SSH via túnel neste SPEC |

---

## Estimativa

| Fase | Tempo |
|------|--------|
| Dashboard Tunnel + Access + DNS | ~20–40 min |
| cloudflared + systemd no big1 | ~15–30 min |
| Testes + docs Obsidian | ~15 min |

---

## Checklist Roger (antes de executar)

- [ ] Confirmar hostname `pve.itecnologys.com` (ou outro nome)  
- [ ] Confirmar email(s) Access  
- [ ] Fornecer token CF com Tunnel + Access **ou** criar túnel no dashboard e passar só o **install token** do connector  
- [ ] Confirmar: origin `http://127.0.0.1:8006` vs HTTPS + noTLSVerify  
- [ ] OK explícito para implementar (este documento é só plano)

---

## Fora de âmbito / fase 2

- pfSense via Tunnel (`firewall-admin…`) — nova SPEC  
- SSH Proxmox via Tunnel / Access — não recomendado; preferir Tailscale + `:4422`  
- Substituir Tailscale — **não**; coexistir  

---

## Referências

- `ACCESS-BIG1.md` · `SPEC-054-PROXMOX-PRIVATE-ADMIN.md`  
- Lições túnel: `RENTCHARGE_CLOUDFLARE_TUNNEL.md` (host BIG)  
- Cloudflare Zero Trust: Tunnel + Access Applications