# Decision: Capa de red y conectividad (punto 4)

## Contexto

El PBS actual tiene el puerto 8007 abierto a internet para recibir backups. A 100+ servidores, cada servicio de backup deberia ir por VPN privada. Ademas, ya existe PowerDNS y Traefik en uso. La capa de red organiza como se comunican los servidores entre si y con el exterior de forma segura.

Infraestructura fisica: servidores con 2 interfaces de red (IP publica + vRack OVH 25Gbps). Todo el direccionamiento interno sera IPv6 (ULA).

3 subcapas:
- 4.1 VPN y acceso seguro entre servidores
- 4.2 DNS y service discovery
- 4.3 Proxy inverso y balanceo

---

## 4.1 VPN y acceso seguro entre servidores

### El problema

- PBS:8007 expuesto a internet para recibir backups de PVE remotos
- Trafico de backup viaja por internet sin cifrado adicional (solo TLS de PBS)
- vRack de OVH conecta servidores pero sin cifrado ni autenticacion (L2 privada, no segura)
- Sin VPN, cada servicio nuevo expuesto requiere abrir puertos en firewall publico
- La superficie de ataque crece con cada puerto abierto
- Modelo actual de gateways: 1 VM gateway por cliente (NAT + WG), no escala

### Opciones evaluadas

| Herramienta | Modelo | Recursos | Complejidad | Estado |
|-------------|--------|----------|-------------|--------|
| **WireGuard** | Punto a punto, hub-spoke | Kernel module, ~0 overhead | Baja (config manual, Ansible) | **ELEGIDA** |
| **Tailscale** | Mesh VPN, SaaS | Agente ligero | Muy baja | Descartada (SaaS, dependencia externa) |
| **Headscale** | Tailscale self-hosted | ~200MB RAM | Baja-media | Posible evolucion futura si escala |
| **Nebula** | Overlay con certificados | Agente ligero | Media | Descartada (menor comunidad) |
| **Netbird** | Mesh con SSO | ~300MB RAM | Media | Descartada (muy joven) |
| **BGP/OSPF entre hubs** | Routing dinamico | FRRouting | Alta | Descartado (overengineering a esta escala) |

### DECISION 4.1 (confirmada)

#### WireGuard + wgdashboard + IPv6 ULA

Todo el direccionamiento WireGuard en IPv6 ULA (fd00::/8). No ruteable a internet, privado por diseño.

#### Tres roles de WireGuard

**Rol 1: PBS como servidor WG (backups)**

Cada PBS fisico es un servidor WireGuard cuyos unicos peers son los PVE que le envian backups.

```
PBS-1 (wg server)                    PBS-2 (wg server)
├── peer: PVE-A                      ├── peer: PVE-D
├── peer: PVE-B                      └── peer: PVE-E
└── peer: PVE-C
```

- PVE apunta su PBS storage a [fdab:1234:bkp::1]:8007 (IP WG del PBS)
- PBS:8007 deja de escuchar en IP publica
- Los peers PVE NO se ven entre ellos (ip forwarding desactivado, AllowedIPs /128 por peer)
- Trafico por vRack (25Gbps) cuando estan en el mismo DC

**Rol 2: WG Hub (acceso clientes + tecnicos + VMs)**

Hub centralizado donde se conectan:
- Usuarios remotos (tecnicos, clientes)
- Mikrotiks de oficinas de clientes
- VMs de clientes que necesitan red privada

```
WG Hub (par HA con keepalived)
├── peer: tecnico David
├── peer: tecnico Juan
├── peer: cliente ACME usuario remoto
├── peer: cliente ACME mikrotik oficina
├── peer: VM-web ACME (en PVE-1)
├── peer: VM-db ACME (en PVE-2)
├── peer: cliente BETA usuario remoto
├── peer: VM-app BETA (en PVE-1)
└── ...
```

- ip forwarding ACTIVADO (los peers deben verse entre ellos)
- Aislamiento por cliente con nftables: peers de ACME solo ven peers de ACME
- VMs en PVEs distintos se ven via WG Hub (cross-PVE transparente)
- Panel futuro para que el cliente defina granularidad peer-a-peer
- Reemplaza el modelo de 1 gateway VM por cliente: gateways compartidos con reglas granulares

**Rol 3: Mesh de gestion entre fisicos (sobre vRack)**

WireGuard sobre vRack para cifrar y autenticar el trafico de gestion entre servidores fisicos.

```
Fisico 1 (vRack)  ◄── WG tunnel cifrado ──►  Fisico 2 (vRack)
fdab:1234:mgmt::1                              fdab:1234:mgmt::2
```

- Servicios internos (Grafana, Netbox, Wazuh, Semaphore) escuchan en IP WG mesh
- Ansible, exporters, logs viajan por WG mesh
- Hub-spoke: todos los fisicos conectan a un hub de gestion (o al par HA)

#### Direccionamiento IPv6 ULA

```
fdab:1234:bkp::/48    → Red de backups (PBS ↔ PVE)
  fdab:1234:bkp:1::/64   PBS-1 y sus PVEs
  fdab:1234:bkp:2::/64   PBS-2 y sus PVEs

fdab:1234:vpn::/48    → Red de clientes/tecnicos (WG Hub)
  fdab:1234:vpn:acme::/64   Cliente ACME (VMs + usuarios)
  fdab:1234:vpn:beta::/64   Cliente BETA

fdab:1234:mgmt::/48   → Red de gestion (mesh entre fisicos)
  fdab:1234:mgmt::1     Hub/Fisico 1
  fdab:1234:mgmt::2     Fisico 2
```

#### Arquitectura del WG Hub

Debian minimal dedicado exclusivamente a WireGuard:

```
┌──────────────────────────────────┐
│  Debian minimal                   │
│                                   │
│  Kernel: WireGuard module         │
│  Host:   nftables (aislamiento   │
│          por cliente)             │
│  Host:   /etc/wireguard/*.conf   │
│                                   │
│  Docker: wgdashboard              │
│  └─ UI web (gestion de peers)    │
│  └─ API REST (→ ICSManager)      │
│  └─ Escribe /etc/wireguard/      │
│  └─ Recarga WG (wg syncconf)    │
│                                   │
│  Nada mas. Sin PBS, sin VMs,     │
│  sin otros servicios.            │
└──────────────────────────────────┘
```

#### Alta disponibilidad: par HA con keepalived

```
┌─────────────┐    ┌─────────────┐
│ WG Hub A    │    │ WG Hub B    │
│ (MASTER)    │    │ (BACKUP)    │
│ fdab::1     │    │ fdab::2     │
└──────┬──────┘    └──────┬──────┘
       │                   │
       └───── VIP ─────────┘
         fdab:1234:vpn::1
         (IP flotante)
```

- Misma config WG en ambos (mismas claves, mismos peers)
- Keepalived gestiona VIP sobre vRack
- Failover en <2 segundos
- Los peers no se enteran: su endpoint es la VIP, no cambia
- Para endpoint publico (usuarios remotos): VIP publica o DNS con TTL bajo

#### Aislamiento entre clientes (nftables en el hub)

```bash
# nftables en WG Hub
# Cliente ACME: sus peers se ven entre ellos
nft add rule inet filter forward \
  iifname "wg-hub" ip6 saddr fdab:1234:vpn:acme::/64 \
  ip6 daddr fdab:1234:vpn:acme::/64 accept

# Cliente BETA: sus peers se ven entre ellos
nft add rule inet filter forward \
  iifname "wg-hub" ip6 saddr fdab:1234:vpn:beta::/64 \
  ip6 daddr fdab:1234:vpn:beta::/64 accept

# DEFAULT: nadie ve a nadie de otro cliente
nft add rule inet filter forward iifname "wg-hub" drop
```

Cada cliente tiene su /64. Las reglas son por subnet, no por peer individual (mas simple). Panel futuro para granularidad peer-a-peer dentro del /64.

#### Cambio de modelo: gateways compartidos

| Modelo actual | Modelo nuevo |
|---|---|
| 1 VM gateway por cliente | 2 VM WG Hub (par HA) compartidos |
| 50 clientes = 50 VMs gateway | 50 clientes = 2 VMs hub |
| NAT por cliente | Sin NAT (peers directos IPv6) |
| Cada GW consume RAM/CPU | Recursos compartidos |
| Aislamiento por VM | Aislamiento por nftables |
| Sin HA (si el GW cae, el cliente cae) | HA con keepalived (<2 seg failover) |

Mitigacion de riesgo: tests automatizados de aislamiento (playbook que verifica que cada cliente solo alcanza sus recursos).

#### Exposicion resultante del servidor fisico

```
eth0 (IP publica):
  - Firewall: solo WG UDP (1 puerto) + SSH bastion
  - PBS:8007 CERRADO desde internet
  - PVE:8006 CERRADO desde internet
  - Todo lo demas: DROP

eth1 (vRack 25Gbps):
  - WG mesh cifrado (gestion + backups)
  - Servicios internos solo escuchan en IP WG

wg-hub (overlay IPv6):
  - Clientes y tecnicos acceden a paneles por aqui
  - :8007, :8006, Grafana, etc. solo via WG
```

#### Fase de arranque

Fase inicial con solo tecnicos internos para pulir el modelo:
1. Montar par HA de WG Hub (2 VMs Debian minimal)
2. Peers: solo tecnicos del equipo
3. Validar: acceso a paneles, grabacion bastion, aislamiento nftables
4. Cuando funcione estable: abrir a clientes y VMs progresivamente

#### Recursos

| Componente | CPU | RAM | Disco |
|-----------|-----|-----|-------|
| WG Hub A (master) | 1 vCPU | 512 MB | 10 GB |
| WG Hub B (backup) | 1 vCPU | 512 MB | 10 GB |
| wgdashboard (Docker en Hub A) | incluido | ~200 MB | incluido |
| WG en cada PBS (backup role) | kernel module | ~0 | ~0 |
| WG en cada fisico (mesh role) | kernel module | ~0 | ~0 |

#### Escalabilidad futura

- Si un par HA no es suficiente (>200 peers): asignar clientes a hubs distintos (Hub par 1: clientes A-M, Hub par 2: clientes N-Z), con tunel WG entre hubs para cross-routing
- Si se necesita mesh automatico: evaluar Headscale (compatible con clientes WireGuard existentes)
- Si se necesita routing dinamico entre DCs: FRRouting con OSPF sobre tuneles WG entre hubs
- Nada de esto es necesario para arrancar

---

## 4.2 DNS y service discovery

### Las 4 problematicas

1. **Autoritativo de clientes**: zonas de dominios de clientes (primario o secundario)
2. **Resolver para clientes**: navegacion de VMs y usuarios WG, con bloqueo configurable
3. **Naming automatico**: toda IP asignada tiene AAAA + PTR operativos desde el momento 0
4. **Diagnostico self-service**: pagina donde el cliente verifica su conectividad antes de abrir ticket

### Opciones evaluadas para resolver

| Herramienta | Multi-tenant | Panel cliente | Bloqueo config. | API | Estado |
|-------------|-------------|---------------|-----------------|-----|--------|
| **Technitium DNS** | Si (por cliente/zona) | Panel web multi-usuario nativo | Si (listas por cliente) | REST completa | **ELEGIDA como resolver** |
| **AdGuard Home** | Parcial (por IP) | Solo admin | Si (listas por IP) | REST | Descartada (no multi-tenant nativo) |
| **Pi-hole** | No | No | Global | Limitada | Descartada |
| **Blocky** | Si (grupos) | No tiene UI | Si (por grupo) | Si | Descartada (sin panel) |
| **Unbound** | No | No | No | No | Descartada (solo resuelve) |

### DECISION 4.2 (confirmada)

#### Componente 1: PowerDNS Authoritative (ya existente)

Se mantiene y amplia. No se reemplaza.

| Funcion | Estado |
|---------|--------|
| Zonas autoritativas de clientes (primario/secundario) | Ya funciona, mantener |
| Zona vpn6.com.es (nombres WG peers) | Crear, automatizar |
| Zonas PTR IPv6 (reverse DNS) | Crear, automatizar |
| API REST para creacion automatica de registros | Activar/usar |

Alimentado por:
- **wgdashboard**: al crear peer WG → API PowerDNS → AAAA + PTR en vpn6.com.es
- **Netbox (netbox-dns plugin)**: VMs sincronizadas desde PVE → registros DNS automaticos
- **Manual**: zonas de clientes como hasta ahora, evolucionando dominio a dominio

#### Componente 2: Technitium DNS (resolver con bloqueo)

**Solo como resolver**. No toca las zonas autoritativas (eso es PowerDNS).

Technitium resuelve consultas DNS de:
- VMs de clientes
- Usuarios WG (tecnicos, clientes remotos)
- Mikrotiks de oficinas conectados por WG

Funcionalidades clave:
- **Bloqueo multi-tenant**: cada cliente (identificado por rango IP WG) tiene su perfil de bloqueo
- **Panel web nativo multi-usuario**: cada cliente puede entrar y ver sus queries, ajustar bloqueo
- **Categorias de bloqueo**: malware, phishing, ads, adult, custom por cliente
- **Dashboard de trafico DNS**: top dominios, queries bloqueadas, estadisticas
- **API REST completa**: automatizable desde ICSManager/n8n
- **DNSSEC validation**: verifica firmas DNS
- **DoH/DoT upstream**: consultas cifradas a upstream (Cloudflare, Google)

```
VM cliente ──────►┌──────────────────────────┐
                  │  Technitium DNS           │
WG usuario ──────►│  (resolver + bloqueo)     │───► Upstream DoH
                  │                           │     (Cloudflare/Google)
Mikrotik ────────►│  Panel por cliente:       │
                  │  - ACME: malware+ads ✅   │
                  │  - BETA: solo malware ✅  │
                  │  - GAMMA: todo ✅         │
                  │                           │
                  │  Zonas internas:          │
                  │  → reenvio a PowerDNS     │
                  │    para *.vpn6.com.es     │
                  │    y zonas de clientes    │
                  └──────────────────────────┘
```

Technitium reenvia a PowerDNS las consultas de zonas internas:
- `*.vpn6.com.es` → PowerDNS (nombres WG)
- `*.cliente.com` → PowerDNS (si somos autoritativo)
- Todo lo demas → upstream DoH (navegacion)

Recursos: 1-2 vCPU, 512MB-1GB RAM, contenedor Docker o VM ligera.

#### Componente 3: Naming automatico (toda IP tiene nombre)

Esquema de nombres sobre `vpn6.com.es` (dominio propio):

```
Tecnicos internos:
  laptop.david.vpn6.com.es     → fdab:1234:vpn::42
  movil.david.vpn6.com.es      → fdab:1234:vpn::43

Clientes (subdominio por cliente):
  oficina.acme.vpn6.com.es     → fdab:1234:vpn:acme::1   (mikrotik)
  portatil.juan.acme.vpn6.com.es → fdab:1234:vpn:acme::10 (usuario)
  vm-web.acme.vpn6.com.es      → fdab:1234:vpn:acme::100 (VM)

Infraestructura:
  pbs-1.mgmt.vpn6.com.es       → fdab:1234:mgmt::10
  pve-2.mgmt.vpn6.com.es       → fdab:1234:mgmt::20
  grafana.mgmt.vpn6.com.es     → fdab:1234:mgmt::30

Con dominio del cliente (si lo pide):
  vpn.acme-empresa.com  → CNAME a acme.vpn6.com.es
```

Flujos de creacion automatica:

```
wgdashboard crea peer
  → nombre definido en el formulario
  → API PowerDNS: crea AAAA + PTR
  → El peer ya tiene rDNS + forward desde el momento 0

PVE crea VM
  → netbox-proxmox sincroniza VM a Netbox
  → netbox-dns genera registro en PowerDNS
  → La VM ya tiene nombre DNS automatico

Ansible despliega servidor nuevo
  → Playbook incluye task: registrar en PowerDNS via API
  → Servidor tiene nombre desde el primer boot
```

#### Componente 4: Pagina de diagnostico self-service

Panel web donde el cliente entra (SSO Authentik) y ve su estado:

```
┌─────────────────────────────────────────┐
│  Diagnostico de conectividad            │
│  Cliente: ACME                          │
│                                         │
│  ✅ Tu IP: fdab:1234:vpn:acme::10      │
│  ✅ WireGuard: conectado (handshake 3s) │
│  ✅ DNS: resolviendo correctamente      │
│  ❌ Certificado PBS: caduca en 3 dias   │
│  ✅ PBS:8007: accesible (120ms)         │
│  ✅ Latencia WG: 12ms                   │
│  ⚠️  Tunel IPsec oficina: no detectado  │
│                                         │
│  [Copiar informe] [Abrir ticket]        │
└─────────────────────────────────────────┘
```

Implementacion: app web ligera (Flask/FastAPI, un contenedor Docker) que:
1. Detecta IP origen → identifica cliente (via Netbox API o tabla local)
2. Ejecuta checks en tiempo real contra los servicios de ese cliente
3. Genera informe copiable para pegar en ticket
4. Login via SSO Authentik

**Prioridad**: mes 3+, desarrollo propio. No es critico para arrancar.

#### Integracion PVE → DNS via Netbox

```
PVE API ──netbox-proxmox──► Netbox
                               │
                               │ VM con IP asignada
                               ▼
                            netbox-dns plugin
                               │
                               │ Sincroniza zona en PowerDNS
                               ▼
                            PowerDNS API
                               │
                               ▼
                            AAAA: vm-web.acme.vpn6.com.es
                            PTR:  fdab:...::100 → vm-web.acme.vpn6.com.es
```

No hay hookscripts fragiles en PVE. Netbox es el intermediario fiable. Si la VM existe en Netbox con IP, tiene DNS.

#### Arquitectura DNS completa

```
┌───────────────────────────────────────────────────────┐
│                                                        │
│  AUTORITATIVO                     RESOLVER             │
│  ┌──────────────────┐            ┌──────────────────┐ │
│  │  PowerDNS Auth   │            │  Technitium DNS  │ │
│  │  (ya existente)  │◄─reenvio──│  (nuevo)         │ │
│  │                  │  zonas     │                  │ │
│  │  Zonas clientes  │  internas  │  Resolver +      │ │
│  │  vpn6.com.es     │            │  bloqueo multi-  │ │
│  │  PTR IPv6        │            │  tenant          │ │
│  │                  │            │                  │ │
│  │  ← Netbox API    │            │  Panel por       │ │
│  │  ← wgdashboard   │            │  cliente nativo  │ │
│  │  ← Ansible       │            │                  │ │
│  └──────────────────┘            │  Upstream: DoH   │ │
│                                  └──────────────────┘ │
│                                                        │
│  NAMING AUTOMATICO               DIAGNOSTICO           │
│  ┌──────────────────┐           ┌──────────────────┐  │
│  │  Netbox (SSOT)   │           │  Panel web ligero│  │
│  │  + netbox-dns    │           │  (Flask/FastAPI)  │  │
│  │  + netbox-proxmox│           │  SSO Authentik    │  │
│  │  → PowerDNS API  │           │  Checks por      │  │
│  │                  │           │  cliente          │  │
│  │  wgdashboard     │           │  Mes 3+           │  │
│  │  → PowerDNS API  │           └──────────────────┘  │
│  └──────────────────┘                                  │
│                                                        │
└───────────────────────────────────────────────────────┘
```

#### Recursos DNS

| Componente | CPU | RAM | Disco | Estado |
|-----------|-----|-----|-------|--------|
| PowerDNS Authoritative | existente | existente | existente | Ampliar zonas |
| Technitium DNS (resolver) | 1 vCPU | 512 MB - 1 GB | 10 GB | Nuevo |
| netbox-dns plugin | 0 (dentro de Netbox) | 0 | 0 | Configurar |
| Panel diagnostico | incluido en VM servicios | ~100 MB | incluido | Mes 3+ |

#### Prioridades despliegue DNS

| Prioridad | Que | Esfuerzo |
|-----------|-----|----------|
| **Semana 1** | Technitium DNS como resolver basico (sin bloqueo aun) | 2h |
| **Semana 1** | Crear zona vpn6.com.es en PowerDNS | 1h |
| **Semana 2** | Automatizar AAAA+PTR desde wgdashboard → PowerDNS API | 4h |
| **Semana 2** | Configurar Technitium: reenvio zonas internas a PowerDNS | 1h |
| **Mes 1** | Configurar perfiles de bloqueo por cliente en Technitium | 2h |
| **Mes 1** | netbox-proxmox + netbox-dns: auto-registro VMs | 1 dia |
| **Mes 2** | Abrir panel Technitium a clientes (con SSO Authentik) | 2h |
| **Mes 3+** | Panel de diagnostico self-service | 3-5 dias desarrollo |

---

## 4.3 Proxy inverso y publicacion de servicios

### El problema

- Tendencia a eliminar IPv4: los clientes deben poder publicar servicios sin necesitar IP publica propia
- Cada cliente que quiere exponer un servicio web necesita SSL, reverse proxy, y DNS
- Hoy se hace con Traefik (ya en uso) pero sin un modelo sistematico
- Los clientes deberian poder declarar "quiero publicar este servicio" y que se configure automaticamente

### Opciones evaluadas

| Herramienta | Autodiscovery | SSL auto | API | Estado |
|-------------|--------------|---------|-----|--------|
| **Traefik** | Docker labels, ficheros, API | Let's Encrypt nativo | REST | **ELEGIDA** (ya en uso) |
| **Nginx Proxy Manager** | Manual (UI web) | Let's Encrypt | No | Descartada (manual) |
| **HAProxy** | Config estatica | Manual o con ACME | Stats | Descartada (sin auto-SSL) |
| **Caddy** | Caddyfile, API | Automatico por defecto | REST | Alternativa viable |

### DECISION 4.3 (confirmada)

#### Traefik como proxy inverso centralizado

Ya se usa. Se amplia como punto de publicacion de servicios para clientes.

#### Modelo: cliente declara servicio → Traefik lo expone

```
Cliente ACME quiere publicar:
  - Portal web: portal.acme.com
  - API: api.acme.com

Flujo:
1. Cliente declara en panel (o ICSManager): "quiero publicar portal.acme.com"
2. DNS: AAAA de portal.acme.com → IPv6 del Traefik
3. Traefik: route portal.acme.com → VM del cliente (por WG IPv6)
4. SSL: Let's Encrypt automatico
5. Cliente solo tiene IPv6 WG, Traefik pone la cara publica
```

#### Arquitectura

```
Internet (IPv4+IPv6)
       │
       ▼
┌──────────────────────────────────────┐
│  Traefik (proxy inverso)             │
│                                       │
│  Escucha:                            │
│  - IPv4 publica :443 (legacy)        │
│  - IPv6 publica :443 (preferido)     │
│                                       │
│  Routes:                             │
│  portal.acme.com → [fdab:..acme::100]:8080  │
│  api.acme.com    → [fdab:..acme::101]:3000  │
│  grafana.mgmt.vpn6.com.es → [fdab:..mgmt::30]:3000 │
│                                       │
│  SSL: Let's Encrypt (automatico)     │
│  Middleware: rate limiting, headers   │
│                                       │
│  Config: ficheros dinamicos          │
│  (generados por Ansible/API)         │
└──────────────────────────────────────┘
       │
       │ WG IPv6
       ▼
┌──────────────┐  ┌──────────────┐
│ VM cliente   │  │ VM cliente   │
│ portal ACME  │  │ API ACME     │
│ (solo IPv6   │  │ (solo IPv6   │
│  WG, sin IP  │  │  WG, sin IP  │
│  publica)    │  │  publica)    │
└──────────────┘  └──────────────┘
```

#### Eliminacion progresiva de IPv4

La tendencia es que las VMs de clientes NO tengan IPv4 publica:

| Antes | Despues |
|-------|---------|
| Cada VM con IP publica | VM solo tiene IPv6 WG |
| SSL configurado en cada VM | SSL centralizado en Traefik |
| Firewall por VM | Firewall centralizado |
| El cliente gestiona su SSL | Traefik gestiona Let's Encrypt |

Para clientes que aun necesiten IPv4 entrante (legacy):
- Traefik escucha en IPv4 publica y reenvia a IPv6 WG del cliente
- El cliente no necesita IPv4 propia
- Transicion transparente

#### Configuracion dinamica

Traefik puede leer rutas de:
- **Ficheros YAML** (generados por Ansible al dar de alta un servicio)
- **Docker labels** (para servicios en Docker)
- **API** (para automatizacion)

```yaml
# /etc/traefik/dynamic/clientes/acme.yml
# Generado automaticamente al dar de alta el servicio
http:
  routers:
    portal-acme:
      rule: "Host(`portal.acme.com`)"
      service: portal-acme
      tls:
        certResolver: letsencrypt
  services:
    portal-acme:
      loadBalancer:
        servers:
          - url: "http://[fdab:1234:vpn:acme::100]:8080"
```

Flujo automatizado:
```
ICSManager/Panel → API → Ansible playbook
  → Crea fichero YAML en Traefik
  → Crea AAAA en PowerDNS
  → Traefik recarga automaticamente (file watcher)
  → Servicio publicado con SSL en segundos
```

#### Servicios internos via Traefik

Los paneles internos (Grafana, Netbox, Wazuh, etc.) tambien pasan por Traefik pero solo accesibles via WG:

```yaml
# Servicios internos - solo escuchan en IPv6 WG
http:
  routers:
    grafana:
      rule: "Host(`grafana.mgmt.vpn6.com.es`)"
      service: grafana
      tls:
        certResolver: letsencrypt
    netbox:
      rule: "Host(`netbox.mgmt.vpn6.com.es`)"
      service: netbox
      tls:
        certResolver: letsencrypt
```

Accesibles solo desde la red WG de gestion. Desde internet: no alcanzable.

#### Recursos

| Componente | CPU | RAM | Disco |
|-----------|-----|-----|-------|
| Traefik | 1 vCPU | 256-512 MB | 5 GB |

Puede correr en la VM de servicios (como contenedor Docker) o en los WG Hubs. No necesita VM dedicada.

#### Prioridades despliegue proxy

| Prioridad | Que | Esfuerzo |
|-----------|-----|----------|
| **Semana 1** | Traefik para servicios internos (Grafana, Netbox, etc.) | 2h |
| **Semana 2** | SSL automatico para servicios internos | 1h |
| **Mes 1** | Primer servicio de cliente publicado via Traefik | 2h |
| **Mes 2** | Template Ansible para alta automatica de servicios | 4h |
| **Mes 3+** | Panel para que clientes declaren servicios | Desarrollo |

---

## 4.4 Salida a internet: NAT CGNAT + política restrictiva

### El problema

Las VMs de clientes son IPv6-only (WG). Necesitan salida a internet para:
- apt update / Docker pull
- APIs externas
- Navegación (si aplica)

Sin un mecanismo de salida, las VMs están aisladas. Pero dar salida sin control abre riesgos: un cliente puede enviar spam, hacer scraping, o abusar y provocar que la IP compartida se blacklistee.

### DECISION 4.4 (confirmada)

#### Dual-stack con IPv4 CGNAT para salida

Cada VM de cliente tiene dual-stack:

```
VM de cliente:
  - IPv6 WG: fdab:1234:vpn:acme::10  → acceso entrante (RDP, SSH, servicios)
  - IPv4 CGNAT: 100.64.1.10/24       → solo salida NAT (navegar, apt, APIs)

Regla de oro:
  IPv4 = solo SALE, nunca ENTRA (outbound NAT)
  IPv6 = ENTRA controlado (el cliente/técnico accede vía WG)
  Web  = publicado por Traefik (HTTP/HTTPS al mundo)
```

#### Rango CGNAT (100.64.0.0/10)

Se usa el rango CGNAT (RFC 6598) en vez de RFC1918 para evitar colisiones con redes de oficina de clientes:

```
100.64.0.0/10 total (~4 millones de IPs)

Asignación: /24 por cliente
  100.64.1.0/24  → Cliente ACME
  100.64.2.0/24  → Cliente BETA
  100.64.3.0/24  → Cliente GAMMA
  ...
  100.64.254.0/24 → Cliente 254
  100.65.x.0/24   → Overflow si hace falta
```

Ventaja sobre 10.x o 192.168.x: un cliente con oficina en 192.168.1.0/24 conectada por WG no tiene conflicto con la IP CGNAT de su VM.

#### Política de salida restrictiva (nftables en WG Hub)

```nft
table ip filter {
    chain forward {
        type filter hook forward priority 0; policy drop;

        # Tráfico establecido/relacionado
        ct state established,related accept

        # --- PERMITIDO PARA TODOS ---
        ip saddr 100.64.0.0/10 tcp dport { 80, 443 } accept   # Web
        ip saddr 100.64.0.0/10 udp dport { 53, 123 } accept   # DNS, NTP
        ip saddr 100.64.0.0/10 tcp dport 53 accept             # DNS TCP

        # --- SMTP: BLOQUEADO POR DEFECTO ---
        ip saddr 100.64.0.0/10 tcp dport 25 drop               # NUNCA

        # Puerto 465/587: solo whitelist
        ip saddr 100.64.0.0/10 tcp dport { 465, 587 } ip daddr @smtp_whitelist accept

        # --- RESTO: DENEGADO ---
        ip saddr 100.64.0.0/10 log prefix "CGNAT-BLOCKED: " drop
    }
}

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100;
        # NAT compartido (base)
        ip saddr 100.64.0.0/10 oifname "eth0" masquerade
    }
}

# Whitelist SMTP
set smtp_whitelist {
    type ipv4_addr
    flags interval
    elements = {
        # WildDuck propio (IP interna)
        100.64.0.0/10,
        # Añadir IPs de servicios de correo autorizados según necesidad
    }
}
```

#### Puertos permitidos por defecto

| Puerto | Política | Razón |
|--------|----------|-------|
| 80, 443 | ✅ Permitido | Navegación, APIs, apt, Docker pulls |
| 53, 123 | ✅ Permitido | DNS, NTP |
| 25 | ✗ Bloqueado siempre | Prevenir spam. Sin excepciones. |
| 465, 587 | ✅ Solo whitelist | SMTP autenticado a servidores conocidos |
| Todo lo demás | ✗ Bloqueado | El cliente pide, se evalúa, se abre específicamente |

Logs de intentos bloqueados → Alloy → Loki. Visibles en Grafana.

#### Rate limiting por cliente

```nft
# Evitar abuso incluso en puertos permitidos
ip saddr 100.64.1.0/24 tcp dport { 80, 443 } limit rate 200/second burst 50 accept
ip saddr 100.64.1.0/24 tcp dport { 80, 443 } drop
```

#### Definición de producto: base vs premium

```
SALIDA INTERNET (NAT) - Definición de producto
─────────────────────────────────────────────────
INCLUIDO (base):
  - Salida compartida: HTTP/HTTPS, DNS, NTP
  - SMTP solo a servidores autorizados (465/587 whitelist)
  - Puerto 25 bloqueado sin excepciones
  - IP pública compartida
  - IP puede cambiar sin preaviso
  - Sin garantía de reputación de IP
  - Política restrictiva no negociable

PREMIUM (contratación adicional):
  - IP dedicada fija con PTR personalizable
  - Si se blacklistea, solo afecta al cliente que la contrató
  - Apertura de puertos adicionales (previa evaluación)
  - Reglas firewall personalizadas
  - Rate limits ajustados
─────────────────────────────────────────────────
```

Implementación del premium:

```nft
# Cliente ACME tiene IP dedicada (premium)
ip saddr 100.64.1.0/24 oifname "eth0" snat to 1.2.3.101

# Resto de clientes: IP compartida
ip saddr 100.64.0.0/10 oifname "eth0" snat to 1.2.3.100
```

#### Gestión

- Reglas nftables gestionadas con Ansible (un fichero por cliente, versionado en Forgejo)
- Aperturas de puertos: el cliente solicita → se evalúa → se aplica con playbook → queda en git
- Asignación de rangos CGNAT: en Netbox (IPAM), prefijo 100.64.X.0/24 asignado al tenant
- Alertas: logs de tráfico bloqueado correlacionados con cliente en Grafana

---

## 4.5 Modelo de VMs: una VM = un servicio (caja negra)

### El problema

Si varios servicios con BBDD comparten una VM:
- Un técnico trabajando en Zammad puede afectar a Netbox
- Diagnosticar "qué consume IO" es complejo cuando hay 5 servicios mezclados
- Migrar un servicio a otro servidor requiere separarlo primero
- El backup de la VM incluye todo, no puedes restaurar solo un servicio

### DECISION 4.5 (confirmada)

**Cada servicio con estado (BBDD) tiene su propia VM.** Es una caja negra: todo lo que necesita está dentro (app + BBDD + Redis). Se backupea entera, se migra entera, se diagnostica de forma aislada.

#### Mapa de VMs por servicio

| VM | Contenido (todo Docker dentro) | BBDD | Stateful |
|----|-------------------------------|------|----------|
| **VM Zammad** | Zammad + PostgreSQL + Redis + Elasticsearch | PostgreSQL | Sí, VM dedicada |
| **VM Authentik** | Authentik + PostgreSQL + Redis | PostgreSQL | Sí, VM dedicada |
| **VM Netbox** | Netbox + PostgreSQL + Redis | PostgreSQL | Sí, VM dedicada |
| **VM Outline** | Outline + PostgreSQL + Redis | PostgreSQL | Sí, VM dedicada |
| **VM ICSManager** | ICSManager + PostgreSQL (todo Docker) | PostgreSQL | Sí, VM dedicada |
| **VM WildDuck** | WildDuck + MongoDB + Redis (todo Docker) | MongoDB | Sí, VM dedicada |
| **VM Servicios** | Semaphore, Uptime Kuma, Technitium, Traefik | Ninguna pesada | Stateless/ligeros |
| **VM Monitoring** | VictoriaMetrics, Loki, Grafana, Alertmanager | Time-series | Ya dedicada |
| **VM Wazuh** | Wazuh Manager + Dashboard (OpenSearch) | OpenSearch | Ya dedicada |

#### Ventajas operativas

| Aspecto | Servicios mezclados | Caja negra por servicio |
|---------|-------------------|----------------------|
| Diagnosticar | "¿Qué de los 5 servicios consume IO?" | "La VM Zammad consume IO → es Zammad" |
| Migrar | Separar primero, luego mover | Mover la VM entera |
| Backup/Restore | Todo o nada | Restauras solo Zammad sin tocar nada |
| Un técnico trabaja | Con miedo de romper otros servicios | Libertad total dentro de su VM |
| Actualizar | Coordinar 5 servicios | Actualizar uno, si falla, rollback VM |
| Escalar | Dar más RAM a la VM afecta a todos | Dar más RAM solo a Zammad |

#### WildDuck y MongoDB

MongoDB dockerizado dentro de la VM WildDuck. De momento es correo interno del equipo técnico, volumen bajo. Si el correo se abre a más usuarios o el volumen crece significativamente, se revalúa:
- MongoDB en VM dedicada (si el tamaño lo justifica)
- O migración a servicio gestionado

Los tokens SMTP de WildDuck para avisos de PVE son operativamente críticos. El backup de la VM WildDuck los incluye automáticamente.

#### Impacto en dimensionamiento

La tabla actualizada de VMs:

| VM | vCPU | RAM | Disco |
|----|------|-----|-------|
| Monitoring | 4 | 8-12 GB | 200-500 GB |
| Wazuh | 4 | 12 GB | 100 GB |
| Zammad | 2-3 | 4-6 GB | 50 GB |
| Authentik | 1-2 | 2-3 GB | 20 GB |
| Netbox | 1-2 | 2-3 GB | 20 GB |
| ICSManager | 1-2 | 2-3 GB | 20 GB |
| WildDuck | 1-2 | 2-3 GB | 30-50 GB |
| PMG | 1-2 | 2-3 GB | 20 GB |
| PDM | 1-2 | 1-2 GB | 20 GB |
| Outline | 1 | 1-2 GB | 20 GB |
| Servicios (stateless) | 1-2 | 2-3 GB | 20 GB |
| Bastion | 1 | 1 GB | 20 GB |
| WG Hub A | 1 | 512 MB | 10 GB |
| WG Hub B | 1 | 512 MB | 10 GB |
| Forgejo | exist. | exist. | exist. |
| **Total** | **~24-32 vCPU** | **~44-58 GB** | **~580-910 GB** |

---

## 4.6 Proxmox Datacenter Manager (PDM)

### El problema

Con múltiples PVE en distintos DCs (Francia, potencialmente otros), la gestión es por nodo o por cluster. Si un cliente necesita mover una VM de un PVE a otro (por mantenimiento, por rendimiento, o por fallo), hay que hacerlo manualmente conectándose a cada PVE.

### DECISION 4.6 (confirmada)

**PDM como panel único de gestión multi-cluster.**

Proxmox Datacenter Manager permite:
- Vista global de todos los nodos PVE y clusters en un solo panel
- Migración de VMs entre clusters/nodos (lo que los clientes necesitan)
- Gestión centralizada de recursos, storage, red
- Planificación de capacidad a nivel de datacenter

```
                    ┌─────────────────────┐
                    │  PDM                 │
                    │  (panel único)       │
                    └──────┬──────────────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼─────┐ ┌───▼──────┐ ┌──▼────────┐
        │ PVE-1     │ │ PVE-2    │ │ PVE-3     │
        │ Francia   │ │ Francia  │ │ Alemania  │
        │ 20 VMs    │ │ 15 VMs   │ │ 10 VMs    │
        └───────────┘ └──────────┘ └───────────┘

El técnico ve todo desde PDM. Puede migrar VM-web
de PVE-1 a PVE-2 desde la misma interfaz.
```

#### Recursos

| Componente | CPU | RAM | Disco |
|-----------|-----|-----|-------|
| PDM (VM dedicada) | 1-2 vCPU | 1-2 GB | 20 GB |

VM dedicada (patrón caja negra). Ligero: es solo plano de gestión, no compute.

SSO con Authentik. Accesible solo vía WG (red de gestión).

---

## 4.7 Proxmox Mail Gateway (PMG)

### El problema

WildDuck gestiona el correo (buzones, IMAP, SMTP, tokens). Pero no tiene filtrado avanzado de spam ni antivirus. Si se abre el correo a más usuarios (más allá del equipo técnico), el volumen de spam y malware entrante será un problema.

### DECISION 4.7 (confirmada)

**PMG como gateway de filtrado delante de WildDuck.**

```
Internet (puerto 25)
       │
       ▼
┌──────────────────────┐
│  PMG                  │
│  Proxmox Mail Gateway │
│                       │
│  - Anti-spam          │
│    (SpamAssassin)     │
│  - Anti-virus         │
│    (ClamAV)           │
│  - Greylisting        │
│  - SPF/DKIM/DMARC     │
│  - Cuarentena con UI  │
│  - Reglas por dominio │
│  - Reglas por usuario │
│                       │
│  Puerto 25 entrante   │
│  → filtra             │
│  → reenvía limpio a   │
│    WildDuck            │
└──────────┬───────────┘
           │ (email limpio)
           ▼
┌──────────────────────┐
│  WildDuck             │
│  (buzones, IMAP,      │
│   tokens SMTP PVE)    │
└──────────────────────┘
```

#### Funcionalidades clave

| Función | Qué hace |
|---------|----------|
| **Anti-spam** | SpamAssassin + reglas custom, scoring por mensaje |
| **Anti-virus** | ClamAV, escanea adjuntos entrantes y salientes |
| **Greylisting** | Retrasa primer intento desde IP desconocida (mata el 80% del spam) |
| **SPF/DKIM/DMARC** | Verifica autenticidad del remitente |
| **Cuarentena** | UI web donde el usuario ve mensajes filtrados y puede liberar falsos positivos |
| **Reglas por dominio** | Políticas diferentes por dominio gestionado |
| **Reporting** | Estadísticas: spam filtrado, virus detectados, volumen |

#### Email saliente

PMG también filtra salida: si un usuario comprometido envía spam, PMG lo detecta y bloquea antes de que salga y blacklistee la IP.

```
WildDuck (usuario envía)
       │
       ▼
┌──────────────────────┐
│  PMG                  │
│  - Verifica que no    │
│    sea spam saliente  │
│  - Firma DKIM         │
│  - Rate limiting      │
└──────────┬───────────┘
           │
           ▼
      Internet (destino)
```

#### Integración con el stack

| Integración | Qué aporta |
|-------------|-----------|
| PMG → Loki (logs) | Logs de spam filtrado, virus detectados → visibles en Grafana |
| PMG → Alertmanager | Alerta si el volumen de spam sube anómalamente |
| PMG → Wazuh | Eventos de seguridad (virus detectados) correlacionados |
| PMG SSO Authentik | Panel de administración con cuenta unificada |
| PMG cuarentena → usuario | El usuario accede vía web a su cuarentena |

#### Recursos

| Componente | CPU | RAM | Disco |
|-----------|-----|-----|-------|
| PMG (VM dedicada) | 1-2 vCPU | 2-3 GB | 20 GB |

ClamAV consume la mayor parte de la RAM (~1-1.5 GB para las firmas). SpamAssassin ligero. VM dedicada siguiendo patrón caja negra.

#### Prioridades

| Paso | Qué | Cuándo |
|------|-----|--------|
| Desplegar PMG con reglas básicas | Cuando WildDuck se abra a más usuarios |
| Configurar DKIM signing | Junto con el despliegue |
| Integrar logs PMG → Loki | Semana 1 post-despliegue |
| Cuarentena accesible a usuarios | Junto con el despliegue |

No es urgente mientras WildDuck solo sirva al equipo técnico. **Se despliega cuando se amplíe el correo.**

---

## Resumen Capa 4 completa (DECISIONES FINALES)

```
┌─────────────────────────────────────────────────────┐
│              CAPA 4: RED Y CONECTIVIDAD              │
├─────────────────────────────────────────────────────┤
│                                                      │
│  4.1 VPN (confirmada)                                │
│  ┌───────────────────────────────────┐               │
│  │  WireGuard + wgdashboard + IPv6   │               │
│  │                                    │               │
│  │  Rol 1: PBS = WG server (backups) │               │
│  │  - Peers: solo PVEs con storage   │               │
│  │  - Sin forwarding (aislados)      │               │
│  │                                    │               │
│  │  Rol 2: WG Hub HA (clientes)     │               │
│  │  - Par HA keepalived              │               │
│  │  - Tecnicos + clientes + VMs     │               │
│  │  - nftables aislamiento/cliente   │               │
│  │  - wgdashboard (UI + API)        │               │
│  │  - Reemplaza 1-GW-por-cliente    │               │
│  │                                    │               │
│  │  Rol 3: Mesh gestion (vRack)     │               │
│  │  - WG cifrado sobre vRack 25Gbps │               │
│  │  - Servicios internos solo aqui   │               │
│  │                                    │               │
│  │  Direccionamiento: IPv6 ULA       │               │
│  │  fdab:1234:bkp::/48  (backups)   │               │
│  │  fdab:1234:vpn::/48  (clientes)  │               │
│  │  fdab:1234:mgmt::/48 (gestion)   │               │
│  └───────────────────────────────────┘               │
│                                                      │
│  4.2 DNS (confirmada)                                │
│  ┌───────────────────────────────────┐               │
│  │  PowerDNS Auth (ya existente)     │               │
│  │  - Zonas clientes (pri/sec)       │               │
│  │  - vpn6.com.es (nombres WG)      │               │
│  │  - PTR IPv6                       │               │
│  │  - ← Netbox + wgdashboard API    │               │
│  │                                    │               │
│  │  Technitium DNS (resolver nuevo)  │               │
│  │  - Resolver + bloqueo multi-tenant│               │
│  │  - Panel web por cliente          │               │
│  │  - Perfiles: malware/ads/adult    │               │
│  │  - Reenvio zonas internas → PDNS  │               │
│  │                                    │               │
│  │  Naming automatico:               │               │
│  │  - wgdashboard → PDNS API         │               │
│  │  - Netbox → netbox-dns → PDNS     │               │
│  │  - PVE → Netbox → DNS automatico │               │
│  │                                    │               │
│  │  Panel diagnostico (mes 3+)       │               │
│  │  - Self-service checks cliente    │               │
│  └───────────────────────────────────┘               │
│                                                      │
│  4.3 PROXY INVERSO (confirmada)                      │
│  ┌───────────────────────────────────┐               │
│  │  Traefik (ya en uso, ampliar)     │               │
│  │  - Proxy inverso centralizado     │               │
│  │  - SSL Let's Encrypt automatico   │               │
│  │  - Clientes declaran servicio →   │               │
│  │    Traefik lo publica             │               │
│  │  - VMs sin IPv4 publica           │               │
│  │    (Traefik pone la cara publica) │               │
│  │  - Config YAML dinamica via       │               │
│  │    Ansible/API                     │               │
│  │  - Servicios internos solo via WG │               │
│  └───────────────────────────────────┘               │
│                                                      │
│  4.4 SALIDA INTERNET NAT (confirmada)                │
│  ┌───────────────────────────────────┐               │
│  │  Dual-stack por VM:              │               │
│  │  - IPv4 CGNAT (100.64.x.x/24)   │               │
│  │    solo salida NAT, nunca entra  │               │
│  │  - IPv6 WG: acceso entrante     │               │
│  │                                    │               │
│  │  Política restrictiva:           │               │
│  │  - 80,443,53,123: permitido     │               │
│  │  - Puerto 25: BLOQUEADO siempre │               │
│  │  - 465,587: solo whitelist SMTP │               │
│  │  - Resto: bloqueado por defecto │               │
│  │                                    │               │
│  │  Producto base: IP compartida    │               │
│  │  (puede cambiar sin preaviso)   │               │
│  │  Premium: IP dedicada fija      │               │
│  └───────────────────────────────────┘               │
│                                                      │
│  4.5 MODELO VMs (confirmada)                         │
│  ┌───────────────────────────────────┐               │
│  │  Una VM = un servicio (caja negra)│              │
│  │  App + BBDD + Redis todo dentro  │               │
│  │  - Zammad, Authentik, Netbox,    │               │
│  │    ICSManager, WildDuck, Outline │               │
│  │    cada uno en su VM dedicada    │               │
│  │  - Backup/migración: VM entera   │               │
│  │  - Diagnóstico aislado           │               │
│  │  - Total: ~24-32 vCPU, 44-58 GB │               │
│  └───────────────────────────────────┘               │
│                                                      │
│  4.6 PDM (confirmada)                                │
│  ┌───────────────────────────────────┐               │
│  │  Proxmox Datacenter Manager      │               │
│  │  - Gestión multi-cluster PVE     │               │
│  │  - Migración VMs entre PVEs     │               │
│  │  - Vista global de recursos      │               │
│  │  - SSO Authentik, solo via WG    │               │
│  │  - VM dedicada: 1-2 vCPU, 1-2GB │               │
│  └───────────────────────────────────┘               │
│                                                      │
│  4.7 PMG (confirmada, desplegar al ampliar correo)   │
│  ┌───────────────────────────────────┐               │
│  │  Proxmox Mail Gateway            │               │
│  │  - Anti-spam (SpamAssassin)      │               │
│  │  - Anti-virus (ClamAV)           │               │
│  │  - SPF/DKIM/DMARC               │               │
│  │  - Greylisting                   │               │
│  │  - Cuarentena con UI web        │               │
│  │  - Filtro saliente (anti-spam)  │               │
│  │  - Delante de WildDuck          │               │
│  │  - VM dedicada: 1-2 vCPU, 2-3GB │               │
│  └───────────────────────────────────┘               │
│                                                      │
└─────────────────────────────────────────────────────┘

Recursos Capa 4:
- WG Hub A: 1 vCPU, 512 MB RAM, 10 GB disco
- WG Hub B: 1 vCPU, 512 MB RAM, 10 GB disco
- Technitium DNS: 1 vCPU, 512 MB - 1 GB RAM (en VM Servicios)
- Traefik: contenedor Docker, 256-512 MB RAM (en VM Servicios)
- PDM: 1-2 vCPU, 1-2 GB RAM, 20 GB disco
- PMG: 1-2 vCPU, 2-3 GB RAM, 20 GB disco
- PowerDNS: ya existente
- WG en servidores: kernel module, 0 extra
- NAT CGNAT: en WG Hub (nftables, 0 extra)

Dimensionamiento revisado (todas las VMs de gestión):
  ~24-32 vCPU, ~44-58 GB RAM, ~580-910 GB disco
  Recomendación servidor: 128 GB RAM, 8-12c/16-24t, 2×2TB NVMe
```