theus-cli-linux-arm64 0.2.84

package/vendor/theus-arsenal/skills/homelab-segmentacion-vlan/SKILL.md

@@ -0,0 +1,307 @@
+---
+name: homelab-segmentacion-vlan
+description: Segmentación de redes domésticas en VLANs para tráfico IoT, invitados, dispositivos de confianza y servidores usando UniFi, pfSense/OPNsense y MikroTik — incluye puertos trunk, reglas de firewall y mapeo de SSIDs a VLANs.
+---
+
+# Segmentación VLAN para homelab
+
+Cómo dividir una red doméstica en VLANs aisladas para que los dispositivos IoT, los invitados y tus PCs principales no puedan comunicarse entre sí. La mejora de seguridad de mayor impacto para una red doméstica.
+
+Todas las reglas de firewall mostradas aquí añaden aislamiento entre segmentos — no eliminan protecciones existentes. Aplica los cambios en una ventana de mantenimiento y verifica la conectividad entre segmentos después de cada paso antes de continuar.
+
+## Cuándo usarla
+
+- Configurar VLANs en una red doméstica por primera vez
+- Aislar dispositivos IoT (focos inteligentes, cámaras, TVs) de los dispositivos de confianza
+- Crear una red Wi-Fi de invitados que no pueda alcanzar los dispositivos del hogar
+- Explicar cómo funcionan las VLANs a alguien que no conoce el concepto
+- Configurar puertos trunk, puertos de acceso y mapeo SSID-a-VLAN
+- Diagnosticar problemas de enrutamiento inter-VLAN o de reglas de firewall en pfSense/OPNsense/UniFi
+
+## Cómo funciona
+
+```
+Sin VLANs — red plana:
+  Todos los dispositivos en 192.168.1.0/24
+  Smart TV (posible malware) → puede alcanzar tu NAS, tus PCs, todo
+
+Con VLANs:
+  VLAN 10 — Confianza  192.168.10.0/24  (PCs, teléfonos, laptops)
+  VLAN 20 — IoT        192.168.20.0/24  (smart TV, focos, cámaras)
+  VLAN 30 — Servidores 192.168.30.0/24  (NAS, Pi, VMs)
+  VLAN 40 — Invitados  192.168.40.0/24  (Wi-Fi de visitas)
+  VLAN 99 — Gestión    192.168.99.0/24  (paneles web de switch/AP)
+
+  Smart TV → bloqueado para alcanzar 192.168.10.0/24 y 192.168.30.0/24
+  Invitados → solo internet, no ven ningún dispositivo del hogar
+```
+
+## Plantilla de diseño de VLANs
+
+```
+VLAN  Nombre      Subred              Gateway         Propósito
+10    confianza   192.168.10.0/24     192.168.10.1    PCs, teléfonos, laptops
+20    iot         192.168.20.0/24     192.168.20.1    Dispositivos de hogar inteligente
+30    servidores  192.168.30.0/24     192.168.30.1    NAS, Pi, autoalojado
+40    invitados   192.168.40.0/24     192.168.40.1    Wi-Fi de visitas
+99    gestion     192.168.99.0/24     192.168.99.1    Paneles web de equipos de red
+```
+
+## Ejemplos
+
+**Homelab típico con AP UniFi y switch gestionable:**
+
+```
+Escenario: casa de 3 dormitorios, UniFi Dream Machine + switch UniFi de 8 puertos + 2 APs
+
+VLAN 10 — Confianza  192.168.10.0/24   MacBook, iPhones, iPad
+VLAN 20 — IoT        192.168.20.0/24   Termostato Nest, Philips Hue, timbre Ring, smart TVs
+VLAN 30 — Servidores 192.168.30.0/24   NAS Synology (192.168.30.10), Pi-hole (192.168.30.2)
+VLAN 40 — Invitados  192.168.40.0/24   Wi-Fi de visitas — solo internet
+
+Mapeo SSID → VLAN:
+  "Casa"      → VLAN 10 (WPA2, contraseña fuerte, solo dispositivos de confianza)
+  "IoT"       → VLAN 20 (WPA2, contraseña separada, impresa en el router para altas)
+  "Invitados" → VLAN 40 (WPA2, contraseña simple que puedes compartir libremente)
+
+Comportamiento de puertos del switch:
+  Puerto 1  → trunk al router (VLANs 10,20,30,40,99 etiquetadas)
+  Puerto 2  → trunk a los APs (VLANs 10,20,40 etiquetadas; el AP etiqueta por SSID)
+  Puerto 3  → acceso VLAN 30 (NAS — sin etiquetar, no necesita conocer VLANs)
+  Puerto 4  → acceso VLAN 30 (Pi-hole — sin etiquetar)
+  Puertos 5–8 → acceso VLAN 10 (estaciones de trabajo cableadas)
+
+Reglas de firewall aplicadas (todas añaden aislamiento, ninguna elimina protecciones):
+  IoT → Confianza: BLOQUEAR
+  IoT → Servidores: BLOQUEAR excepto 192.168.30.2:53 (DNS de Pi-hole permitido)
+  IoT → Internet: PERMITIR
+  Invitados → Redes locales: BLOQUEAR
+  Invitados → Internet: PERMITIR
+  Confianza → todo: PERMITIR
+```
+
+## Configuración en UniFi
+
+### Crear las redes en el controlador UniFi
+
+```
+Settings → Networks → Create New Network
+
+Para cada VLAN:
+  Name: IoT
+  Purpose: Corporate  (proporciona DHCP + enrutamiento)
+  VLAN ID: 20
+  Network: 192.168.20.0/24
+  Gateway IP: 192.168.20.1
+  DHCP: Enable
+  DHCP Range: 192.168.20.100 – 192.168.20.254
+```
+
+### Mapear SSIDs a VLANs (UniFi)
+
+```
+Settings → WiFi → Create New WiFi
+
+  Name: IoT-Network
+  Password: <contraseña separada>
+  Network: IoT  ← selecciona tu VLAN aquí
+  # Todos los dispositivos que se conecten a este SSID caen en la VLAN 20
+
+  Name: Invitados
+  Password: <contraseña de invitados>
+  Network: Guest
+  Guest Policy: Enable  ← también aísla a los invitados entre sí
+```
+
+### Reglas de firewall en UniFi (Traffic Rules)
+
+```
+Settings → Traffic & Security → Traffic Rules
+
+# Bloquear que IoT alcance la VLAN de confianza
+  Action: Block
+  Category: Local Network
+  Source: IoT (192.168.20.0/24)
+  Destination: Confianza (192.168.10.0/24)
+
+# Permitir que IoT solo alcance internet
+  Action: Allow
+  Source: IoT
+  Destination: Internet
+
+# Bloquear invitados hacia todas las redes locales
+  Action: Block
+  Source: Invitados
+  Destination: Local Networks
+```
+
+## Configuración en pfSense / OPNsense
+
+### Crear las VLANs
+
+```
+Interfaces → Assignments → VLANs → Add
+
+  Parent Interface: em1  (tu NIC de LAN)
+  VLAN Tag: 20
+  Description: IoT
+
+# Repite para cada VLAN y luego asigna cada una a una interfaz:
+Interfaces → Assignments → Add
+  Selecciona la VLAN creada → clic en Add
+  Activa la interfaz y ponle la IP de gateway (192.168.20.1/24)
+```
+
+### DHCP para cada VLAN
+
+```
+Services → DHCP Server → Selecciona la interfaz de tu VLAN
+
+  Enable DHCP
+  Range: 192.168.20.100 a 192.168.20.254
+  DNS Servers: 192.168.30.2  ← IP de Pi-hole si tienes uno
+```
+
+### Reglas de firewall (pfSense/OPNsense)
+
+```
+# Las reglas se procesan de arriba abajo; gana la primera coincidencia.
+
+# En la interfaz IoT (VLAN 20):
+  Regla 1: Permitir IoT → DNS de Pi-hole  ← DEBE ir antes de la regla de bloqueo RFC1918
+    Protocolo: UDP/TCP
+    Origen: red IoT
+    Destino: 192.168.30.2 puerto 53
+    Acción: Allow
+
+  Regla 2: Bloquear IoT → RFC1918 (todos los rangos IP privados)
+    Protocolo: any
+    Origen: red IoT
+    Destino: RFC1918  (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12)
+    Acción: Block
+
+  Regla 3: Permitir IoT → internet
+    Protocolo: any
+    Origen: red IoT
+    Destino: any
+    Acción: Allow
+
+# En la interfaz de Confianza (VLAN 10):
+  Permitir todo (los dispositivos de confianza pueden alcanzar todo)
+    Origen: red Confianza
+    Destino: any
+    Acción: Allow
+
+# Excepciones adicionales para dispositivos IoT que necesitan servicios locales concretos:
+  Insertar antes de la Regla 2 (el bloqueo RFC1918):
+    Protocolo: TCP
+    Origen: red IoT
+    Destino: 192.168.30.x puerto 8123  ← Home Assistant
+    Acción: Allow
+```
+
+## Configuración en MikroTik
+
+```
+# Paso 1: crea un bridge con filtrado VLAN habilitado
+/interface bridge
+add name=bridge vlan-filtering=yes
+
+# Paso 2: añade los puertos físicos al bridge
+# Puerto trunk hacia el router/enlace ascendente (etiquetado para todas las VLANs)
+/interface bridge port
+add bridge=bridge interface=ether1 frame-types=admit-only-vlan-tagged
+
+# Puerto de acceso para dispositivos de confianza (VLAN 10 sin etiquetar)
+/interface bridge port
+add bridge=bridge interface=ether2 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
+
+# Puerto de acceso para dispositivos IoT (VLAN 20 sin etiquetar)
+/interface bridge port
+add bridge=bridge interface=ether3 pvid=20 frame-types=admit-only-untagged-and-priority-tagged
+
+# Paso 3: define qué VLANs se permiten en qué puertos
+/interface bridge vlan
+add bridge=bridge tagged=ether1 untagged=ether2 vlan-ids=10
+add bridge=bridge tagged=ether1 untagged=ether3 vlan-ids=20
+
+# Paso 4: crea las interfaces VLAN sobre el bridge (IPs de gateway)
+/interface vlan
+add interface=bridge name=vlan10 vlan-id=10
+add interface=bridge name=vlan20 vlan-id=20
+
+# Paso 5: asigna las IPs de gateway
+/ip address
+add interface=vlan10 address=192.168.10.1/24
+add interface=vlan20 address=192.168.20.1/24
+
+# Paso 6: pools y servidores DHCP
+/ip pool
+add name=pool-confianza ranges=192.168.10.100-192.168.10.254
+add name=pool-iot ranges=192.168.20.100-192.168.20.254
+
+/ip dhcp-server
+add interface=vlan10 address-pool=pool-confianza name=dhcp-confianza
+add interface=vlan20 address-pool=pool-iot name=dhcp-iot
+
+/ip dhcp-server network
+add address=192.168.10.0/24 gateway=192.168.10.1
+add address=192.168.20.0/24 gateway=192.168.20.1
+
+# Paso 7: firewall — bloquear que IoT alcance la VLAN de confianza
+/ip firewall filter
+add chain=forward src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
+    action=drop comment="Bloquear IoT hacia Confianza"
+```
+
+## Puertos trunk vs puertos de acceso
+
+```
+# Puerto trunk: transporta varias VLANs (etiquetadas) — conecta switch-switch, switch-router, switch-AP
+# Puerto de acceso: transporta una sola VLAN (sin etiquetar) — conecta dispositivos finales (PC, cámara, NAS)
+
+# Un puerto de switch gestionable conectado a tu router debe ser trunk:
+  VLANs permitidas: 10, 20, 30, 40, 99
+
+# Un puerto que conecta a un PC debe ser de acceso:
+  VLAN: 10 (confianza)
+  Sin etiquetado — el PC no sabe ni le importa qué es una VLAN
+
+# Un puerto que conecta a un AP debe ser trunk:
+  El AP etiqueta el tráfico de cada SSID con el ID de VLAN correcto
+  VLANs permitidas: 10, 20, 40  (las de los SSIDs que sirva el AP)
+```
+
+## Antipatrones
+
+```
+# MAL: crear VLANs sin añadir reglas de firewall
+# Las VLANs sin reglas de firewall no dan seguridad — el enrutamiento inter-VLAN está abierto por defecto
+# BIEN: añade reglas de bloqueo explícitas justo después de crear las VLANs
+
+# MAL: poner el Pi-hole en la VLAN de IoT
+# Los dispositivos IoT lo alcanzan, pero los de confianza no (sin reglas extra)
+# BIEN: Pi-hole en la VLAN de servidores con una regla que permita a todas las VLANs alcanzar el puerto 53
+
+# MAL: VLAN nativa igual a la VLAN de gestión
+# El tráfico sin etiquetar que cae en tu VLAN de gestión habilita ataques de VLAN hopping
+# BIEN: usa una VLAN dedicada sin uso como nativa (p. ej. VLAN 999) y mantén el tráfico de gestión etiquetado
+
+# MAL: misma contraseña de Wi-Fi para el SSID de IoT y el de confianza
+# Quien conozca la contraseña puede conectar dispositivos IoT al segmento equivocado
+```
+
+## Buenas prácticas
+
+- Empieza con 4 VLANs: Confianza, IoT, Servidores, Invitados — añade más según necesites
+- Coloca el Pi-hole en la VLAN de servidores (192.168.30.x)
+- Añade una regla de firewall que permita DNS (puerto 53) desde todas las VLANs hacia la IP del Pi-hole — antes de cualquier regla de bloqueo RFC1918
+- Prueba el aislamiento tras cada cambio de regla: desde la VLAN IoT, intenta hacer ping a un dispositivo de confianza — debe fallar
+- Usa una VLAN de gestión para los paneles web de switch y APs, y restringe su acceso solo a la VLAN de confianza
+- Documenta tu diseño de VLANs en una tabla (ID de VLAN, nombre, subred, propósito)
+
+## Skills relacionadas
+
+- `homelab-diseno-red`
+- `homelab-dns-pihole`
+- `homelab-vpn-wireguard`

package/vendor/theus-arsenal/skills/homelab-vpn-wireguard/SKILL.md

@@ -0,0 +1,299 @@
+---
+name: homelab-vpn-wireguard
+description: Configuración de servidor VPN WireGuard, peers y generación de claves, split tunneling vs túnel completo, DDNS y acceso remoto a una red doméstica desde móviles y laptops.
+---
+
+# VPN WireGuard para homelab
+
+WireGuard es un protocolo VPN rápido y moderno. Es la opción correcta para acceso remoto a una red doméstica — más simple de configurar que OpenVPN y más rápido que la mayoría de alternativas.
+
+Todos los ejemplos de configuración muestran montajes habituales. Revisa cada comando — especialmente las reglas de reenvío de iptables y los permisos de los archivos de claves — antes de aplicarlos a tu sistema, y haz los cambios en una ventana de mantenimiento.
+
+## Cuándo usarla
+
+- Montar un servidor WireGuard en una Raspberry Pi, un host Linux, pfSense o un router
+- Generar pares de claves WireGuard y escribir archivos de configuración de peers
+- Configurar acceso remoto desde un teléfono o laptop hacia la red doméstica
+- Explicar split tunneling (enrutar solo el tráfico del hogar) vs túnel completo (enrutar todo)
+- Diagnosticar conexiones WireGuard que no levantan
+- Automatizar la generación de configuraciones de peers para múltiples clientes
+
+## Cómo funciona WireGuard
+
+```
+Tu teléfono (cliente WireGuard)
+    │
+    │  Túnel UDP cifrado (puerto 51820)
+    │
+Tu router doméstico (servidor WireGuard — necesita IP pública o DDNS)
+    │
+    Tu red doméstica (192.168.1.0/24, NAS, Pi, etc.)
+
+Cada dispositivo tiene un par de claves (pública + privada).
+El servidor conoce la clave pública de cada cliente.
+El cliente conoce la clave pública del servidor + el endpoint (IP:puerto).
+El tráfico se cifra extremo a extremo sin servidor central ni autoridad de certificados.
+```
+
+## Configuración del servidor (Linux)
+
+```bash
+# Instala WireGuard
+sudo apt update && sudo apt install wireguard -y
+
+# Genera el par de claves del servidor — crea los archivos con permisos privados desde el inicio
+sudo mkdir -p /etc/wireguard
+sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server_private.key'
+sudo sh -c 'wg pubkey < /etc/wireguard/server_private.key > /etc/wireguard/server_public.key'
+
+# Escribe la configuración del servidor — sustituye el valor real de la clave privada
+# No guardes claves privadas en control de versiones ni las compartas
+sudo tee /etc/wireguard/wg0.conf << 'EOF'
+[Interface]
+Address = 10.8.0.1/24              # Subred de la VPN — el servidor toma la .1
+ListenPort = 51820
+PrivateKey = <pegar_clave_privada_del_servidor>
+
+# Reglas de reenvío acotadas: permitir tráfico VPN de entrada/salida, no un FORWARD ACCEPT general
+PostUp   = iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
+PostUp   = iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
+PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+PostDown = iptables -D FORWARD -i wg0 -o eth0 -j ACCEPT
+PostDown = iptables -D FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
+PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
+
+[Peer]
+# Teléfono — sustituir por la clave pública real del teléfono
+PublicKey = <clave_publica_telefono>
+AllowedIPs = 10.8.0.2/32
+
+[Peer]
+# Laptop — sustituir por la clave pública real de la laptop
+PublicKey = <clave_publica_laptop>
+AllowedIPs = 10.8.0.3/32
+EOF
+sudo chmod 600 /etc/wireguard/wg0.conf
+
+# Sustituye eth0 por el nombre real de tu interfaz de salida
+# Compruébalo con: ip route show default
+
+# Habilita el reenvío de IP (requerido para enrutar tráfico a través del servidor)
+echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-wireguard.conf
+sudo sysctl --system
+
+# Arranca WireGuard y actívalo en el arranque
+sudo wg-quick up wg0
+sudo systemctl enable wg-quick@wg0
+```
+
+## Configuración del cliente
+
+```bash
+# Genera un par de claves único para cada dispositivo cliente
+# Ejecútalo en el cliente, o en el servidor y transfiere la clave privada de forma segura — nunca en texto plano
+umask 077
+wg genkey | tee phone_private.key | wg pubkey > phone_public.key
+
+# Archivo de configuración del cliente (phone_wg0.conf):
+[Interface]
+PrivateKey = <clave_privada_telefono>
+Address = 10.8.0.2/32
+DNS = 192.168.1.2                  # Opcional: usar Pi-hole como DNS a través del túnel
+
+[Peer]
+PublicKey = <clave_publica_servidor>
+Endpoint = tu-ip-de-casa.ddns.net:51820  # Tu IP pública o hostname DDNS
+AllowedIPs = 192.168.1.0/24            # Split tunnel: solo tráfico de la red doméstica
+# AllowedIPs = 0.0.0.0/0, ::/0        # Túnel completo: todo el tráfico por la VPN
+
+PersistentKeepalive = 25              # Mantiene el hueco NAT abierto (requerido en clientes móviles)
+```
+
+## Split tunnel vs túnel completo
+
+```
+# Split tunnel: AllowedIPs = 192.168.1.0/24
+  Solo el tráfico destinado a tu red doméstica pasa por la VPN.
+  El tráfico de internet (YouTube, Spotify) va directo — mejor rendimiento en móvil.
+  Ideal para: "solo quiero alcanzar mi NAS y mi Pi desde cualquier lugar".
+
+# Túnel completo: AllowedIPs = 0.0.0.0/0, ::/0
+  TODO el tráfico pasa por tu conexión de internet doméstica.
+  Útil para: aprovechar el DNS del hogar/el bloqueo de anuncios de Pi-hole.
+  Desventaja: la velocidad de subida de tu casa se convierte en tu cuello de botella en todas partes.
+
+# Split tunnel multi-subred (el caso más común en homelab):
+  AllowedIPs = 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, 10.8.0.0/24
+  Enruta todas tus VLANs a través del túnel; internet sigue yendo directo.
+```
+
+## Generación de claves y gestión de peers
+
+```python
+import subprocess
+
+def generate_keypair() -> tuple[str, str]:
+    """Genera un par de claves WireGuard. Devuelve (clave_privada, clave_publica)."""
+    private = subprocess.check_output(["wg", "genkey"]).decode().strip()
+    public = subprocess.run(
+        ["wg", "pubkey"], input=private.encode(), capture_output=True
+    ).stdout.decode().strip()
+    return private, public
+
+def generate_preshared_key() -> str:
+    return subprocess.check_output(["wg", "genpsk"]).decode().strip()
+
+def build_client_config(
+    client_private_key: str,
+    client_vpn_ip: str,       # p. ej. "10.8.0.3"
+    server_public_key: str,
+    server_endpoint: str,     # p. ej. "casa.ejemplo.com:51820"
+    allowed_ips: str = "192.168.1.0/24",
+    dns: str = "",
+) -> str:
+    dns_line = f"DNS = {dns}\n" if dns else ""
+    return f"""[Interface]
+PrivateKey = {client_private_key}
+Address = {client_vpn_ip}/32
+{dns_line}
+[Peer]
+PublicKey = {server_public_key}
+Endpoint = {server_endpoint}
+AllowedIPs = {allowed_ips}
+PersistentKeepalive = 25
+"""
+
+def build_server_peer_block(
+    client_public_key: str,
+    client_vpn_ip: str,
+    comment: str = "",
+) -> str:
+    comment_line = f"# {comment}\n" if comment else ""
+    return f"""
+{comment_line}[Peer]
+PublicKey = {client_public_key}
+AllowedIPs = {client_vpn_ip}/32
+"""
+```
+
+Mantén las claves privadas fuera del control de versiones. Si usas este script, escribe el material de claves en archivos con modo 600 y nunca lo registres en logs ni lo imprimas.
+
+## WireGuard en pfSense / OPNsense
+
+```
+# pfSense: VPN → WireGuard → Add Tunnel
+  Interface Keys: Generate (crea el par de claves automáticamente)
+  Listen Port: 51820
+  Interface Address: 10.8.0.1/24
+
+# Añadir peer (uno por cliente):
+  Public Key: <clave pública del cliente>
+  Allowed IPs: 10.8.0.2/32
+
+# Asignar la interfaz WireGuard:
+  Interfaces → Assignments → Add (seleccionar wg0)
+  Habilitar la interfaz, sin IP (ya está en la config del túnel)
+
+# Reglas de firewall:
+  WAN → permitir UDP puerto 51820 entrante (para que los clientes alcancen el servidor)
+  Interfaz WireGuard → permitir tráfico hacia las redes LAN que quieras alcanzables
+```
+
+## DDNS (DNS dinámico) para servidores domésticos
+
+La mayoría de conexiones domésticas tienen IP dinámica. Usa DDNS para que tu endpoint VPN siga siendo alcanzable tras un cambio de IP.
+
+```bash
+# Opción 1: DDNS con Cloudflare — guarda las credenciales en un archivo de secretos, no en línea
+# Entrada de docker-compose usando un archivo de entorno:
+  ddns-updater:
+    image: qmcgaw/ddns-updater
+    env_file: ./ddns.env   # guarda aquí zone_id y token, no en el compose
+    restart: unless-stopped
+
+# ddns.env (chmod 600, sin commitear a git):
+# SETTINGS_CLOUDFLARE_ZONE_ID=tu_zone_id
+# SETTINGS_CLOUDFLARE_TOKEN=tu_api_token
+
+# Opción 2: DuckDNS (gratis, simple)
+  Regístrate en duckdns.org → obtén un token y un subdominio (micasa.duckdns.org)
+  Guarda el token en /etc/ddns.env (modo 600) y usa un pequeño script propiedad de root:
+
+  # /usr/local/bin/update-duckdns
+  #!/bin/sh
+  set -eu
+  . /etc/ddns.env
+  curl --fail --silent --show-error --max-time 10 \
+    --get "https://www.duckdns.org/update" \
+    --data-urlencode "domains=micasa" \
+    --data-urlencode "token=${DUCKDNS_TOKEN}" \
+    --data-urlencode "ip="
+
+  # Tarea cron:
+  */5 * * * * /usr/local/bin/update-duckdns >/dev/null 2>&1
+```
+
+## Diagnóstico
+
+```bash
+# Comprueba el estado de WireGuard y el último handshake
+sudo wg show
+
+# Si "latest handshake" es never o muy antiguo, el túnel no está conectado.
+# Comprueba:
+# 1. ¿Está abierto el puerto UDP 51820 en el router/firewall?
+sudo ufw status  # o revisa las reglas de firewall en pfSense/UniFi
+
+# 2. ¿Es correcta la clave pública del servidor en la config del cliente?
+sudo wg show wg0 public-key   # Compárala con la que hay en la config del cliente
+
+# 3. ¿Está habilitado el reenvío de IP en el servidor?
+cat /proc/sys/net/ipv4/ip_forward  # Debe ser 1
+
+# 4. ¿AllowedIPs del cliente cubre la IP que intentas alcanzar?
+# Si AllowedIPs = 192.168.1.0/24 e intentas llegar a 192.168.3.5, no se enrutará.
+
+# Revisa los logs del kernel en busca de errores de WireGuard
+dmesg | grep wireguard
+
+# Reinicia WireGuard
+sudo wg-quick down wg0 && sudo wg-quick up wg0
+```
+
+## Antipatrones
+
+```
+# MAL: guardar claves privadas en control de versiones o compartirlas
+# Las claves privadas equivalen a contraseñas — nunca las commitees a git
+
+# MAL: usar AllowedIPs = 0.0.0.0/0 en móvil sin considerar el impacto
+# El túnel completo enruta todo el tráfico móvil por la subida de tu casa — normalmente lento
+
+# MAL: no configurar PersistentKeepalive en clientes móviles
+# Los clientes móviles detrás de NAT pierden los túneles inactivos sin esto
+
+# MAL: abrir el puerto 51820 en el firewall pero olvidar el reenvío de IP en el servidor
+# El túnel conecta pero no enruta tráfico — confuso de depurar
+
+# MAL: compartir un par de claves entre varios dispositivos cliente
+# Cada dispositivo debe tener su propio par único — compartir claves rompe el modelo de seguridad
+
+# MAL: usar una regla amplia "FORWARD ACCEPT" en iptables
+# Acota las reglas de reenvío a la interfaz wg0 y a la dirección concreta
+```
+
+## Buenas prácticas
+
+- Genera un par de claves único por dispositivo cliente — nunca reutilices claves
+- Usa split tunneling (`AllowedIPs = <subredes del hogar>`) en móvil
+- Configura `PersistentKeepalive = 25` en todos los clientes móviles
+- Usa DDNS si tu ISP asigna IP dinámica; guarda las credenciales en archivos de entorno, no en línea
+- Usa reglas de reenvío de iptables acotadas (entrada solo por wg0) en lugar de un FORWARD ACCEPT general
+- Añade la IP del Pi-hole como `DNS =` en las configs de los clientes para tener bloqueo de anuncios a través de la VPN
+- Rota el par de claves del servidor periódicamente y actualiza las configs de todos los clientes
+
+## Skills relacionadas
+
+- `homelab-diseno-red`
+- `homelab-segmentacion-vlan`
+- `homelab-dns-pihole`

package/vendor/theus-arsenal/skills/ingenieria-agentica/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: ingenieria-agentica
+description: Opera como ingeniero agéntico con ejecución guiada por evals, descomposición de tareas y enrutado de modelos consciente del costo; incluye el modelo operativo para equipos donde los agentes de IA generan gran parte de la implementación.
+---
+
+# Ingeniería agéntica
+
+Usa esta skill para flujos de ingeniería donde los agentes de IA realizan la mayor parte del trabajo de implementación y los humanos hacen cumplir la calidad y los controles de riesgo. Cubre tanto la operación individual (bucle de evals, descomposición, enrutado de modelos) como el modelo operativo de equipo (proceso, revisiones y arquitectura para equipos que entregan con generación de código asistida por IA).
+
+## Principios operativos
+
+1. Define los criterios de completitud antes de ejecutar.
+2. Descompón el trabajo en unidades del tamaño de un agente.
+3. Enruta los niveles de modelo según la complejidad de la tarea.
+4. Mide con evals y verificaciones de regresión.
+
+## Bucle eval-first
+
+1. Define un eval de capacidad y un eval de regresión.
+2. Ejecuta la línea base y captura las firmas de fallo.
+3. Ejecuta la implementación.
+4. Vuelve a correr los evals y compara los deltas.
+
+## Descomposición de tareas
+
+Aplica la regla de la unidad de 15 minutos:
+- cada unidad debe ser verificable de forma independiente
+- cada unidad debe tener un único riesgo dominante
+- cada unidad debe exponer una condición de "hecho" clara
+
+## Enrutado de modelos
+
+- Modelo económico del catálogo Theus: clasificación, transformaciones repetitivas (boilerplate), ediciones acotadas
+- Modelo estándar del catálogo Theus: implementación y refactors
+- Modelo premium del catálogo Theus: arquitectura, análisis de causa raíz, invariantes multi-archivo
+
+Escala al nivel de modelo superior solo cuando el nivel inferior falla con una brecha de razonamiento clara.
+
+## Estrategia de sesión
+
+- Continúa la sesión para unidades estrechamente acopladas.
+- Inicia una sesión nueva tras las transiciones de fase importantes.
+- Compacta después de completar un hito, no durante una depuración activa.
+
+## Cambios de proceso en equipos AI-first
+
+1. La calidad de la planificación importa más que la velocidad de tecleo.
+2. La cobertura de evals importa más que la confianza anecdótica.
+3. El foco de la revisión pasa de la sintaxis al comportamiento del sistema.
+
+## Requisitos de arquitectura
+
+Prefiere arquitecturas amigables para agentes:
+- límites explícitos
+- contratos estables
+- interfaces tipadas
+- tests deterministas
+
+Evita el comportamiento implícito repartido en convenciones ocultas.
+
+## Foco de revisión para código generado por IA
+
+Prioriza:
+- invariantes y casos borde
+- límites de error (error boundaries)
+- suposiciones de seguridad y autenticación
+- acoplamiento oculto y riesgo de despliegue (rollout)
+- regresiones de comportamiento
+- integridad de datos
+- manejo de fallos
+
+No gastes ciclos de revisión en desacuerdos puramente de estilo cuando el formateo/lint automatizado ya lo impone; minimiza el tiempo dedicado a problemas de estilo que la automatización ya cubre.
+
+## Estándar de testing
+
+Eleva el listón de testing para el código generado:
+- cobertura de regresión obligatoria en los dominios tocados
+- aserciones explícitas de casos borde
+- verificaciones de integración en los límites de las interfaces
+
+## Disciplina de costos
+
+Registra por tarea:
+- modelo
+- estimación de tokens
+- reintentos
+- tiempo de reloj
+- éxito/fallo
+
+## Señales de contratación y evaluación
+
+Los ingenieros AI-first sólidos:
+- descomponen limpiamente el trabajo ambiguo
+- definen criterios de aceptación medibles
+- producen prompts y evals de alta señal
+- hacen cumplir los controles de riesgo bajo presión de entrega