1148 lines
48 KiB
Markdown
1148 lines
48 KiB
Markdown
# 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
|
||
```
|