theus-cli-linux-x64 1.2.2 → 1.4.0

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

@@ -1,307 +0,0 @@
----
-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

@@ -1,299 +0,0 @@
----
-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

@@ -1,96 +0,0 @@
----
-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