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:** 🚧 EM CURSO — Access app + policy OK; **falta permissão Tunnel Edit** (token `cfut_llIr…` cria Access/DNS, não cria túnel)  
**Hostname:** `proxmox.itecnologys.com`  
**Access email:** `admin@itecnologys.com`  
**big1:** `cloudflared` **2026.9.1** já instalado

---


## Progresso implementação (2026-09-11)

| Item | Estado |
|------|--------|
| Hostname `proxmox.itecnologys.com` | ✅ escolhido |
| Email Access `admin@itecnologys.com` | ✅ |
| Token `cfut_llIr…` | ✅ Access + DNS; ❌ Tunnel Create |
| Access App `proxmox-big1-spec055` | ✅ id `a68244f9-b062-44a8-bb00-4b9d03eae8cc` |
| Access Policy allow email | ✅ |
| `cloudflared` no big1 | ✅ 2026.9.1 instalado |
| Túnel `big1-pve-admin` | ❌ API Authentication error (falta Account → Cloudflare Tunnel → **Edit**) |
| DNS CNAME túnel | ⏳ após criar túnel |
| Origin `127.0.0.1:8006` | ⏳ após connector |

**Desbloqueio:** no token CF adicionar **Account - Cloudflare Tunnel - Edit**, *ou* criar o túnel no dashboard Zero Trust e colar o **install token** (`eyJhIjoi…`).

## 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 | **`proxmox.itecnologys.com`** (confirmado Roger 2026-09-11) | Substitui A antigo → `100.90.196.58` (big casa) |
| Origin | `http://127.0.0.1:8006` | Túnel só no loopback; WAN `:8006` continua DROP |
| Auth | **Cloudflare Access** — Allow email **`admin@itecnologys.com`** | 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 Access: **`admin@itecnologys.com`** (confirmado 2026-09-11).  
3. Confirmar que Zero Trust / Team domain está activo na conta CF.  
4. **Hostname ainda por escolher** (ver secção abaixo).

**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 |

---

## Hostname (decisão pendente)

DNS actual (2026-09-11):

| Nome | Estado | Nota |
|------|--------|------|
| `big1.itecnologys.com` | A → `95.216.14.146` proxied | WAN pfSense — **conflito** |
| `proxmox.itecnologys.com` | A → `100.90.196.58` | Proxmox **casa (big)** — **conflito** |
| `pve.itecnologys.com` | livre | Recomendado |
| `proxmox-big1.itecnologys.com` | livre | Alternativa clara |

**Access email:** `admin@itecnologys.com` ✅  
**Hostname:** **`proxmox.itecnologys.com`** ✅ (Roger 2026-09-11; DNS actual A→big casa será substituído pelo CNAME do túnel)

### Bloqueio técnico (2026-09-11)

Tokens disponíveis no vault (`EYH0…` zone DNS, `225f77…` “API Key”) **não** autorizam:
- `GET /accounts/.../cfd_tunnel` → Authentication error  
- `GET /accounts/.../access/apps` → Authentication error  
- Global Key `225f77…` → formato inválido (6103)

**Para desbloquear**, Roger envia **uma** destas opções:

1. **Install token** do connector (Zero Trust → Networks → Tunnels → Create → `big1-pve-admin` → Docker/Debian copy token), formato:
   `eyJhIjoi...`  (comando: `sudo cloudflared service install <TOKEN>`)
2. **API Token** novo em dash.cloudflare.com → My Profile → API Tokens, permissões:
   - Account: Cloudflare Tunnel Edit  
   - Account: Access: Apps and Policies Edit  
   - Zone itecnologys.com: DNS Edit  

Depois disso o agente conclui: Tunnel config → origin `http://127.0.0.1:8006` → Access allow `admin@itecnologys.com` → DNS `proxmox` CNAME → testes.

---

## Checklist Roger (antes de executar)

- [ ] Escolher hostname (`pve.itecnologys.com` / `proxmox-big1…` / forçar `big1…` / `proxmox…`)  
- [x] Email Access: **`admin@itecnologys.com`**  
- [ ] Token CF Tunnel+Access **ou** install token do connector  
- [ ] Origin `http://127.0.0.1:8006` vs HTTPS + noTLSVerify  
- [ ] OK explícito para implementar  

---

## 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