Al terminar, tendrás un montaje:

• Robusto: usa UUID en lugar de nombres de dispositivo volátiles (/dev/sda1).
• Seguro para el arranque: si el disco no está conectado, el sistema arranca igualmente.
• Bajo demanda: el disco se monta solo cuando se accede a él, ahorrando recursos.

Índice

1. Conceptos previos
2. Paso 1: Comprobar que el disco está conectado y detectado
3. Paso 2: Obtener el UUID del disco
4. Paso 3: Crear el punto de montaje
5. Paso 4: Editar /etc/fstab
6. Paso 5: Recargar systemd
7. Paso 6: Activar la unidad de automontaje
8. Paso 7: Verificar el montaje
9. Paso 8: Permisos de usuario.
10. Opciones de fstab explicadas
11. Solución de problemas
12. Resumen del flujo completo
13. Conclusión

Conceptos previos.

Antes de tocar nada, conviene tener claros cuatro conceptos que aparecerán una y otra vez:

• /media vs /mnt: por convención, /media se usa para medios extraíbles (USB, discos externos) y /mnt para montajes temporales o manuales. Usaremos /media.
• UUID vs /dev/sdX: el nombre /dev/sda, /dev/sdb… puede cambiar entre arranques (sobre todo con discos USB). El UUID es un identificador único y estable del sistema de archivos. Usa siempre UUID.
• systemd y fstab: en sistemas modernos, systemd es quien gestiona los montajes definidos en /etc/fstab mediante unidades (.mount y .automount). Por eso, tras editar fstab, hay que decirle a systemd que recargue (daemon-reload).
• x-systemd.automount: opción que le dice a systemd que no monte el disco inmediatamente, sino que cree una unidad de automontaje que lo montará la primera vez que se acceda al directorio. Esto es ideal para discos USB que queremos que se monten solo cuando se usen.

Paso 1: Comprobar que el disco está conectado y detectado.

Este paso es ineludible. Si el disco no está siendo detectado por el sistema, ningún ajuste en fstab funcionará. Y es un fallo muy común con discos USB que no reciben suficiente energía o con cables defectuosos.

Conecta el disco y ejecuta:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

Deberías ver un disco nuevo con el tamaño esperado, por ejemplo:

NAME        SIZE TYPE FSTYPE MOUNTPOINT
sda       931,5G disk
└─sda1    931,5G part ext4
sdb       111,8G disk
└─sdb1    111,8G part ext4
nvme0n1   238,5G disk
├─nvme0n1p1 256M part vfat  /boot/firmware
└─nvme0n1p2 237,7G part ext4 /

En este ejemplo voy a montar dos discos duros, un disco SSD de 120GB, conectado al puerto USB 3.0, mediante un adaptador SATA-USB, el cual aparece en el sistema como sdb1 y un disco HD de 1TB, conectado al puerto USB 3.0 mediante un adaptador SATA-USB autoalimentado apareciendo como sda1

Antes de seguir, si tu disco no aparece, el problema es físico o de alimentación.

Conecta el disco y revisa los últimos mensajes del kernel

sudo dmesg | tail -n 30

Busca errores como device descriptor read/64, error -110 o reset full-speed USB device. Si los ves, prueba con otro puerto USB, otro cable o asegúrate de que la alimentación externa (si la tiene) está conectada. Desconecta y vuelve a conectar el disco, y repite lsblk.

Truco: en Raspberry Pi y otros SBC, un disco de 2.5″ puede consumir más de lo que un solo puerto USB puede entregar de forma estable. Un hub USB con alimentación suele resolver el problema.

Paso 2: Obtener el UUID del disco.

Una vez que el disco aparece en lsblk, obtén su UUID real:

sudo blkid /dev/sda1 /dev/sdb1

Salida de ejemplo:

/dev/sda1: LABEL="SD_120Gb" UUID="f6b565ed-cee0-4508-b94d-464c422fd9f1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c7a2c28e-01"
/dev/sdb1: LABEL="Disco_1TB" UUID="4fa0fd15-57f5-4b75-8cc7-916186cb1062" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="1d6caf36-01"

Copia el UUID exacto. Compruébalo carácter por carácter: un 0 por O, un 1 por l… y el montaje fallará silenciosamente.

Consejo: Si tienes varios discos, puedes ver todos los UUID a la vez con sudo blkid (sin argumentos).

Paso 3: Crear el punto de montaje.

Crea un directorio vacío donde se montará el disco:

sudo mkdir -p /media/Disco_120GB
sudo mkdir -p /media/Disco_1TB

Comprueba que esté vacío:

ls -la /media/Disco_120GB /media/Disco_1TB

Si tiene archivos dentro (residuos de un montaje anterior), límpialos con cuidado. Un punto de montaje «sucio» puede impedir que systemd active la unidad.

Paso 4: Editar /etc/fstab.

Abre el archivo con tu editor preferido:

sudo nano /etc/fstab

Añade una línea al final con este formato:

UUID=4fa0fd15-57f5-4b75-8cc7-916186cb1062 /media/Disco_1TB ext4  defaults,nofail,x-systemd.automount,x-systemd.device-timeout=10s  0  2

UUID=f6b565ed-cee0-4508-b94d-464c422fd9f1 /media/Disco_120GB ext4  defaults,nofail,x-systemd.automount,x-systemd.device-timeout=5s  0  2

Desglose de los campos:

¿Qué hace cada opción?

• defaults: opciones por defecto (rw, suid, dev, exec, auto, nouser, async).
• nofail: si el disco no está presente al arrancar, el sistema arranca igualmente sin bloquearse. Imprescindible para discos secundarios y USB.
• x-systemd.automount: crea una unidad .automount. El disco no se monta hasta que se accede a él por primera vez. Perfecto para discos que no se usan constantemente.
• x-systemd.device-timeout=10s: le dice a systemd que no espere más de 10 segundos al dispositivo. Sin esto, el valor por defecto es 90 segundos, lo que puede alargar el arranque si el disco no está conectado.

Valores recomendados para x-systemd.device-timeout:

• SSD (detección casi instantánea): 5s.
• HDD por USB (el motor tarda en arrancar): 10s o 15s.
• Nunca 0: eso haría que el sistema espere indefinidamente.

Extra opcional: si quieres que el disco se desmonte solo tras un tiempo sin uso (ahorro de energía), añade x-systemd.idle-timeout=10min.

Guarda el archivo (Ctrl+O, Enter, Ctrl+X en nano).

Paso 5: Recargar systemd

Cada vez que edites /etc/fstab, systemd debe releer la configuración:

sudo systemctl daemon-reload

Si no haces esto, systemd seguirá usando la versión antigua en memoria y verás el aviso:

mount: (consejo) fstab ha sido modificado, pero systemd sigue utilizando
       la versión antigua; utilice 'systemctl daemon-reload' para recargar.

daemon-reload no monta nada: solo recarga definiciones. El montaje viene en los pasos siguientes.

Paso 6: Activar la unidad de automontaje.

Este es el paso que más gente olvida y la causa principal de que «no se monte nada». Tras crear una entrada nueva en fstab con x-systemd.automount, systemd crea la unidad pero la deja inactiva (inactive (dead)). No se activará sola hasta el próximo arranque.

Comprueba el estado:

systemctl list-units --type=automount --all

Comprueba que en el resultado ninguna aparece inactive.

UNIT                          LOAD   ACTIVE   SUB     DESCRIPTION
media-Disco_120GB.automount   loaded inactive dead    media-Disco_120GB.automount
media-Disco_1TB.automount     loaded active   running media-Disco_1TB.automount

Si es así, actívala manualmente:

sudo systemctl start media-Disco_120GB.automount

Nota sobre el nombre de la unidad: systemd nombra las unidades a partir del punto de montaje, sustituyendo / por -. Para /media/Disco_120GB → media-Disco_120GB.automount. Si el nombre tiene espacios o caracteres especiales, systemd los escapa (por ejemplo, espacios → \x20). Puedes listar todas las unidades disponibles con systemctl list-unit-files | grep automount.

Verifica que ahora aparece como active (running):

systemctl list-units --type=automount --all | grep 120GB

Paso 7: Verificar el montaje.

Con la unidad activa, dispara el montaje accediendo al directorio:

ls /media/Disco_120GB /media/Disco_1TB

Esto «despierta» la unidad de automontaje y monta la partición en ese instante. Ahora comprueba con:

mount | grep /media
df -h | grep Disco

Deberías ver algo así:

/dev/sdb1 on /media/Disco_120GB type ext4 (rw,relatime,...,x-systemd.automount)

¡Listo! El disco está montado y se montará automáticamente cada vez que accedas a él o al arrancar el sistema.

Paso 8: Permisos de usuario:

Cuando montas un sistema de archivos nativo de Linux como ext4 mediante fstab, el directorio recién montado en /media/... pertenecerá por defecto al usuario root (root:root).

Aunque lo menciones de pasada en la tabla de opciones para exFAT/NTFS (uid=1000,gid=1000), a muchos usuarios les pasa que montan su partición ext4, van a guardar un archivo desde su usuario normal sin privilegios y obtienen un error de «Permiso denegado».

Sugerencia: Añadir una pequeña nota o un comando rápido al final del proceso para ajustar los permisos si es necesario:

sudo chown -R $USER:$USER /media/Disco_120GBsudo chown -R $USER:$USER /media/Disco_1TB

Nota: Esto debe hacerse con el disco ya montado, de lo contrario cambiarías los permisos del punto de montaje vacío y al montarse el disco se sobrescribirían con los permisos raíz del sistema de ficheros).

Opciones de fstab explicadas {#opciones-fstab}

Resumen rápido de las opciones más útiles para discos secundarios:

Solución de problemas.

El disco no aparece en lsblk / blkid

• Revisa cable, puerto USB y alimentación.
• Ejecuta sudo dmesg | tail -n 30 justo después de conectar el disco.
• Prueba otro puerto (mejor USB 3.0) u otro cable.
• Desconecta y vuelve a conectar el disco.

systemctl start ...automount da Job failed

Obtén el error exacto:

sudo journalctl -u media-Disco_120GB.automount -xe --no-pager

Causas más frecuentes:

1. UUID incorrecto en fstab. Compara carácter por carácter con sudo blkid.
2. Conflicto con una unidad .mount en estado failed. Resetea:sudo systemctl reset-failed media-Disco_120GB.mount sudo systemctl start media-Disco_120GB.automount
3. Punto de montaje con residuos. Comprueba ls -la /media/Disco_120GB. Si hay archivos, limpia el directorio.
4. El disco no está listo en el momento del arranque. Añade o aumenta x-systemd.device-timeout (por ejemplo, 30s).

La unidad aparece como inactive (dead)

Es el estado normal tras daemon-reload si no se ha hecho start. Solución:

sudo systemctl start media-Disco_120GB.automount

mount -a no muestra nada y el disco «no se monta»

Con x-systemd.automount, mount -a no monta el disco de inmediato, solo valida la configuración. El montaje real ocurre al acceder al directorio:

ls /media/Disco_120GB

El arranque tarda mucho (más de un minuto)

Falta x-systemd.device-timeout. Sin él, systemd espera 90 segundos por defecto al dispositivo. Añade x-systemd.device-timeout=10s (o 5s para SSD, 15s para HDD USB).

«No tengo permisos para escribir en el disco» (exFAT/NTFS)

Añade a las opciones: uid=1000,gid=1000 (sustituye por tu id -u e id -g).

Resumen del flujo completo.

Para que no se te olvide nada, este es el flujo completo que debes seguir cada vez que añadas un disco nuevo:

# 1. Comprobar que el disco está detectado
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

# 2. Obtener el UUID
sudo blkid /dev/sdX1

# 3. Crear el punto de montaje
sudo mkdir -p /media/Disco_XXX

# 4. Editar /etc/fstab con el UUID y las opciones
sudo nano /etc/fstab
#   → UUID=... /media/Disco_XXX ext4 defaults,nofail,x-systemd.automount,x-systemd.device-timeout=10s 0 2

# 5. Recargar systemd
sudo systemctl daemon-reload

# 6. Activar la unidad de automontaje
sudo systemctl start media-Disco_XXX.automount

# 7. Verificar que está activa
systemctl list-units --type=automount --all | grep XXX

# 8. Disparar el montaje accediendo al directorio
ls /media/Disco_XXX

# 9. Verificar montaje final
mount | grep /media
df -h | grep Disco

Conclusión

Montar discos al inicio en Debian es una tarea que, bien hecha, no da problemas nunca más. La clave está en:

• Verificar siempre que el disco está detectado antes de tocar fstab.
• Usar UUID y nunca /dev/sdX.
• Combinar nofail con x-systemd.device-timeout para no bloquear el arranque.
• Activar la unidad de automontaje manualmente la primera vez.
• Tener a mano journalctl y reset-failed cuando algo falle.

Con estos pasos, tus discos se montarán solos, de forma fiable, y sin sorpresas. Si te has encontrado con algún caso raro que no aparezca aquí, déjalo en los comentarios y lo añadiremos a la guía.

¡Feliz montaje!

A diferencia del 2.4 GHz, el 5 GHz tiene mucho más espectro disponible, lo que significa menos interferencias de los vecinos y la posibilidad de usar canales más anchos para alcanzar velocidades gigabit. Sin embargo, tiene un talón de Aquiles: su menor capacidad para atravesar paredes.

En esta guía vamos a analizar, opción por opción y basándonos en una configuración real, cómo exprimir al máximo tu red de 5 GHz priorizando la velocidad y la baja latencia.

Aviso: Si al aplicar esta configuración notas que algunos dispositivos (como ciertos Android TV o equipos multimedia) no detectan la red de 5 GHz, es muy probable que se deba a que no son compatibles con los canales DFS (como el canal 100 recomendado aquí). Si te ocurre esto, puedes solucionarlo fácilmente fijando un canal no-DFS en la parte baja de la banda (del 36 al 48) o conectando dichos dispositivos a la red de 2.4 GHz, la cual ofrece una estabilidad excelente para este tipo de aparatos fijos.

Configuración General (Identidad y Seguridad)

Esta pestaña define cómo se presenta tu red al mundo y qué nivel de seguridad ofrece.

• Habilitar Smart Connect: OFF (Desactivado)
  • Cómo debe estar: Desactivado (para tener redes separadas).
  • El porqué: Smart Connect intenta unir el 2.4 y el 5 GHz bajo el mismo nombre. Esto puede llevar a que dispositivos que necesitan velocidad se conecten al 2.4 GHz (más lento), o que dispositivos alejados intenten agarrarse al 5 GHz (que no llega bien). Al separarlas (Cronos_2.4G y Cronos_5G), tú tienes el control absoluto.
• Banda:5 GHz
  • El porqué: Es el menú que estamos configurando.
• Nombre de red (SSID):Cronos_5G
  • El porqué: Añadir el sufijo «_5G» o «_5GHz» es fundamental para identificar la red rápida frente a la de cobertura.
• Ocultar SSID: No
  • El porqué: Ocultar la red no aporta seguridad real (cualquier hacker la verá con herramientas básicas) y puede causar problemas de conexión y batería en móviles y portátiles.
• Modo Inalámbrico: N/AC mixed
  • Cómo debe estar: N/AC mixed (o AX/N/AC mixed si tu router y dispositivos son Wi-Fi 6).
  • El porqué: Asegura la compatibilidad con dispositivos Wi-Fi 4 (N) y Wi-Fi 5 (AC). Si tuvieras un router de última generación (Wi-Fi 6) y dispositivos compatibles, lo ideal sería seleccionar el modo «AX» para aprovechar las ventajas de la nueva tecnología.
• Ancho de banda del canal: 80 MHz
  • Cómo debe estar: 80 MHz.
  • El porqué: Es el punto dulce del 5 GHz. Te permite velocidades altísimas (hasta 1.7 Gbps) sin las desventajas de los 160 MHz, que son más propensos a sufrir interferencias y a requerir canales DFS (radar) que a veces causan cortes breves.
• Canal: 100
  • Cómo debe estar: Manual (eligiendo un canal libre) o Automático.
  • El porqué: El canal 100 pertenece a la banda DFS (Selección Dinámica de Frecuencia). Estos canales suelen estar menos saturados por los routers de los vecinos, lo que se traduce en menos interferencias y más velocidad. Nota: Si notas cortes extraños, puede ser porque el router detecta un radar y cambia de canal automáticamente; en ese caso, fija un canal no-DFS (del 36 al 48).
• Canal de extensión: Automático
  • El porqué: Es el canal secundario que se usa cuando se activa el ancho de banda de 80 MHz. Dejar que el router lo gestione automáticamente es lo más seguro.
• Método de autenticación: WPA2-Personal
  • Cómo debe estar: WPA2-Personal (o WPA3-Personal si todos tus dispositivos son modernos).
  • El porqué: Es el estándar de seguridad actual. El cifrado WPA2 con AES es obligatorio para poder alcanzar las velocidades del estándar AC.
• Cifrado WPA: AES
  • Cómo debe estar: AES.
  • El porqué: El cifrado TKIP está obsoleto y limita la velocidad de la red drásticamente. AES es el estándar moderno y seguro.
• Clave WPA precompartida: [Tu contraseña segura]
• Fotogramas de administración protegidos (PMF): Deshabilitar
  • Cómo debe estar: Deshabilitar (o Habilitar si usas WPA3).
  • El porqué: El PMF protege contra ataques de desconexión (deauth). Sin embargo, algunos dispositivos antiguos (o incluso algunos electrodomésticos modernos) no lo soportan y no se conectarán si lo activas. Si no usas WPA3, es mejor dejarlo deshabilitado para evitar problemas.
• Intervalo de rotación de la clave de red: 3600
  • El porqué: El router renueva la clave de cifrado interna cada hora (3600 segundos). Es un valor estándar, seguro y no afecta al rendimiento.

Parte 2: Configuración Profesional (Optimización de Red)

Aquí es donde se ajusta el comportamiento del router a nivel de radiofrecuencia. Esta pestaña está pensada para exprimir el hardware.

• Habilitar radio: Sí
  • El porqué: Enciende la señal inalámbrica de 5 GHz.
• Habilitar programador inalámbrico: No
  • El porqué: Permite programar apagados y encendidos (ej. por la noche). Desactivado significa que la red está encendida 24/7.
• Definir AP aislado: No
  • El porqué: Si se activa, los dispositivos conectados no pueden comunicarse entre sí. Es útil para redes de invitados, pero en tu red principal impediría que tu móvil hiciera casting al televisor o controlara dispositivos IoT.
• Asistente para itinerancia: Habilitar (-70 dBm)
  • Cómo debe estar: Habilitar (si usas repetidores o Mesh), Deshabilitar (si solo tienes un router).
  • El porqué: Esta función «expulsa» a los dispositivos que tienen muy mala señal (por debajo de -70 dBm) para obligarlos a buscar una mejor conexión, por ejemplo, en otro nodo de la red Mesh.
• Habilitar indagación IGMP: Habilitar
  • El porqué: (IGMP Snooping). Esencial si tienes servicios de televisión IPTV o muchos dispositivos enviando tráfico de multidifusión (multicast). Evita que el router sature la red enviando paquetes a dispositivos que no los necesitan.
• Tasa de multidifusión (Mbps): Automático
  • El porqué: Deja que el router decida la velocidad óptima para esos paquetes de multidifusión.
• AMPDU RTS: Habilitar / Umbral RTS: 2347
  • Cómo debe estar: Habilitar y 2347.
  • El porqué: El estándar. AMPDU agrupa paquetes para mayor eficiencia. El umbral 2347 indica el tamaño máximo de paquete que se envía sin solicitar permiso al canal. En redes 5 GHz limpias, no hay que tocarlo.
• Intervalo DTIM: 3
  • El porqué: Es el tiempo que los dispositivos en modo de bajo consumo (como smartphones) pueden «dormir». Un valor de 3 es un buen equilibrio entre el ahorro de batería y la recepción instantánea de notificaciones (Push).
• Intervalo de señalización: 100
  • El porqué: El router envía una señal de «¡Estoy aquí!» cada 100 ms para que los dispositivos lo encuentren rápido. Es el estándar.
• ¿Desea habilitar la ráfaga de transmisión? Deshabilitar
  • Cómo debe estar: Deshabilitar o Habilitar (prueba).
  • El porqué: (TX Bursting). Agrupa paquetes para enviarlos de golpe. En 5 GHz modernos, no suele aportar mejoras significativas y a veces puede generar microcortes con ciertos dispositivos. Dejarlo deshabilitado es más seguro.
• Habilitar WMM: Habilitar
  • Cómo debe estar: Obligatorio Habilitar.
  • El porqué: (Wi-Fi Multimedia). Es el sistema de Calidad de Servicio (QoS). Sin esto activado, tu router 5 GHz no pasará de 54 Mbps, independientemente de la tecnología que tenga. Prioriza el tráfico de voz y vídeo.
• Habilitar WMM sin confirmación: Deshabilitar
  • El porqué: Evita que se envíen datos sin esperar confirmación de recepción, lo que podría causar pérdida de paquetes. Mejor asegurar la integridad de los datos.
• Habilitar WMM APSD: Habilitar
  • El porqué: (Automatic Power Save Delivery). Ayuda a los dispositivos móviles (portátiles, tablets) a ahorrar batería gestionando eficientemente el tráfico.
• Optimizar la agregación AMPDU: Deshabilitar
  • El porqué: ¡Ojo a este ajuste! La agregación AMPDU junta varios paquetes en uno solo para enviarlos más rápido. Aumenta el throughput (velocidad bruta de descarga), pero aumenta la latencia (ping). Al tenerlo deshabilitado, estás priorizando una red más reactiva (ideal para gaming o videollamadas) a costa de perder un poco de velocidad punta.
• Esquema de modulación (Modulation Scheme): Up to MCS 11 (NitroQAM/1024-QAM)
  • Cómo debe estar: Al máximo posible.
  • El porqué: Esto permite la modulación de mayor densidad (1024-QAM), que es una característica del Wi-Fi 6, pero algunos routers la aplican a 5 GHz para exprimir el hardware. Si tus dispositivos son modernos, déjalo así.
• Equidad de tiempo de emisión: Habilitar
  • Cómo debe estar: Habilitar.
  • El porqué: (Airtime Fairness). Evita que un dispositivo antiguo o lento acapare el tiempo de antena del router. Asegura que todos los dispositivos tengan una oportunidad justa de transmitir, mejorando el rendimiento general de la red.
• 802.11ac Multi-User MIMO: Habilitar
  • Cómo debe estar: Habilitar.
  • El porqué: Permite que el router se comunique con múltiples dispositivos (hasta 4) simultáneamente en la misma frecuencia, en lugar de ir uno por uno.
• Beamforming explícito y Formación de haces universal: Habilitar
  • Cómo debe estar: Habilitar.
  • El porqué: Dirige la señal WiFi directamente hacia tus dispositivos en lugar de emitirla en todas direcciones. Mejora la intensidad de la señal y el alcance.
• Ajuste de la potencia de transmisión: Performance
  • Cómo debe estar: Performance (Máximo).
  • El porqué: Emite con la máxima potencia permitida. Como el 5 GHz tiene menos alcance que el 2.4 GHz, necesitas toda la potencia posible para cubrir bien tu hogar.

Conclusión

Esta configuración de 5 GHz está orientada al máximo rendimiento. La elección del ancho de canal de 80 MHz, el uso de un canal DFS (100) para evitar la congestión, y la desactivación de la optimización AMPDU (para priorizar la baja latencia) harán que tu red esté muy por encima de la red estándar de fábrica.

Si aplicas estos ajustes, tus consolas descargarán más rápido, tus películas en streaming no se pararán a cargar y la experiencia de navegación en general será mucho más fluida.

¿Te han surgido dudas con alguno de los parámetros? ¡Déjamelo en los comentarios!

Aunque el 5 GHz es indiscutiblemente más rápido, el 2.4 GHz sigue siendo el rey de la cobertura y la penetración de paredes. Sin embargo, es una banda muy ruidosa donde los microondas, el Bluetooth y los routers de tus vecinos compiten por el mismo espacio físico.

Aquí es donde surge el problema. Los firmwares de routers modernos (como AsusWRT) vienen de fábrica con ciertos parámetros de optimización pensados para redes de alto rendimiento. Estas funciones avanzadas, sumadas a la saturación del entorno, suelen saturar o confundir a los microcontroladores más económicos (como los populares ESP8266, ESP32 o chips de domótica simple). El resultado: desconexiones aleatorias, bucles de reconexión infinitos o fallos al intentar emparejar un nuevo dispositivo.

Dejar la configuración por defecto no es una opción si buscas una red sólida. En esta guía vamos a repasar paso a paso, y pantalla por pantalla, cada una de las opciones reales de los menús General y Professional de un router moderno. Utilizaremos una configuración real como ejemplo para explicarte no solo qué hace cada parámetro, sino por qué debes configurarlo de una manera específica para lograr una red de 2,4 GHz totalmente estable, reactiva y sin caídas.

Aviso: Es posible que algunos dispositivos IoT (como enchufes o cámaras) o equipos antiguos no detecten esta red de 2.4 GHz si no están bien configurados los canales o el modo inalámbrico. En los siguientes pasos explicamos cómo ajustar el router para evitar estos fallos de visibilidad.

Parte 1: Configuración General (Lo básico)

Esta es la primera pestaña que solemos ver. Aquí definimos la identidad y la seguridad de nuestra red.

• Habilitar Smart Connect (conexión inteligente): OFF (Desactivado)
  • Por qué: Smart Connect unifica las redes de 2.4 GHz y 5 GHz bajo un mismo nombre, dejando que el dispositivo decida a cuál conectarse. En teoría suena bien, pero en la práctica, muchos dispositivos (especialmente los de domótica baratos) se confunden y se conectan al 5 GHz (que tiene menos alcance), desconectándose. Separar las bandas con nombres distintos (ej. MiRed_2.4G y MiRed_5G) te da control total.
• Banda: 2.4 GHz
• Nombre de red (SSID):Cronos_2.4G
  • Por qué: Es fundamental añadir el sufijo «_2.4G» para que tú y tu familia sepáis a qué red os estáis conectando.
• Ocultar SSID: No
  • Por qué: Ocultar la red es un mito de seguridad. No evita que un hacker la encuentre, pero sí hace que tus dispositivos móviles gasten más batería buscándola desesperadamente y que tengas problemas para conectarte a nuevas redes.
• Modo Inalámbrico: Automático (con Protección brg y Disable 11b activados)
  • Por qué: El modo automático permite que el router use el estándar más alto posible (802.11n, ac o ax). Al marcar «Disable 11b» (Deshabilitar 11b), evitas que dispositivos obsoletos de hace 20 años ralenticen toda la red. La «Protección brg» (CTS-to-self) ayuda a que los dispositivos modernos no se pisen entre sí cuando hay dispositivos antiguos cerca.
• Ancho de banda del canal: 20 MHz
  • Por qué: Este es el ajuste más importante de la guía. Aunque el router te ofrezca 40 MHz (para ir «más rápido»), en 2.4 GHz esto es un error. Hay muy poco espectro. Usar 40 MHz hace que tu señal se solape con la de tus vecinos, creando interferencias masivas. 20 MHz garantiza estabilidad y menos latencia.
• Canal: 1 (o 6, u 11)
  • Por qué: En 2.4 GHz los canales se solapan. Los únicos tres canales que no se pisan entre sí son el 1, el 6 y el 11. Lo ideal es usar una app como WiFi Analyzer en el móvil y elegir de estos tres el que esté más vacío.
• Método de autenticación: WPA2-Personal
  • Por qué: Es el estándar de seguridad más compatible y seguro actualmente. (WPA3 es mejor, pero puede dar problemas con dispositivos IoT antiguos).
• Cifrado WPA: AES
  • Por qué: El cifrado TKIP está obsoleto. Usar AES es obligatorio para poder alcanzar las velocidades del estándar N. Además, tu contraseña se ve «Muy intensa», lo cual es perfecto.
• Fotogramas de administración protegidos (PMF): Deshabilitar
  • Por qué: Esta función (parte de WPA3) evita ataques de «desautenticación» (cuando alguien intenta desconectar tus dispositivos de la red). Si lo deshabilitas, ganas compatibilidad con dispositivos antiguos, aunque pierdes esa capa extra de seguridad. Si no tienes problemas, puedes probar a habilitarlo.
• Intervalo de rotación de la clave de red: 3600
  • Por qué: El router cambia la clave de cifrado interna cada 3600 segundos (1 hora). Esto es muy seguro y no afecta al rendimiento.

Parte 2: Configuración Profesional (Avanzado)

Aquí es donde se separa a los aficionados de los expertos. Esta pestaña controla cómo el router gestiona el tráfico de radiofrecuencia.

• Habilitar radio: Sí
  • Por qué: Obvio, es el interruptor principal del WiFi.
• Habilitar programador inalámbrico: No
  • Por qué: Te permitiría apagar el WiFi a ciertas horas (por ejemplo, por la noche). Útil si quieres ahorrar energía o controlar el uso de internet de los niños.
• Definir AP aislado: No
  • Por qué: Si lo activaras, los dispositivos conectados al WiFi no podrían comunicarse entre sí (por ejemplo, tu móvil no podría controlar tus bombillas inteligentes). Solo se usa en redes de invitados.
• Asistente para itinerancia: Habilitar (Desconectar clientes con RSSI inferior a: -70 dBm)
  • Por qué: Esta es una función de «Malla» (Mesh). Si tienes un dispositivo conectado al router con muy mala señal (por debajo de -70 dBm, que es un límite bastante estricto), el router lo desconectará a la fuerza para obligarlo a buscar una señal mejor (por ejemplo, conectarse a un repetidor o a un nodo Mesh cercano).
• Bluetooth Coexistence: Deshabilitar
  • Por qué: Si tienes dispositivos Bluetooth muy cerca del router (altavoces, auriculares), el WiFi y el Bluetooth se interfieren porque usan la misma frecuencia. Activarlo hace que el router «ceda el paso». Si no tienes problemas de interferencia Bluetooth, es mejor dejarlo deshabilitado para que el WiFi no pierda rendimiento.
• Habilitar indagación IGMP: Habilitar
  • Por qué: Indispensable para gestionar el tráfico de «multidifusión» (Multicast). Si tienes IPTV (televisión por internet) o muchos dispositivos inteligentes, esto evita que el router inunde la red enviando paquetes a dispositivos que no los necesitan.
• Tasa de multidifusión: Automático
  • Por qué: Deja que el router decida la velocidad para ese tráfico de multidifusión.
• Tipo de preámbulo: Corto
  • Por qué: El preámbulo es la «cabecera» de los paquetes de datos. Un preámbulo «Corto» (Short Preamble) es más eficiente y reduce la sobrecarga (overhead), mejorando ligeramente el rendimiento en redes modernas. Solo usa «Largo» si tienes dispositivos muy antiguos de 802.11b.
• AMPDU RTS: Habilitar / Umbral RTS: 2347
  • Por qué: El umbral RTS es el tamaño máximo de paquete que se puede enviar sin pedir permiso al aire. 2347 es el valor por defecto y está bien. Si tuvieras una red muy congestionada y con muchos microcortes, podrías bajarlo a 2304 para forzar al router a «pedir turno» antes de enviar paquetes grandes, evitando colisiones.
• Intervalo DTIM: 3
  • Por qué: El DTIM (Delivery Traffic Indication Message) indica a los dispositivos (como tu móvil) cada cuántos «beacons» (señales de baliza) deben despertar para ver si hay datos nuevos. Un valor de 3 significa que el móvil se puede dormir profundamente durante 3 ciclos, ahorrando batería. Si tienes problemas de notificaciones retrasadas en el móvil, bájalo a 2.
• Intervalo de señalización: 100
  • Por qué: Cada cuántos milisegundos (ms) el router grita «¡Estoy aquí!» para que los dispositivos lo encuentren. 100 ms es el estándar perfecto.
• ¿Desea habilitar la ráfaga de transmisión? Habilitar
  • Por qué: (Frame Bursting). Permite al router enviar varios paquetes de datos seguidos sin soltar el control del aire, mejorando la velocidad de transferencia.
• Habilitar WMM: Habilitar
  • Por qué: (Wi-Fi Multimedia). Es un sistema de Calidad de Servicio (QoS). Prioriza el tráfico importante (como una videollamada o un juego online) sobre las descargas masivas. Sin WMM activado, tu WiFi no pasará de 54 Mbps.
• Habilitar WMM sin confirmación: Deshabilitar
  • Por qué: Enviar datos «sin confirmación» es más rápido pero arriesgado (si el paquete se pierde, se pierde para siempre). Mejor mantenerlo deshabilitado para asegurar que los datos lleguen íntegros.
• Habilitar WMM APSD: Habilitar
  • Por qué: (Automatic Power Save Delivery). Ayuda a los dispositivos móviles a ahorrar batería al gestionar mejor cuándo pueden dormir y cuándo deben recibir datos.
• Optimizar la agregación AMPDU: Deshabilitar
  • Por qué: La agregación AMPDU junta varios paquetes en uno solo para enviarlos. Aumenta la velocidad bruta, pero también aumenta la latencia (ping). Como lo tienes deshabilitado, estás priorizando una conexión más reactiva (bueno para gaming), aunque si quieres maximizar la velocidad de descarga en 2.4GHz, podrías probar a habilitarlo.
• Modulation Scheme (Esquema de modulación): Up to MCS 11 (NitroQAM/1024-QAM)
  • Por qué: Esto es tecnología Wi-Fi 6 aplicada a 2.4 GHz. Permite meter más datos en la misma onda. Está perfecto si tus dispositivos son modernos. Si tuvieras dispositivos que se desconectan, podrías bajarlo a MCS 9 (256-QAM).
• Unidad de tiempo de emisión (TXOP): Deshabilitar
  • Por qué: El TXOP permite a un dispositivo acaparar el canal durante un tiempo determinado. En 2.4 GHz suele dar más problemas que beneficios, así que está bien deshabilitado.
• 802.11ac Multi-User MIMO: Habilitar
  • Por qué: MU-MIMO permite al router hablar con varios dispositivos a la vez. Ojo: El estándar 802.11ac es exclusivo de 5 GHz. En 2.4 GHz esta opción técnicamente no hace nada, pero no molesta dejarla activada. En Wi-Fi 6 (802.11ax) sí que tiene efecto en 2.4 GHz.
• Beamforming explícito y Formación de haces universal: Habilitar
  • Por qué: En lugar de emitir la señal en todas direcciones (como una bombilla), el router detecta dónde está tu móvil y «dirige» un haz de señal concentrado directamente hacia él. Mejora el alcance y la velocidad.
• Ajuste de la potencia de transmisión: Performance (Rendimiento)
  • Por qué: Al ponerlo al máximo (Performance), el router emitirá con toda su potencia. Es lo ideal para cubrir toda la casa. (Nota: Si vives en un piso muy pequeño y la señal es tan fuerte que no te deja cambiar al 5 GHz, podrías bajarlo, pero por norma general, máximo es mejor).

Resumen de la configuración recomendada

Conclusión

Como has visto, cada ajuste tiene su justificación. Esta configuración es ideal si priorizas la estabilidad frente a la velocidad bruta (ancho de canal de 20 MHz), evitas dispositivos obsoletos (11b deshabilitado) y mantienes la seguridad actualizada (WPA2/AES).

Si aplicas estos ajustes, tu red de 2,4 GHz dejará de ser ese «WiFi lento» que todos evitan y se convertirá en una red sólida, fiable y con una cobertura excelente en todos los rincones del hogar.

Con estos ajustes en AsusWRT, la banda de 2,4 GHz se convierte en una red muy robusta: eliminamos algoritmos innecesarios que saturan microcontroladores de recursos limitados y garantizamos la máxima estabilidad para la domótica del hogar.

¿Tienes dudas sobre algún otro parámetro de tu router? Déjalas en los comentarios.

Esta guía está actualizada para Debian 13 (Trixie) y MX Linux 25, y tiene en cuenta los cambios importantes que han llegado con la versión 4.x de Transmission. Si seguiste la guía Inicia transmission-daemon con systemd en Debian 12, es muy probable que te hayas encontrado con que el servicio no arranca correctamente. Aquí te explico paso a paso cómo hacerlo bien, con las mejores prácticas actuales y dos rutas de instalación según tu sistema operativo.

1. Instalación del paquete (elige tu ruta)

Lo primero es actualizar la lista de paquetes.

sudo apt update

A partir de aquí, el procedimiento cambia según el sistema que uses.

Ruta A: Debian 13 puro o Raspberry Pi OS (Trixie) → usa backports

Este es el punto más importante y el que más confusiones genera. Debian 13 incluye en sus repositorios principales una versión beta de Transmission, concretamente la 4.1.0~beta2. Si instalas el paquete sin más, apt te dará esa beta, que arrastra errores conocidos y puede provocar cuelgues inesperados o problemas al guardar la configuración.

La solución oficial es instalar la versión estable desde los backports de Debian 13. Allí encontrarás la versión 4.1.3, que corrige los problemas de la beta y añade parches importantes. Además, esta versión evita un problema conocido de las versiones 4.1.0 y 4.1.1 que provocaba que algunos trackers bloquearan al cliente por un flujo excesivo de peticiones.

“Nota para Raspberry Pi OS: aunque los backports de Debian funcionan en la arquitectura arm64, esta combinación no está soportada oficialmente por la Fundación Raspberry Pi. Úsala bajo tu propio riesgo y, si puedes, haz una copia de seguridad antes.”

Paso 1: Añade el repositorio de backports (si no lo tienes ya).

echo "deb http://ftp.de.debian.org/debian trixie-backports main" | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update

Paso 2: Instala el paquete indicando explícitamente que quieres la versión de backports.

sudo apt install -t trixie-backports transmission-daemon

Esta es la opción más recomendada si usas Debian 13 o Raspberry Pi OS.

Ruta B: MX Linux 25 → instala directamente

Si usas MX Linux 25 (basado en Debian 13), la situación es mucho más sencilla. MX Linux empaqueta su propia versión de Transmission en su repositorio, y la versión actual (4.1.0+dfsg-1~mx25+1) ya es estable, no es una beta. No necesitas añadir los backports de Debian, ya que podrías crear conflictos de paquetes con el sistema de MX.

Simplemente instala el paquete con normalidad:

sudo apt install transmission-daemon

Importante: No mezcles repositorios. Si usas MX Linux, mantente dentro de sus repositorios oficiales. Si usas Debian puro, usa los backports de Debian. Mezclar ambos puede romper dependencias.

2. El paso crítico: arreglar el servicio systemd

Aquí está el cambio más importante respecto a guías anteriores, y afecta tanto a Debian 13 como a MX Linux 25. La unidad de systemd que viene por defecto usa Type=notify, pero con Transmission 4.x esto ya no funciona bien. El demonio se inicia correctamente, pero no notifica a systemd cuando está listo, por lo que systemd cree que ha fallado y acaba matándolo tras un tiempo de espera (timeout).

La solución es crear un archivo de override (anulación) para cambiar el tipo de servicio a simple, sin tocar el archivo original del sistema. Es un procedimiento limpio y persistente que sobrevive a las actualizaciones del paquete.

Ejecuta:

sudo systemctl edit transmission-daemon.service

Se abrirá un editor. Añade las siguientes líneas:

[Service]
Type=simple

Guarda y cierra. Luego recarga systemd para que aplique el cambio:

sudo systemctl daemon-reload

Con esto, el servicio ya debería arrancar y mantenerse activo sin problemas.

3. Endurecimiento (hardening) del servicio

Transmission 4.x ya incluye algunas opciones de seguridad por defecto, pero podemos añadir más capas de protección. Un demonio que acepta conexiones de red siempre es un objetivo interesante, así que vale la pena blindarlo un poco.

Vuelve a abrir el editor de override:

sudo systemctl edit transmission-daemon.service

Y añade estas directivas de seguridad dentro de la sección [Service], junto al Type=simple que ya pusiste:

# Hardening
NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=full
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictRealtime=true

¿Qué hace cada directiva?

Cada línea del bloque anterior es una capa de aislamiento que systemd aplica al proceso de Transmission. Ninguna es imprescindible por sí sola, pero juntas reducen drásticamente lo que un atacante podría hacer si encontrara una vulnerabilidad en el demonio.

• NoNewPrivileges=true: Impide que el proceso (o cualquiera de sus hijos) pueda obtener privilegios adicionales a través de execve(), como los bits setuid/setgid o las capabilities del sistema de archivos. Es una de las protecciones más básicas y efectivas.
• PrivateTmp=true: Crea directorios /tmp y /var/tmp privados para el servicio, aislados del resto del sistema. Así, otros procesos no pueden leer ni manipular los archivos temporales que genere Transmission.
• PrivateDevices=true: Proporciona un sistema de archivos /dev mínimo y privado, con solo los dispositivos pseudo-API esenciales (/dev/null, /dev/zero, etc.). El servicio pierde acceso a discos, cámaras, GPUs y cualquier otro dispositivo físico real.
• ProtectSystem=full: Monta /usr, /boot y /efi como solo lectura, y además hace lo mismo con /etc. Esto significa que el proceso no puede modificar los binarios del sistema ni la configuración global, limitando el daño si se ve comprometido.
• ProtectHome=true: Hace que los directorios /home y /run/user sean completamente inaccesibles para el servicio. Es la directiva que ya te advertí que puede chocar con tus rutas de descarga si están dentro de una carpeta personal.
• ProtectKernelTunables=true: Hace que las variables del kernel expuestas en /proc/sys/, /sys/ y rutas similares sean de solo lectura para el proceso. Evita que Transmission pueda alterar parámetros críticos del sistema en tiempo de ejecución.
• ProtectKernelModules=true: Deniega explícitamente la carga y descarga de módulos del kernel. Un cliente de torrents no necesita cargar controladores, así que esto cierra una vía de escalada de privilegios.
• ProtectControlGroups=true: Hace que la jerarquía de cgroups (/sys/fs/cgroup) sea de solo lectura para el servicio. Impide que el proceso manipule los grupos de control del sistema, que son un mecanismo habitual para intentar escapar de un contenedor o de un sandbox.
• RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6: Limita los tipos de sockets que el proceso puede crear. Solo se permiten tres familias: AF_UNIX (comunicación local), AF_INET (IPv4) y AF_INET6 (IPv6). Se bloquean así familias más exóticas como AF_PACKET (acceso a paquetes en crudo), que a menudo se usan en exploits.
• RestrictRealtime=true: Rechaza cualquier intento de activar políticas de planificación en tiempo real (SCHED_FIFO, SCHED_RR, etc.). Un cliente de torrents no necesita prioridad de tiempo real, y permitirla podría usarse para agotar la CPU y afectar al resto del sistema.

Notas:
ProtectSystem=full es un buen equilibrio para Transmission: protege las rutas del sistema pero deja escribibles /var y /srv, donde podrías tener tus descargas. Si prefieres un aislamiento aún mayor y tus descargas están en un disco externo montado aparte, podrías probar ProtectSystem=strict, que monta todo el árbol de archivos como solo lectura salvo /dev, /proc y /sys. Requiere ajustar permisos con ReadWritePaths para las carpetas de descarga.

ProtectHome=true: esta opción impide el acceso a los directorios dentro de /home. Si tus descargas van a una carpeta en tu home, tendrás que ajustar esta opción o usar BindPaths para dar acceso solo a la carpeta concreta. Si tus descargas van a un disco externo montado en /mnt, /srv o similar, no habrá problema.

NoNewPrivileges=true: Impedirá que Transmission ejecute scripts (por ejemplo, para enviar notificaciones) En ese caso, tendrás que ponerlo a false en el override o buscar una alternativa externa.

Guarda, recarga:

sudo systemctl daemon-reload

y luego reinicia:

sudo systemctl restart transmission-daemon

4. Configuración básica (settings.json)

El archivo de configuración principal está en /etc/transmission-daemon/settings.json. Nunca lo edites con el servicio en marcha, porque Transmission sobrescribirá tus cambios al apagarse. Sigue siempre este orden:

Para el servicio con:

sudo systemctl stop transmission-daemon

Edita el servicio con:

sudo nano /etc/transmission-daemon/settings.json

Aquí tienes las opciones más importantes que deberías revisar.

Directorios de descarga

Busca las líneas download-dir y, si quieres, incomplete-dir:

"download-dir": "/ruta/a/tus/descargas",
"incomplete-dir": "/ruta/a/tus/descargas/incompletos",
"incomplete-dir-enabled": true,

Si prefieres que los archivos se descarguen directamente a su destino final, pon "incomplete-dir-enabled": false.

Interfaz web (RPC)

Para poder controlar Transmission desde el navegador o un cliente remoto, necesitas configurar el RPC. Este es un punto crítico de seguridad: no expongas el RPC sin autenticación.

"rpc-enabled": true,
"rpc-bind-address": "0.0.0.0",
"rpc-port": 9091,
"rpc-whitelist-enabled": true,
"rpc-whitelist": "127.0.0.1,192.168.1.*",
"rpc-authentication-required": true,
"rpc-username": "tu_usuario",
"rpc-password": "tu_contraseña",

¿Qué hace cada directiva de la interfaz web (RPC)?

Estas opciones controlan cómo se accede a Transmission de forma remota, ya sea desde el navegador o mediante herramientas como transmission-remote. Configurarlas bien es clave para no exponer el servicio sin protección.

• "rpc-enabled": true
  Activa o desactiva por completo el servidor RPC (la interfaz de control remoto). Si está en false, nadie podrá conectarse a Transmission desde fuera, aunque el resto de opciones estén configuradas. Es el interruptor maestro.
• "rpc-bind-address": "0.0.0.0"
  Define en qué dirección IP de tu máquina “escucha” el servidor RPC. Con "0.0.0.0" escucha en todas las interfaces de red disponibles. Si solo quieres acceso local, usa "127.0.0.1". Si usas WireGuard, aquí deberías poner la IP de tu interfaz VPN (por ejemplo, "10.0.0.1").
• "rpc-port": 9091
  Es el puerto de red que Transmission usará para el RPC. El valor 9091 es el estándar, pero puedes cambiarlo si tienes conflictos con otro servicio. Si lo cambias, recuerda usar el nuevo puerto al acceder desde el navegador.
• "rpc-whitelist-enabled": true
  Activa o desactiva la “lista blanca” de direcciones IP. Si está en true, solo las IPs que aparezcan en rpc-whitelist podrán conectarse. Es una capa de seguridad importante, incluso si tienes autenticación activada.
• "rpc-whitelist": "127.0.0.1,192.168.1.*"
  Es la lista de IPs o rangos de IP permitidos. Admite comodines con *. En el ejemplo, se permite el acceso desde la propia máquina (127.0.0.1) y desde cualquier dispositivo de la red local 192.168.1.x. Nunca uses "*" si el servicio es accesible desde internet.
• "rpc-authentication-required": true
  Obliga a que los clientes se identifiquen con un usuario y contraseña para poder usar el RPC. Es imprescindible si vas a acceder desde fuera de tu red local o a través de una VPN, porque la whitelist por sí sola no protege contra alguien que ya esté dentro de tu red (o que falsifique una IP).
• "rpc-username": "tu_usuario"
  El nombre de usuario que se pedirá en el formulario de acceso. Elige uno que no sea obvio (evita admin o transmission).
• "rpc-password": "tu_contraseña"
  La contraseña asociada a ese usuario. Importante: puedes escribirla en texto plano en el archivo, pero Transmission la cifrará automáticamente la primera vez que arranque el servicio. A partir de ese momento, en settings.json verás una cadena con un { al principio, no tu contraseña original. Por eso es crucial que hagas los cambios con el servicio detenido: si lo editas mientras corre, al apagarse sobrescribirá el archivo y perderás los cambios.

Un detalle sobre la seguridad: la combinación de rpc-whitelist + rpc-authentication-required es la que te da una protección real. La whitelist filtra por origen, y la autenticación añade una barrera incluso si alguien logra saltarse ese filtro (por ejemplo, desde dentro de tu propia red). Para acceso remoto, la opción más segura sigue siendo WireGuard, como explicamos en la sección 6.b.

Si vas a acceder a través de WireGuard (ver sección 6), es más seguro cambiar rpc-bind-address por la IP de tu interfaz VPN (por ejemplo, "10.0.0.1") en lugar de "0.0.0.0". Lo explico en detalle en el apartado 6.b.

Otras opciones útiles

"ratio-limit": 2.0,
"ratio-limit-enabled": true,
"idle-seeding-limit": 30,
"idle-seeding-limit-enabled": true,
"speed-limit-up": 1000,
"speed-limit-up-enabled": true,

¿Qué hace cada directiva de límites?

Estas opciones controlan el comportamiento de Transmission una vez que un torrent ha terminado de descargarse, y también cuánto ancho de banda puede usar. Son fundamentales para mantener tu equipo bajo control y no saturar la conexión.

• "ratio-limit": 2.0
  Define la proporción de subida (ratio) a la que se dejará de sembrar un torrent. El ratio se calcula dividiendo los datos subidos entre los datos descargados. Un valor de 2.0 significa que subirás el doble de lo que has descargado. Un ratio de 1.0 es el mínimo para ser un “buen ciudadano” en la red BitTorrent; 2.0 se considera un buen equilibrio. Por defecto, si no se activa, los torrents se siembran indefinidamente.
• "ratio-limit-enabled": true
  Activa o desactiva el límite de ratio. Si está en true, el torrent se pausará automáticamente cuando alcance el valor de ratio-limit. Si está en false, el límite se ignora y el torrent seguirá sembrando sin fin (a menos que actúen otros límites como el de inactividad).
• "idle-seeding-limit": 30
  Establece el tiempo máximo de inactividad (en minutos) que un torrent puede estar sembrando sin subir datos antes de ser pausado. 30 minutos es un valor razonable para liberar recursos de torrents que ya no interesan a nadie.
• "idle-seeding-limit-enabled": true
  Activa o desactiva el límite por inactividad. Si está en true, se aplica el tiempo definido en idle-seeding-limit. Si está en false, el torrent puede estar sembrando sin actividad indefinidamente, sin pausarse por este motivo.
• "speed-limit-up": 1000
  Define la velocidad máxima de subida en kilobytes por segundo (KB/s). El valor 1000 equivale aproximadamente a 1 MB/s. Este límite solo se aplica si speed-limit-up-enabled está activado. Es útil para evitar que Transmission acapare todo el ancho de banda de subida de tu conexión y afecte a otros servicios.
• "speed-limit-up-enabled": true
  Activa o desactiva el límite de velocidad de subida. Si está en true, la velocidad de subida se limitará al valor de speed-limit-up. Si está en false, la subida será ilimitada (hasta el máximo que permita tu conexión y los peers).

Un detalle importante: ratio-limit e idle-seeding-limit pueden entrar en conflicto. Si un torrent alcanza el ratio límite, se pausa por ratio; si deja de subir datos, se pausa por inactividad. El primero en alcanzarse es el que se aplica. Configurar ambos te da un control más fino sobre cuándo deja de sembrar Transmission.

Cuando termines de editar, guarda el archivo y arranca el servicio de nuevo:

sudo systemctl start transmission-daemon

5. Gestión del servicio

Ahora que todo está configurado, estos son los comandos que usarás habitualmente:

# Ver el estado del servicio
sudo systemctl status transmission-daemon

# Detenerlo
sudo systemctl stop transmission-daemon

# Reiniciarlo (por ejemplo, tras editar settings.json)
sudo systemctl restart transmission-daemon

Si quieres que se inicie automáticamente al arrancar el sistema:

sudo systemctl enable transmission-daemon

6. Acceso remoto a la interfaz web: router vs. WireGuard

Por defecto, la interfaz web de Transmission (el RPC) solo escucha en 127.0.0.1, lo que significa que solo es accesible desde la propia Raspberry Pi. Para poder controlarlo desde otro dispositivo, tienes dos caminos:

• 6.a. Exponer el puerto a internet, Abrir el puerto 9091 en el router.
• 6.b. Acceder a través de una VPN. Acceder a través de tu VPN WireGuard.
  La diferencia en seguridad entre ambos es enorme.

6.a. Abrir el puerto 9091 en el router (no recomendado)

Esta es la vía rápida y la que usaban muchas guías antiguas. Consiste en hacer que Transmission escuche en todas las interfaces y redirigir el puerto 9091 en tu router para que sea accesible desde fuera de tu red local.

Pasos:

Detén el servicio con:

sudo systemctl stop transmission-daemon

Modifica el archivo settings.json:

sudo nano /etc/transmission-daemon/settings.json

cambia rpc-bind-address para que escuche en todas las interfaces:

"rpc-bind-address": "0.0.0.0",

La rpc-whitelist es tu única barrera si expones el puerto. Si tu IP pública es dinámica, tendrías que añadirla manualmente cada vez, o desactivar la whitelist por completo ("rpc-whitelist-enabled": false), lo cual es muy peligroso. Una alternativa algo más segura es mantener la whitelist activada con los rangos de tu red local y añadir tu IP pública actual, pero no es una solución estable.

Guarda, arranca el servicio

sudo systemctl start transmission-daemon

Ahora redirige el puerto 9091/TCP en tu router hacia la IP local de la Raspberry Pi. La forma exacta depende de cada modelo de router.

Accede desde fuera con

http://tu-dominio.duckdns.org:9091 (o tu IP pública).

¿Por qué no te lo recomiendo?

• Transmission habla HTTP en texto plano por defecto. Tus credenciales de acceso viajan sin cifrar. Cualquiera que intercepte el tráfico (tu operadora, un WiFi público, un atacante en tu misma red) puede leer tu usuario y contraseña.
• Los bots escanean internet constantemente. En cuanto el puerto 9091 esté abierto, empezarás a recibir intentos de login automatizados. Transmission tiene autenticación, pero no está diseñado para estar expuesto directamente a internet.
• Superficie de ataque directa. Cualquier vulnerabilidad que se descubra en el RPC de Transmission quedará expuesta sin ninguna capa intermedia que filtre.

6.b. Acceder a través de tu VPN WireGuard (recomendado)

Esta es la opción que yo mismo uso y la que te recomiendo sin dudarlo. Si ya tienes montada una VPN WireGuard en tu Raspberry Pi —como expliqué en la entrada WireGuard en Raspberry Pi: VPN casera, segura y gratuita—, ya tienes hecha la mitad del trabajo. La idea es muy sencilla: en lugar de exponer Transmission a internet, te conectas primero a tu VPN y luego accedes a la interfaz web como si estuvieras dentro de tu red local. Todo el tráfico viaja cifrado por el túnel de WireGuard.

Ventajas frente a abrir el puerto:

• Cifrado de extremo a extremo. Todo el tráfico entre tu dispositivo y la Raspberry Pi viaja cifrado por WireGuard.
• No expones ningún servicio a internet. Transmission sigue escuchando únicamente en la interfaz de la VPN. Los bots y escáneres no tienen nada a lo que atacar.
• Una sola puerta de entrada. Ya tienes WireGuard como punto de acceso seguro a tu red doméstica. Aprovecharlo para Transmission es lo lógico.
• Funciona desde cualquier dispositivo: móvil, portátil, tablet… Solo necesitas el cliente WireGuard y tu configuración.

Pasos:

Conéctate a tu VPN desde el dispositivo que vayas a usar.

Detén el servicio con:

sudo systemctl stop transmission-daemon

En settings.json

sudo nano /etc/transmission-daemon/settings.json

Haz que Transmission escuche en la IP de la interfaz de la VPN. Si tu servidor WireGuard usa la IP 10.0.0.1, la configuración sería:

"rpc-bind-address": "10.0.0.1",

Nota: Podrías usar "0.0.0.0" para escuchar en todas las interfaces, pero limitarlo a la IP de la VPN es más seguro, porque la única vía de acceso será el túnel. El inconveniente es que no podrás entrar localmente desde dispositivos que estén fuera de la VPN.

Ajusta la rpc-whitelist para permitir las IPs de tus clientes VPN. Si tu subred de WireGuard es 10.0.0.0/24, puedes usar un comodín:

"rpc-whitelist": "10.0.0.*",

Nota: También puedes incluir 127.0.0.1 por si en algún momento necesitas acceso local: "rpc-whitelist": "127.0.0.1,10.0.0.*",

Guarda el archivo, arranca el servicio:

sudo systemctl start transmission-daemon

Accede desde el navegador, ya conectado a la VPN, con la dirección privada de tu Raspberry Pi:

http://10.0.0.1:9091

Introduce tus credenciales y tendrás acceso completo a la interfaz web de Transmission. Al ir todo por el túnel de WireGuard, la velocidad dependerá de tu conexión, pero para gestionar descargas y añadir torrents es más que suficiente.

7. Solución de problemas comunes

El servicio no arranca y da un timeout

Ya lo hemos solucionado en el paso 2, pero si te encuentras con esto en otro equipo, la causa casi seguro es el Type=notify. Verifica que tu archivo de override esté correctamente aplicado:

systemctl cat transmission-daemon.service

Deberías ver tu override.conf con Type=simple al final de la salida.

Error de permisos en settings.json

A veces, el usuario debian-transmission no tiene permisos suficientes sobre el archivo. Verifícalo:

ls -la /etc/transmission-daemon/settings.json

El propietario debería ser debian-transmission:debian-transmission. Si no lo es, corrígelo:

sudo chown debian-transmission:debian-transmission /etc/transmission-daemon/settings.json

No puedo acceder a la interfaz web

• Verifica que rpc-enabled esté en true.
• Comprueba que rpc-bind-address sea "0.0.0.0" si accedes desde otra máquina.
• Revisa que tu IP esté en la whitelist. Si instalaste desde backports, es posible que la whitelist esté activada por defecto y tu IP no esté incluida.
• Asegúrate de que el puerto 9091 esté abierto en el firewall.
• Si ves un error 403 Forbidden, casi siempre es la whitelist o la autenticación.

Conclusión

Transmission sigue siendo una opción excelente para gestionar torrents en un servidor Debian o MX Linux. Los puntos clave para una instalación sin problemas en 2026 son:

1. Elige bien tu ruta de instalación: si usas Debian 13 puro, instala desde trixie-backports para evitar la beta; si usas MX Linux 25, el paquete por defecto ya es estable.
2. Crea un override de systemd para cambiar Type=notify a Type=simple. Esto es imprescindible en ambos sistemas.
3. Añade opciones de hardening para proteger el servicio.
4. Configura bien el RPC si vas a acceder remotamente, con autenticación y whitelist.

Con estos pasos, tendrás un demonio de Transmission funcionando de forma estable y segura. Si te surge alguna duda, ¡déjamela en los comentarios!

En esta guía vamos a hacer una instalación completa desde cero en una Raspberry Pi 5 con Debian 13 (Trixie), aprovechando todas las mejoras y siguiendo las buenas prácticas que ya aplicábamos antes: usuario dedicado, permisos compartidos mediante SGID y servicios systemd.

Si vienes de la guía anterior, verás que el esqueleto es el mismo, pero con las novedades integradas.

¡¡Vamos al lío!!

¿Qué hay de nuevo en aMule 3.1.0?

Antes de empezar, un repaso rápido a lo más relevante, porque justifica de sobra la actualización:

• amuleapi: un nuevo daemon que expone una API REST y sirve una interfaz web completamente nueva. Es responsive, tiene modo claro/oscuro, actualizaciones en tiempo real vía SSE y permite gestionar todo aMule desde el navegador, incluyendo la descarga directa de archivos terminados.
• Modo «Endgame» mejorado: los bloques finales se solicitan a múltiples fuentes a la vez, evitando el clásico estancamiento al 99%.
• Cifrado en las conexiones externas (EC): la comunicación entre amuled y los clientes remotos (amulegui, amuleapi) ahora está cifrada con ChaCha20-Poly1305 o AES-128-GCM.
• Fuga de memoria corregida en el daemon, algo que notábamos mucho en ejecuciones prolongadas.
• Listas modernas en la GUI de escritorio, migradas a wxDataViewCtrl.
• Límites de Kad aumentados y profundidad de peticiones ajustada dinámicamente según el ancho de banda.

Si todo esto te parece suficiente, vamos a instalarlo.

Este manual se compone de los siguientes pasos:

1. Instalación de dependencias
2. Creación del usuario dedicado amule
3. Preparación de directorios y permisos compartidos (SGID)
4. Descarga del código fuente
5. Configuración de la compilación con CMake
6. Compilación e instalación
7. Primer arranque de amuled y generación de configuración
8. Servicios systemd
9. Acceso a la nueva interfaz web
10. Gestión de los servicios

Requisitos previos

• Raspberry Pi 5 con Debian 13 (Trixie).
• Disco externo (en mi caso, un disco mécanico de 1 TB montado en /media/Disco_1TB) donde guardaremos descargas y temporales. Ajusta las rutas a tu caso.
• Acceso a terminal con un usuario con privilegios sudo (en mi caso, raspberry).
• WireGuard en Raspberry PI, VPN casera, segura y gratuita. (opcional, pero recomendable)

1. Instalación de dependencias

Lo primero, como siempre, dejar el sistema al día:

sudo apt update && sudo apt full-upgrade -y

aMule 3.1.0 sigue usando wxWidgets 3.2 y Crypto++ 8.1, así que las dependencias son las mismas que en la versión anterior. Instalamos todo lo necesario para compilar con soporte completo:

sudo apt install -y \
  binutils-dev \
  build-essential \
  cmake \
  gettext \
  git \
  libayatana-appindicator3-dev \
  libboost-all-dev \
  libcrypto++-dev \
  libgd-dev \
  libglib2.0-dev \
  libmaxminddb-dev \
  libreadline-dev \
  libupnp-dev \
  libwxgtk3.2-dev \
  pkg-config \
  wx3.2-headers \
  zlib1g-dev

Si tienes cualquier duda sobre las dependencias, la documentación oficial de compilación las lista todas.

2. Creación del usuario dedicado amule

Este es un paso crítico que ya aplicábamos en la guía anterior:
aMule no debe ejecutarse con tu usuario personal. Le creamos una cuenta de sistema dedicada, sin shell de login y con su propio directorio home.
Así, si alguien comprometiera el daemon, no tendría acceso al resto del sistema.

sudo adduser --system --group --home /home/amule --shell /usr/sbin/nologin amule

• --system: cuenta de sistema, no de persona.
• --group: crea también el grupo amule.
• --home /home/amule: home dedicado, donde vivirá toda la configuración de aMule.
• --shell /usr/sbin/nologin: bloquea cualquier intento de login con esta cuenta.

3. Preparación de directorios y permisos compartidos (SGID)

Si vas a usar un disco duro externo para tus descargas, es posible que necesites echar un vistazo a la Guía completa: Montar particiones al inicio en Debian

Para que tú, desde tu usuario raspberry, puedas gestionar las descargas sin pelearte con permisos, usaremos el truco del bit SGID sobre las carpetas compartidas. Así todos los archivos que cree aMule heredarán el grupo amule y tú podrás acceder a ellos por pertenencia a ese grupo.

Primero, añade tu usuario al grupo amule:

sudo usermod -aG amule raspberry

Importante: cierra la sesión y vuelve a entrar, o ejecuta newgrp amule en la terminal, para que el sistema reconozca el nuevo grupo. Si no, los permisos no se aplicarán hasta el próximo login.

Ahora crea las carpetas de descargas en el disco externo (ajusta la ruta /media/Disco_1TB/aMule a tu caso):

sudo mkdir -p /media/Disco_1TB/aMule/Incoming
sudo mkdir -p /media/Disco_1TB/aMule/Temp

Asigna la propiedad al usuario y grupo amule, aplica permisos 775 y activa el bit SGID:

sudo chown -R amule:amule /media/Disco_1TB/aMule
sudo chmod -R 775 /media/Disco_1TB/aMule
sudo chmod g+s /media/Disco_1TB/aMule
sudo chmod g+s /media/Disco_1TB/aMule/Incoming
sudo chmod g+s /media/Disco_1TB/aMule/Temp

Con esto, cualquier archivo nuevo que se cree dentro heredará automáticamente el grupo amule, y tú podrás gestionarlo sin problemas.

4. Descarga del código fuente

Clonamos el repositorio oficial y nos situamos en la rama de la versión 3.1.0:

cd ~
git clone --branch 3.1.0 https://github.com/amule-org/amule.git amule-3.1.0
cd amule-3.1.0

Nota: Git te avisará de que estás en estado «detached HEAD». Es totalmente normal: estás apuntando a una etiqueta (tag) concreta, no a una rama. No es un error y no afecta a la compilación.

5. Configuración de la compilación con CMake

Aquí está una de las ventajas de compilar en casa: podemos optimizar el binario específicamente para la arquitectura de la Raspberry Pi 5. Usamos las mismas banderas que ya conoces, que exprimen el Cortex-A76 y las extensiones criptográficas:

cmake -B build \
  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_C_FLAGS="-O3 -march=armv8.2-a+crypto -mtune=cortex-a76 -pipe" \
  -DCMAKE_CXX_FLAGS="-O3 -march=armv8.2-a+crypto -mtune=cortex-a76 -pipe" \
  -DBUILD_MONOLITHIC=NO \
  -DBUILD_DAEMON=YES \
  -DBUILD_AMULECMD=YES \
  -DBUILD_AMULEAPI=YES \
  -DBUILD_REMOTEGUI=YES \
  -DENABLE_UPNP=YES \
  -DCMAKE_INSTALL_PREFIX=/usr/local

Un par de aclaraciones sobre las opciones:

• BUILD_MONOLITHIC=NO: no compilamos la GUI de escritorio monolítica, porque en un servidor headless no tiene sentido. Esto ahorra tiempo y recursos.
• BUILD_AMULEAPI=YES: activamos el nuevo daemon, la joya de esta versión.
• CMAKE_INSTALL_PREFIX=/usr/local: instalamos los binarios en /usr/local/bin, fuera de los paquetes del sistema.

6. Compilación e instalación

Lanzamos la compilación usando todos los núcleos disponibles:

cmake --build build -j"$(nproc)"

En la Raspberry Pi 5 esto tardará un rato, así que paciencia.

Cuando termine:

sudo cmake --install build

Esto instalará los binarios (amuled, amuleapi, amulecmd, amulegui) en /usr/local/bin.

7. Primer arranque de amuled y generación de configuración

Ahora vamos a hacer un primer arranque del daemon como el usuario amule para que genere su configuración por defecto:

sudo -u amule amuled -f

Verás que se crea el directorio /home/amule/.aMule/ con el archivo amule.conf y otros.

En este punto aMule se cerrará solo, es totalmente normal.

7.1. Configuración de amule.conf

Editamos el archivo de configuración con el usuario correcto para no tener problemas de permisos:

sudo -u amule nano /home/amule/.aMule/amule.conf

Los ajustes que necesitas revisar son:

Sección [eMule]

Sección [ExternalConnect]

Esta sección es crítica: es la que permite que amuleapi y amulegui se comuniquen con amuled.

Genera el hash MD5 de la contraseña EC con:

echo -n "MiClaveEC" | md5sum | cut -d ' ' -f 1

Copia el resultado y pégalo en ECPassword. Guarda bien la contraseña en claro porque la vas a necesitar después.

Sección [Directories]

Guarda el archivo y sal.

7.2. Configuración de amuleapi

Ahora toca configurar el nuevo daemon. Primero establecemos la contraseña de administrador de la interfaz web:

sudo -u amule amuleapi --set-admin-pass="TuContraseñaWeb"

Opcionalmente, también podemos crear una de invitado (solo lectura):

sudo -u amule amuleapi --set-guest-pass="OtraContraseña"

Ahora editamos la configuración de amuleapi:

sudo -u amule nano /home/amule/.aMule/amuleapi.conf

La sección [EC] es la que conecta amuleapi con amuled. Aquí la contraseña va en texto plano (la misma que hasheaste antes para amule.conf):

[Server]
BindAddress=127.0.0.1
Port=4713
AllowCORS=0

[EC]
Host=127.0.0.1
Port=4712
Password=MiClaveEC
Encryption=1

Ojo: [Server] BindAddress=127.0.0.1 deja la web accesible solo desde la propia Raspberry Pi. Eso es lo que queremos si vamos a poner un proxy inverso con TLS delante. Si vas a acceder directamente desde tu red local, cambia a 0.0.0.0. Y si vas a exponerla a internet, imprescindible usar HTTPS mediante un proxy inverso.

8. Servicios systemd

Creamos dos servicios: uno para amuled y otro para amuleapi. Ambos se ejecutarán como el usuario amule.

8.1. Servicio amuled

sudo nano /etc/systemd/system/amuled.service

[Unit]
Description=aMule Daemon
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=forking
User=amule
Group=amule
Environment="HOME=/home/amule"
ExecStart=/usr/local/bin/amuled -f
Restart=on-failure
RestartSec=10
LimitNOFILE=65536
KillMode=control-group
KillSignal=SIGTERM

[Install]
WantedBy=multi-user.target

8.2. Servicio amuleapi

sudo nano /etc/systemd/system/amuleapi.service

[Unit]
Description=aMule API & Web UI
After=network.target amuled.service
Requires=amuled.service

[Service]
Type=simple
User=amule
Group=amule
Environment="HOME=/home/amule"
ExecStartPre=/bin/bash -c 'until (echo > /dev/tcp/127.0.0.1/4712) 2>/dev/null; do sleep 0.5; done'
ExecStart=/usr/local/bin/amuleapi
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Habilitamos y arrancamos ambos:

sudo systemctl daemon-reload
sudo systemctl enable --now amuled.service
sudo systemctl enable --now amuleapi.service

Verificamos que están corriendo:

sudo systemctl status amuled.service amuleapi.service

Y si queremos ver logs en vivo:

sudo journalctl -u amuled -f
sudo journalctl -u amuleapi -f

9. Acceso a la nueva interfaz web

Desde un navegador en tu red local, visita:

http://IP_DE_LA_RASPBERRY:4713

Introduce la contraseña de administrador que configuraste antes. La interfaz es completamente funcional: gestiona descargas, búsqueda, estadísticas, preferencias, archivos compartidos… Todo desde el navegador, con actualizaciones en tiempo real.

Si quieres probar la API REST desde la terminal:

curl -X POST http://localhost:4713/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"password":"TuContraseñaWeb"}'

Recibirás un token JWT que podrás usar en el resto de endpoints.

9.1. Acceso desde fuera de casa.

Si quieres controlar aMule desde fuera de tu red local, tienes dos opciones:

9.1.a. Abrir el puerto 4713 en el router (no recomendado)

Esta es la vía rápida: la misma que muchos usábamos con el antiguo amuleweb. Consiste en exponer amuleapi directamente a internet abriendo el puerto en el router. Técnicamente funciona, pero tiene un problema serio: amuleapi habla HTTP en texto plano, sin cifrado.

Los pasos serían estos:

Edita amuleapi.conf para que escuche en todas las interfaces de red en lugar de solo en localhost:

sudo -u amule nano /home/amule/.aMule/amuleapi.conf

Y cambia la sección [Server]:ini

[Server]
BindAddress=0.0.0.0 
Port=4713

Reinicia el servicio para aplicar el cambio:

sudo systemctl restart amuleapi.service

Redirige el puerto 4713 en tu router, la forma de hacerlo dependerá de cada modelo de router

Accede desde fuera (por ejemplo)

http://tu-dominio.duckdns.org:4713

¿Por qué no te lo recomiendo? Por varios motivos que conviene tener claros:

• Tus credenciales viajan en claro. Cualquiera que intercepte el tráfico (tu operadora, un WiFi público desde el que te conectes, un atacante en tu misma red) puede leer tu contraseña de administrador y tomar el control de tu aMule.
• Los bots escanean internet constantemente. En cuanto abres un puerto, empiezan a llegar intentos de login automatizados. amuleapi tiene protección contra fuerza bruta (LoginFailureThreshold=5 en 60 segundos, con bloqueo de 300 segundos), pero no es infalible.
• Superficie de ataque directa. Cualquier vulnerabilidad que se descubra en amuleapi queda expuesta directamente a internet, sin ninguna capa intermedia que filtre.

En definitiva, es lo que hacíamos con amuleweb, y funcionaba. Pero hoy no tiene sentido asumir ese riesgo cuando existen alternativas mejores y casi igual de cómodas.

9.1.b. Acceder a través de tu VPN WireGuard (recomendado)

Esta es la opción que yo mismo uso y la que te recomiendo sin dudarlo. Si ya tienes montada una VPN WireGuard en tu Raspberry Pi —como expliqué en la entrada WireGuard en Raspberry Pi: VPN casera, segura y gratuita—, ya tienes hecha la mitad del trabajo.

La idea es muy sencilla: en lugar de exponer amuleapi a internet, te conectas primero a tu VPN y luego accedes a la interfaz web como si estuvieras dentro de tu red local. Todo el tráfico viaja cifrado por el túnel de WireGuard, así que no hay ningún riesgo de interceptación.

Ventajas frente a abrir el puerto:

• Cifrado de extremo a extremo. Todo el tráfico entre tu dispositivo y la Raspberry Pi viaja cifrado por WireGuard, sin necesidad de certificados SSL ni proxies inversos.
• No expones ningún servicio a internet. amuleapi sigue escuchando solo en la interfaz de la VPN. Los bots y escáneres no tienen nada a lo que atacar.
• Una sola puerta de entrada. Ya tienes WireGuard como punto de acceso seguro a tu red doméstica. Aprovecharlo para aMule es lo lógico.
• Funciona desde cualquier dispositivo: móvil, portátil, tablet… Solo necesitas el cliente WireGuard y tu configuración.

Pasos a seguir:

Conéctate a tu VPN desde el dispositivo que vayas a usar (móvil, portátil…). Verifica que tienes conexión navegando a cualquier web.

Ajusta amuleapi.conf para que escuche en la interfaz de la VPN. Como tu servidor WireGuard usa la IP 10.0.0.1, debes indicarle esa dirección:

sudo -u amule nano /home/amule/.aMule/amuleapi.conf

Y deja la sección [Server] así:

[Server]
BindAddress=10.0.0.1
Port=4713

Nota: Podrías usar BindAddress=0.0.0.0 para escuchar en todas las interfaces, pero limitarlo a la IP de la VPN es más seguro, porque la única vía de acceso será el túnel. Lo malo de esto es que no podrás entrar localmente desde ningún dispositivo que esté fuera de la VPN, así que déjalo como mejor se ajuste a tus necesidades

Reinicia el servicio:

sudo systemctl restart amuleapi.service

Accede desde el navegador, ya conectado a la VPN, con la dirección privada de tu Raspberry Pi:

http://10.0.0.1:4713

Introduce tu contraseña de administrador y tendrás acceso completo a la interfaz web de aMule.

Un detalle práctico: como todo va por el túnel de WireGuard, la velocidad de acceso a la interfaz dependerá de tu conexión, pero para gestionar descargas y navegar por las listas va más que sobrado.

9.1.c. Alternativa intermedia: túnel SSH

Si en algún momento no quieres (o no puedes) usar la VPN, también puedes crear un túnel SSH desde tu equipo remoto:

ssh -L 4713:localhost:4713 raspberry@ip-de-tu-raspberry

Y después acceder en el navegador a http://localhost:4713. Funciona igual de bien, viaja cifrado dentro del túnel SSH, y no requiere abrir ningún puerto en el router. Es un buen plan B cuando no tengas la VPN a mano.

En resumen

Opción	Cifrado	Puertos abiertos	Riesgo	Recomendación
Abrir puerto 4713	No	Sí (4713)	Alto	No recomendado
VPN WireGuard	Sí	No	Ninguno	Muy recomendado
Túnel SSH	Sí	No	Ninguno	Buen plan B

Si ya tienes la VPN montada, no hay color: usa WireGuard. Es más seguro, más cómodo, y no tienes que abrir ni un solo puerto en el router. Si no la tienes todavía, es el momento perfecto para montarla —te sirve para aMule y para todo lo demás.

10. Gestión de los servicios

Una vez que tienes aMule funcionando como servicios de systemd, conviene tener a mano los comandos básicos para controlarlos. La buena noticia es que ahora tienes dos servicios independientes (amuled y amuleapi), pero están vinculados por una dependencia que hace que todo sea muy cómodo de gestionar.

Cómo se relacionan los dos servicios

En el archivo amuleapi.service incluimos estas líneas:

After=network.target amuled.service
Requires=amuled.service

Esa dependencia Requires significa que:

• Si amuled se detiene, amuleapi también se detiene automáticamente. El sistema considera que amuleapi no tiene sentido sin el daemon.
• Si arrancas amuleapi, systemd arranca amuled antes automáticamente. No tienes que preocuparte por el orden.

Es decir, en la práctica puedes gestionar casi todo desde un solo comando.

Parar aMule

Para detener todo, basta con parar amuled:

sudo systemctl stop amuled.service

amuleapi se detendrá solo como consecuencia de la dependencia. Puedes verificarlo con:

sudo systemctl status amuleapi.service

Debería aparecer como inactive (dead).

Si por algún motivo quieres parar solo la interfaz web sin cortar las descargas, puedes hacerlo sin afectar a amuled:

sudo systemctl stop amuleapi.service

Esto es útil, por ejemplo, si vas a tocar la configuración de amuleapi.conf y no quieres interrumpir las descargas en curso.

Iniciar aMule

Para arrancar todo de una vez:

sudo systemctl start amuleapi.service

Gracias al Requires, systemd arrancará primero amuled y luego amuleapi. Si prefieres ser explícito con el orden:

sudo systemctl start amuled.service
sudo systemctl start amuleapi.service

Reiniciar aMule

Útil cuando has cambiado algo en la configuración de amule.conf o amuleapi.conf y quieres aplicar los cambios sin parar y arrancar por separado:

sudo systemctl restart amuled.service amuleapi.service

O, si solo has tocado la parte web:

sudo systemctl restart amuleapi.service

Recuerda: amuleapi guarda la configuración en amuleapi.conf y la lee al arrancar. Si cambias algo ahí, es necesario reiniciar el servicio para que surta efecto.

Ver el estado

Para comprobar que ambos servicios están corriendo correctamente:

sudo systemctl status amuled.service amuleapi.service

Verás algo como esto para cada uno:

● amuled.service - aMule Daemon
     Loaded: loaded (/etc/systemd/system/amuled.service; enabled; preset: enabled)
     Active: active (running) since ...

Si algo va mal, esta es la primera parada obligatoria. La salida suele dar pistas muy claras sobre el problema.

Ver los logs en tiempo real

Cuando algo no funciona o quieres seguir la actividad del daemon, los logs son tu mejor amigo:

# Logs de amuled en vivo
sudo journalctl -u amuled -f

# Logs de amuleapi en vivo
sudo journalctl -u amuleapi -f

El parámetro -f mantiene el comando abierto y va mostrando las nuevas líneas a medida que se generan. Para salir, pulsa Ctrl+C.

Si quieres ver solo las últimas líneas sin quedarte enganchado:

sudo journalctl -u amuled -n 50
sudo journalctl -u amuleapi -n 50

Arranque automático al iniciar la Raspberry Pi

Ambos servicios están configurados con WantedBy=multi-user.target, lo que significa que arrancarán automáticamente cada vez que enciendas la Raspberry Pi. Si alguna vez quieres desactivar ese comportamiento (por ejemplo, para hacer pruebas):

sudo systemctl disable amuled.service amuleapi.service

Y para volver a activarlo:

sudo systemctl enable amuled.service amuleapi.service

Ten en cuenta que disable no para el servicio si está corriendo; solo impide que arranque automáticamente al inicio. Si quieres desactivarlo y pararlo en un solo paso:

sudo systemctl disable --now amuled.service

Resumen práctico

Con estos comandos tienes control total sobre aMule. La dependencia entre los dos servicios hace que, en el 90% de los casos, te baste con gestionar amuled, y amuleapi seguirá el ritmo automáticamente.

Con esto tienes aMule 3.1.0 funcionando a pleno rendimiento en tu Raspberry Pi 5, con la mejor interfaz de control remoto que ha tenido nunca aMule y todas las ventajas de la nueva versión. Como siempre, si os surge cualquier duda, dejadme un comentario y os echo una mano.

¡A disfrutar de las descargas!

Miscelánea.

Tal vez te interese como recibir notificaciones de aMule en Telegram.

Puntos clave del script

1. Preservación estricta de permisos (tar -czpf): La bandera -p (--same-permissions) fuerza a tar a almacenar y respetar los atributos, permisos y propietarios originales (www-data:www-data) de los archivos web y carpetas multimedia.
2. Control de almacenamiento: Limpieza automática de respaldos con más de $X$ días mediante find para evitar saturar la tarjeta SD o el SSD.
3. Notificación en tiempo real: Reporte de éxito (con tamaño del archivo y rotaciones) o fallo directo a Telegram.

Paso 1: Crear el script de respaldo (backup_wp.sh)

Crea o edita el script en /usr/local/bin/backup_wp.sh:

#!/bin/bash

# ==========================================
# CONFIGURACIÓN GENERAL
# ==========================================
WP_DIR="/var/www/html"                  # Ruta del sitio WordPress
BACKUP_DIR="/var/backups/wordpress"     # Directorio donde se guardará el .tar.gz
DB_USER="wp_user"                       # Usuario de MariaDB/MySQL
DB_PASS="tu_contrasena_db"              # Contraseña de la base de datos
DB_NAME="wordpress_db"                  # Nombre de la base de datos

# Retención (días a conservar los backups)
RETENTION_DAYS=15

# Configuración Telegram
BOT_TOKEN="123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ"
CHAT_ID="987654321"

# ==========================================
# PREPARACIÓN Y VARIABLES
# ==========================================
mkdir -p "$BACKUP_DIR"
FECHA=$(date +%Y%m%d_%H%M%S)
ARCHIVE_NAME="wp_backup_${FECHA}.tar.gz"
DESTINO="${BACKUP_DIR}/${ARCHIVE_NAME}"
TEMP_SQL="/tmp/db_${FECHA}.sql"

# Función para enviar notificaciones a Telegram
enviar_telegram() {
    local MENSAJE="$1"
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
        -d chat_id="${CHAT_ID}" \
        -d text="${MENSAJE}" \
        -d parse_mode="HTML" > /dev/null
}

# ==========================================
# EJECUCIÓN DEL BACKUP
# ==========================================

# 1. Volcado de la base de datos
if mysqldump -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" > "$TEMP_SQL" 2>/dev/null; then
    
    # 2. Compresión de archivos + volcado SQL (preservando permisos originales con -p)
    if tar -czpf "$DESTINO" -C "$WP_DIR" . -C /tmp "$(basename "$TEMP_SQL")" 2>/dev/null; then
        TAMANO=$(du -h "$DESTINO" | cut -f1)
        rm -f "$TEMP_SQL"
        
        # 3. Rotación: Eliminar copias de seguridad de más de X días
        BORRADOS=$(find "$BACKUP_DIR" -type f -name "wp_backup_*.tar.gz" -mtime +$RETENTION_DAYS -print -delete | wc -l)
        
        MSG_ROTACION=""
        if [ "$BORRADOS" -gt 0 ]; then
            MSG_ROTACION="%0A<b>Rotación:</b> $BORRADOS archivo(s) antiguo(s) eliminado(s) (+$RETENTION_DAYS días)."
        fi
        
        enviar_telegram "<b>✅ Backup WordPress Exitoso</b>%0A<b>Host:</b> $(hostname)%0A<b>Archivo:</b> <code>$ARCHIVE_NAME</code>%0A<b>Tamaño:</b> $TAMANO${MSG_ROTACION}"
    else
        rm -f "$TEMP_SQL"
        enviar_telegram "<b>❌ Error en Backup WordPress</b>%0A<b>Host:</b> $(hostname)%0AFalló la compresión tar.gz."
        exit 1
    fi
else
    enviar_telegram "<b>❌ Error en Backup WordPress</b>%0A<b>Host:</b> $(hostname)%0AFalló la exportación de la base de datos (mysqldump)."
    exit 1
fi

El script backup_wp.sh es una solución automatizada en Bash para realizar copias de seguridad integrales de WordPress sin intervención manual. Esto es todo lo que ejecuta en segundo plano cada vez que el temporizador lo activa:

• Volcado de la base de datos: Extrae una copia en limpio de MariaDB/MySQL mediante mysqldump con todas las entradas, páginas, usuarios, comentarios y configuraciones.
• Empaquetado y preservación de permisos: Junta la base de datos y la totalidad del directorio web (/var/www/html) en un archivo comprimido .tar.gz, utilizando la bandera -p para guardar intactos los propietarios (www-data:www-data) y permisos originales.
• Rotación automática de almacenamiento: Examina la carpeta de respaldos y elimina los archivos que superen los días de retención configurados (por ejemplo, 15 días), evitando que la tarjeta SD o disco duro de la Raspberry Pi se llene.
• Notificación instantánea por Telegram: Conecta con la API de Telegram para enviarte un reporte al móvil con el estado del proceso, informando el nombre del archivo, su tamaño final y si se purgaron copias antiguas (o alertando de inmediato si ocurrió algún fallo).

Ahora que sabes como funciona el script, asigna permisos de ejecución:

sudo chmod +x /usr/local/bin/backup_wp.sh

Paso 2: Crear la unidad de servicio Systemd

Crea el archivo /etc/systemd/system/wp-backup.service:

[Unit]
Description=Servicio de copia de seguridad completa de WordPress con rotacion
After=network-online.target mariadb.service
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup_wp.sh
User=root

Paso 3: Programar el temporizador (Systemd Timer)

Crea el archivo /etc/systemd/system/wp-backup.timer:

[Unit]
Description=Temporizador diario para el backup de WordPress

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

Paso 4: Activación y verificación

Habilita e inicia el temporizador:

sudo systemctl daemon-reload
sudo systemctl enable --now wp-backup.timer

• Verificar la programación del Timer:
  systemctl list-timers wp-backup.timer
• Probar la ejecución manual del servicio:
  sudo systemctl start wp-backup.service

Paso 5: Cómo restaurar el WordPress desde un backup

Tener una copia de seguridad no sirve de nada si no sabes cómo restaurarla. En caso de desastre, hackeo o fallo grave al actualizar un plugin, sigue este procedimiento.

1. Extraer los archivos del sitio web

Descomprime el archivo .tar.gz directamente en el directorio web (/var/www/html) utilizando sudo y el parámetro -p para conservar los propietarios y permisos originales (www-data:www-data):

sudo tar -xzpf /var/backups/wordpress/wp_backup_20260919_040000.tar.gz -C /var/www/html

2. Restaurar la base de datos MySQL / MariaDB

Al descomprimir el paquete se habrá extraído el archivo SQL con el volcado (por ejemplo: db_20260919_040000.sql) dentro de /var/www/html. Según el estado actual de tu sistema, elige una de las dos opciones:

Opción A: En un servidor nuevo o instalación limpia (Desastre total)

Si estás restaurando en una Raspberry Pi o servidor recién instalado donde la base de datos aún no ha sido creada:

# 1. Crear la base de datos si no existe
sudo mysql -e "CREATE DATABASE IF NOT EXISTS wordpress_db;"

# 2. Importar el volcado SQL
sudo mysql -u wp_user -p wordpress_db < /var/www/html/db_20260919_040000.sql

Opción B: En una web en producción / en uso (Sobrescribir o revertir estado)

Si la web está activa pero necesitas volver atrás (por ejemplo, para deshacer una actualización corrupta o una infección de malware), es fundamental borrar la base de datos previa antes de importar. De lo contrario, las tablas antiguas, configuraciones corruptas o plugins eliminados seguirán en la base de datos:

# 1. Borrar la base de datos actual y recrearla completamente vacía
sudo mysql -e "DROP DATABASE IF EXISTS wordpress_db; CREATE DATABASE wordpress_db;"

# 2. Importar el volcado SQL limpio del respaldo
sudo mysql -u wp_user -p wordpress_db < /var/www/html/db_20260919_040000.sql

3. Limpieza y reajuste de seguridad

Para finalizar, elimina el archivo .sql de la carpeta pública de la web para evitar que alguien pueda descargarlo desde el navegador y asegura la propiedad de la instalación:

# Eliminar el dump SQL expuesto por seguridad
sudo rm /var/www/html/db_*.sql

# Reasegurar que todo pertenece al usuario del servidor web (www-data)
sudo chown -R www-data:www-data /var/www/html

Y con esto y una caña ¡Viva España!

Hoy vamos a diseccionar los principales compresores, descubrir cómo sacarles el máximo partido exprimiendo nuestra CPU, y terminaremos montando un sistema de backup automatizado que nos avise por Telegram. ¡Vamos al lío!

En sistemas GNU/Linux existe una distinción fundamental que a menudo confunde a quienes empiezan: empaquetar no es comprimir.

• Empaquetar (Archivar): Consiste en juntar múltiples archivos y directorios (junto con sus permisos, propietarios y estructura de carpetas) en un único archivo continuo. El tamaño total casi no varía. El estándar indiscutible es tar (Tape Archive).
• Comprimir: Consiste en aplicar un algoritmo matemático a un único archivo para reducir el espacio que ocupa en disco. Herramientas nativas como gzip, bzip2 o xzsolo pueden comprimir un único archivo a la vez.

Por esta razón se combinan ambas tareas: primero se empaqueta una carpeta con tar y luego se pasa por el compresor (generando archivos .tar.gz, .tar.bz2 o .tar.xz).

1. El comodín del administrador: El comando tar

El comando tar permite empaquetar y comprimir en un solo paso gracias a que integra los motores de compresión directamente mediante modoles o flags.

Opciones (flags) principales de tar

• Operaciones básicas (elegir una):
  • -c (--create): Crea un nuevo archivo empaquetado.
  • -x (--extract): Extrae el contenido de un archivo empaquetado.
  • -t (--list): Lista el contenido del archivo sin extraerlo.
• Selección del algoritmo de compresión:
  • (Sin flag): Solo empaqueta (.tar).
  • -z (--gzip): Filtra a través de gzip (.tar.gz o .tgz).
  • -j (--bzip2): Filtra a través de bzip2 (.tar.bz2).
  • -J (--xz): Filtra a través de xz (.tar.xz).
• Modificadores esenciales:
  • -f (--file): Especifica el nombre del archivo de destino o lectura. Debe ser el último flag de la lista.
  • -v (--verbose): Muestra el detalle del proceso en pantalla paso a paso.
  • -C (--directory): Cambia a un directorio específico antes de realizar la extracción.
  • -p (--same-permissions): Mantiene intactos los permisos de archivos y propietarios originales.
  • --exclude=PATRÓN: Excluye archivos o carpetas que coincidan con el patrón indicado (ej. --exclude='.git').

Ejemplos prácticos con tar

# Empaquetar sin comprimir
tar -cvf backup.tar /var/www/html

# Empaquetar y comprimir con GZIP (rápido y ligero)
tar -czvf backup.tar.gz /var/www/html

# Empaquetar y comprimir con BZIP2 (ratio intermedio)
tar -cjvf backup.tar.bz2 /var/www/html

# Empaquetar y comprimir con XZ (compresión máxima)
tar -cJvf backup.tar.xz /var/www/html

# Extraer en el directorio actual (autodetecta el formato de compresión)
tar -xvf backup.tar.xz

# Extraer el contenido dentro de una carpeta concreta
tar -xvf backup.tar.gz -C /tmp/restauracion

# Listar contenido sin extraer
tar -tvf backup.tar.xz

2. Herramientas de compresión individuales: gzip, bzip2 y xz

Si trabajas con un solo archivo grande (por ejemplo, un volcado de base de datos .sql o una imagen .img), no necesitas tar. Puedes usar directamente los compresores.

¡Atención! Por defecto, estas herramientas eliminan el archivo original y dejan únicamente el comprimido, a menos que utilices el flag -k (--keep).

gzip (GNU zip)

Es el estándar por su velocidad.

• Comprimir (conservando el original):gzip -k archivo.txt
• Descomprimir:gunzip archivo.txt.gz o gzip -d archivo.txt.gz
• Niveles de compresión: Del -1 (ultra rápido, menos compresión) al -9 (máxima compresión). Por defecto aplica -6.

bzip2

Ofrece mejor ratio que gzip a costa de usar más tiempo y CPU.

• Comprimir (conservando el original):bzip2 -k archivo.txt
• Descomprimir:bunzip2 archivo.txt.bz2 o bzip2 -d archivo.txt.bz2

xz

Usa el algoritmo LZMA2. Ofrece el máximo ratio de compresión en Linux.

• Comprimir (conservando el original):xz -k archivo.txt
• Descomprimir:unxz archivo.txt.xz o xz -d archivo.txt.xz
• Uso de multinúcleo (Multithreading): Por defecto usa un solo hilo. Con -T0 utiliza todos los núcleos disponibles del procesador:
  Bashxz -k -9 -T0 imagen_sistema.img

3. Intercambio con Windows/macOS: zip y unzip

A diferencia de los comandos nativos de Linux, zip empaqueta y comprime en el mismo paso y es el estándar universal para compartir archivos con otros sistemas operativos.

Comandos y flags principales

Para crear archivos .zip:

• -r (--recurse-paths): Imprescindible para incluir subcarpetas recursivamente.
• -e (--encrypt): Solicita clave para cifrar el archivo.
• -9: Aplica compresión máxima.

# Comprimir una carpeta entera recursivamente
zip -r -9 archivo.zip /ruta/a/carpeta

# Comprimir y proteger con contraseña
zip -r -e seguro.zip /ruta/a/datos_sensibles

Para descomprimir .zip:

• -l (--list): Muestra el contenido sin extraer.
• -d (--directory): Especifica la carpeta de destino.

# Extraer en una ruta específica
unzip archivo.zip -d /home/usuario/descargas/

4. Comparativa visual de rendimiento

A la hora de elegir la herramienta adecuada, hay que sopesar tres factores: Ratio de compresión, Velocidad y Consumo de recursos (CPU).

(A continuación se muestra la tarjeta comparativa global con las métricas fijas de cada herramienta):

Comparativa de Compresores en Linux

gzip (.gz)

Ratio compresión60%

Velocidad90% (Muy Rápido)

Uso de CPU20% (Bajo)

bzip2 (.bz2)

Ratio compresión75%

Velocidad50% (Medio)

Uso de CPU50% (Medio)

xz (.xz)

Ratio compresión95% (Máximo)

Velocidad20% (Lento)

Uso de CPU90% (Alto)

zip (.zip)

Ratio compresión50%

Velocidad85% (Rápido)

Uso de CPU15% (Muy bajo)

5. Resumen rápido (Cheat Sheet)

Nivel Pro: Multihilo y Barras de Progreso

1. Exprimiendo la CPU: Compresión Multihilo

¿Por qué la compresión tradicional se siente «lenta»?

Los procesadores modernos (de un ordenador de sobremesa, un servidor o una Raspberry Pi) tienen varios núcleos o hilos (4, 8, 16 o más). Sin embargo, herramientas tradicionales como gzip, bzip2 o xz fueron creadas hace décadas, cuando los procesadores solo tenían un núcleo.

Por defecto, estos comandos solo utilizan 1 solo núcleo al 100%, dejando el resto de tu procesador totalmente ocioso. Si tienes un procesador de 8 núcleos y usas gzip, estás aprovechando apenas un 12,5% de la potencia total de tu máquina.

Las versiones multihilo al rescate

Para solucionar esto existen versiones paralelizadas (multihilo). Lo que hacen es dividir el archivo gigante en pequeños trozos, repartir cada trozo entre todos los núcleos de tu CPU para comprimirlos simultáneamente y luego juntarlos de nuevo.

Paso 1: Instalación

En la mayoría de distribuciones basadas en Debian, Ubuntu o Raspberry Pi OS, estas herramientas no vienen instaladas por defecto, pero se instalan con un solo comando:

sudo apt update
sudo apt install pigz pbzip2 pixz pv

Paso 2: Uso directo de los comandos multihilo

Funcionan con las mismas banderas básicas que ya conoces (-k para mantener el original, -d para descomprimir, -9 para máxima compresión):

# Comprimir un archivo usando TODOS los núcleos de la CPU con pigz
pigz -k -9 base_de_datos.sql
# Genera: base_de_datos.sql.gz (mucho más rápido que gzip)

# Descomprimir a máxima velocidad con pigz
pigz -d base_de_datos.sql.gz

# Comprimir con pbzip2 (repartiendo carga entre núcleos)
pbzip2 -k imagen.iso

Paso 3: Usar herramientas multihilo directamente con tar

Para que tar no use el gzip tradicional sino pigz, se utiliza el flag -I (o --use-compress-program=), indicándole a tar qué motor de compresión externo debe emplear:

# Empaquetar y comprimir una carpeta a la máxima velocidad posible usando pigz:
tar -I pigz -cvf backup_ultrarrapido.tar.gz /var/www/html

# Lo mismo para bzip2 multihilo (pbzip2):
tar -I pbzip2 -cvf backup.tar.bz2 /var/www/html

# Lo mismo para xz multihilo (pixz):
tar -I pixz -cvf backup.tar.xz /var/www/html

Nota para XZ: El comando xz moderno ya incluye soporte multihilo sin instalar nada extra. Solo debes pasarle el flag -T0 para usar todos los núcleos disponibles:

tar -I "xz -T0" -cvf backup.tar.xz /var/www/html

2. Barras de progreso en tiempo real con pv (Pipe Viewer)

Cuando comprimes un archivo o carpeta de varios Gigabytes desde la terminal, la pantalla se queda congelada sin mostrar si el proceso va por el 10% o el 90%, ni cuánto tiempo falta.

La herramienta pv (Pipe Viewer) intercepta el flujo de datos entre comandos (tuberías o pipes|) y muestra una barra de progreso en tiempo real con velocidad de transferencia, tiempo transcurrido y tiempo estimado de finalización (ETA).

[===>                                       ] 12% 14.2MB/s ETA 0:04:32

Ejemplo 1: Ver el progreso al comprimir un solo archivo grande

En lugar de lanzar gzip archivo.iso, hacemos pasar el archivo a través de pv:

pv archivo.iso | pigz > archivo.iso.gz

• Explicación: pv lee archivo.iso, muestra la barra de progreso en pantalla mientras lo pasa por la tubería | a pigz, y el resultado se guarda en archivo.iso.gz.

Ejemplo 2: Ver el progreso al empaquetar una carpeta con tar

Para ver la barra de progreso mientras empaquetas y comprimes una carpeta entera:

tar -cf - /var/www/html | pv | pigz > backup_con_progreso.tar.gz

• tar -cf - /var/www/html: Empaqueta la carpeta y, en vez de crear un archivo en disco directamente, manda el resultado a la salida estándar (-).
• | pv |: Mide los datos que van pasando y dibuja la barra de progreso.
• | pigz > backup_con_progreso.tar.gz: Recibe el flujo, lo comprime usando todos los núcleos de la CPU y lo guarda finalmente en el archivo de destino.

Ejemplo 3: Ver el progreso al descomprimir

pv backup.tar.gz | pigz -d | tar -x

• Lee el comprimido mostrando la barra de progreso (pv), lo descomprime en memoria con todos los núcleos (pigz -d) y lo extrae en el directorio actual (tar -x).

Conclusión: Pon tu disco duro a dieta

Ahora que ya conoces los entresijos del empaquetamiento y la compresión en la terminal de Linux, no hay archivo grande ni directorio pesado que se te resista. Al final, esto es como un gimnasio de alto rendimiento para tus datos: la clave no está en «sudar» CPU a lo loco, sino en elegir la rutina adecuada para cada caso:

• Si necesitas velocidad pura y cero esperas: Tira de gzip o, mejor aún, desata toda la potencia multihilo con pigz.
• Si el espacio en disco o el ancho de banda son sagrados: Dale caña con la mancuerna pesada de xz (o pixz) para arañar hasta el último megabyte.
• Y no olvides la regla de oro: Empaquetar junta los archivos ordenadamente con sus permisos; comprimir los encoge.

Dominar estas herramientas y sus alternativas modernas marca la diferencia entre un administrador que se queda mirando una pantalla congelada y uno que optimiza recursos e infraestructura como un profesional.

En la próxima entrada daremos el paso definitivo: cogeremos todo este músculo de compresión multihilo y lo integraremos en un sistema de backups automatizado con Systemd y avisos directos al móvil por Telegram.

¿Cuál es tu combinación favorita en el día a día? ¿Eres más de primar la velocidad o de buscar el máximo ahorro de espacio? ¡Nos leemos en los comentarios!

En esta entrada, te voy a enseñar cómo instalar, configurar y usar Proxychains junto con Tor para que puedas anonimizar el tráfico de cualquier comando en tu terminal. Verás que es más sencillo de lo que imaginas y te abrirá un mundo de posibilidades para pruebas de penetración, investigación o simplemente para mantener tu privacidad.

Mediante la combinación de Tor y Proxychains, podemos dinamizar nuestras conexiones a través de múltiples nodos intermedios cifrados de forma transparente.

¿Qué es Proxychains y cómo funciona con Tor?

Proxychains es una herramienta que fuerza a cualquier aplicación TCP (que no sea demasiado compleja) a pasar su tráfico a través de una cadena de proxies. En su configuración, podemos definir uno o varios proxies, y el tráfico irá saltando de uno a otro secuencialmente. Normalmente, se usa con un único proxy, que es el de Tor.

Tor, por su parte, expone un proxy SOCKS5 en el puerto 9050 (por defecto) que acepta conexiones. Al configurar Proxychains para que use ese proxy, cualquier comando lanzado con proxychains enviará su tráfico a través del proxy de Tor, y Tor se encargará de enrutarlo a través de su red de nodos (por lo general, 3 saltos). De esta forma, la aplicación final no sabe que está usando Tor, y el tráfico sale de tu máquina cifrado hacia el primer nodo.

Lo interesante es que Proxychains puede encadenar múltiples proxies (por ejemplo, SOCKS5, HTTP, etc.), aunque lo más común es usar solo el de Tor.

¿Qué necesitamos?

El proceso es sumamente sencillo y no requiere alterar la configuración global de red de nuestro sistema ni del router. Únicamente instalaremos dos herramientas:

• Tor: El servicio que creará el túnel SOCKS5 local.
• Proxychains4: Un enlazador (dynamically linked library) que intercepta las llamadas de red TCP de cualquier programa y las fuerza a pasar por el proxy elegido.

Paso 1: Instalación de paquetes

En distribuciones basadas en Debian/Ubuntu:

sudo apt update && sudo apt install tor proxychains4 -y

Paso 2: Configuración de Proxychains

El archivo de configuración principal de Proxychains se encuentra en /etc/proxychains4.conf (o /etc/proxychains.conf). Lo editaremos con nuestro editor favorito (necesitamos permisos de superusuario).

Para nuestro caso, con un solo proxy (Tor), da igual cual uses. Recomiendo dynamic_chain por si acaso.

Dentro del archivo, hay varias secciones. Las más importantes son:

a) Modo de cadena

• strict_chain: todos los proxies deben estar disponibles, y el tráfico pasa por todos en orden.
• dynamic_chain: igual que strict, pero si algún proxy falla, lo omite (siempre que haya al menos uno funcionando).
• random_chain: selecciona un orden aleatorio de los proxies listados.

Para nuestro caso, usaremos dynamic_chain ya que, para nuestro caso, con un único proxy (Tor), da igual usar strict_chain o dynamic_chain. Si en el futuro añades más proxies, random_chain puede ser útil para variar el orden.

Busca la línea #dynamic_chain y descoméntala (quita el #).

Verifica que las opciones strict_chain y random_chain están comentadas. (añade el #).

b) Proxy DNS

Esta sección aborda el gran peligro olvidado de este tipo de configuraciones: las fugas de DNS (DNS Leaks), además de añadir un truco para cambiar de IP a voluntad y una tabla clara de compatibilidad.

De nada sirve ocultar tu dirección IP mediante Tor si tu sistema sigue enviando las peticiones de nombres (DNS) a través de tu proveedor de internet habitual o del router de casa. Si esto ocurre, cualquiera que analice el tráfico sabrá exactamente qué dominios estás visitando.

Para evitar esto, proxychains4 incluye una directiva para forzar a que la resolución de nombres viaje cifrada por el propio túnel de Tor.

Asegúrate de que en /etc/proxychains4.conf la siguiente línea está activa (sin el # al principio):

proxy_dns

¿Cómo verificar que estás 100% protegido?

Abre tu navegador pasando por el proxy:

proxychains firefox https://dnsleaktest.com

Haz clic en Extended test. Si en los resultados de los servidores DNS únicamente aparecen nodos de la red Tor (y en ningún caso la IP de tu proveedor o de tu servidor local), tu anonimato es total.

Nota: proxy_dns funciona con la mayoría de aplicaciones de terminal, pero navegadores como Firefox pueden tener su propia resolución DNS (especialmente si usan DNS sobre HTTPS). Para estos casos, asegúrate de configurar también el proxy DNS dentro del navegador (como se explica en el Método 2).

c) Lista de proxies

Al final del archivo, verás una sección con [ProxyList]. Por defecto, suele haber una línea comentada que dice #socks4 127.0.0.1 9050 o similar. Debemos agregar la línea correspondiente a Tor:

socks5 127.0.0.1 9050

Asegúrate de que no haya otras líneas descomentadas que puedan interferir (a menos que quieras una cadena de varios proxies). Guarda el archivo y cierra.

Con esto, Proxychains ya está listo para usar.

Guarda los cambios y sal del editor.

Paso 3: Arrancar el servicio Tor

Iniciamos y habilitamos el servicio Tor en el sistema:

sudo systemctl enable --now tor

Puedes verificar que está activo y corriendo con:

sudo systemctl status tor

Puedes verificar que Tor está escuchando en el puerto 9050:

sudo netstat -tulpn | grep 9050

Paso 4: Comprobar tu IP pública en la terminal

Prueba a realizar una petición con curl normal y luego mediante proxychains:

# Tu IP real:
curl ifconfig.me

# Tu IP anónima (Nodo de salida de Tor):
proxychains curl ifconfig.me

¡4 métodos para probar el modo incógnito total en Firefox!

A continuación te detallo cada una de ellas:

Método 1: Cierre completo e inyección con Proxychains (Vía Terminal)

Es el método más directo si prefieres no cambiar nada en la configuración interna de Firefox.

1. Cierra completamente Firefox (asegúrate de que no quede ningún proceso en segundo plano):
   killall firefox-esr || killall firefox
2. Lánzalo mediante Proxychains:
   proxychains firefox

• Ventaja: No altera tus ajustes de uso diario. Al cerrar el navegador, todo vuelve a la normalidad.
• Inconveniente: Si abres otra ventana sin usar la terminal, volverá a salir por tu red habitual.

Cualquier comando que ejecutes antecedido por proxychains saldrá a internet a través de la red Tor.

Método 2: Configuración manual en ajustes (El método estándar)

Si vas a usar un equipo o máquina virtual dedicada exclusivamente a la navegación anónima, puedes dejar los ajustes fijados en el propio navegador.

1. Abre Firefox y ve a Ajustes > General > Configuración de red (al final de la página) y pulsa en Ajustes…
2. Selecciona Configuración manual del proxy.
3. En Host SOCKS, introduce 127.0.0.1 y en Puerto9050.
4. Marca la casilla SOCKS v5.
5. Paso crítico: Activa la opción DNS remoto (Proxy DNS al usar SOCKS v5). Esto evita las temidas fugas de DNS (DNS leaks).

Método 3: Crear un perfil de Firefox dedicado (Recomendado)

Esta es la solución más limpia si utilizas el mismo ordenador para tu día a día y para tareas de anonimato. Te permite tener un Firefox «normal» y un Firefox «Tor» funcionando al mismo tiempo sin que interfieran.

1. Abre el gestor de perfiles de Firefox:
   firefox -P
2. Crea un perfil nuevo llamado, por ejemplo, Anonimo.
3. Inicia Firefox con ese perfil y aplica la Configuración manual del proxy SOCKS5 (los pasos del Método 2).
4. Lanzamiento independiente: A partir de este momento, puedes lanzar tu perfil anónimo desde la terminal o mediante un acceso directo sin tener que cerrar tu Firefox habitual:
   Bashfirefox -P "Anonimo" --no-remote (El parámetro --no-remote es la clave para obligar a Firefox a crear una instancia de proceso totalmente separada en memoria).

Método 4: Extensión conmutadora rápida (FoxyProxy)

Si prefieres alternar entre tu conexión nativa y la red Tor con un solo clic desde la barra de herramientas:

1. Instala la extensión FoxyProxy Standard desde la tienda de complementos de Firefox.
2. Añade un nuevo proxy con los siguientes datos:
   • Tipo: SOCKS5
   • IP / Host:127.0.0.1
   • Puerto:9050
   • DNS remoto: Activado
3. Guarda y activa el perfil de Tor desde el icono de la extensión cuando lo necesites, y desactívalo para volver a tu velocidad nativa.

Resumen de uso

¡Valor añadido!

Truco pro: Cambiar la IP de salida: el truco y su alternativa

Cuando usas random_chain, Proxychains alternará la ruta, pero si necesitas refrescar tu identidad de salida de Tor inmediatamente desde la terminal sin reiniciar el servicio, puedes enviarle la señal SIGHUP al demonio de Tor:

sudo killall -HUP tor

Este comando envía una señal a Tor para que recargue su configuración, lo que puede renovar el circuito y darte una nueva IP de salida. Sin embargo, no siempre funciona: en algunas versiones, HUP solo recarga la configuración sin forzar un nuevo circuito, y es posible que la IP siga siendo la misma.

Si necesitas garantía de cambio, la opción más fiable y sencilla es reiniciar el servicio de Tor:

sudo systemctl restart tor

Este método es infalible: detiene y arranca Tor, lo que obliga a construir un circuito completamente nuevo y, por tanto, una nueva IP de salida. El único inconveniente es que interrumpe brevemente las conexiones activas que estén usando Tor.

Para usuarios avanzados: Si quieres un control más fino sin reiniciar el servicio, puedes habilitar el puerto de control de Tor (ControlPort 9051) y usar el comando signal NEWNYM para pedir un nuevo circuito. Pero para la mayoría de los casos, sudo systemctl restart tor es más que suficiente.

Ejecuta de nuevo

# Tu IP real:
curl ifconfig.me

# Tu IP anónima (Nodo de salida de Tor):
proxychains curl ifconfig.me

y verás que tu IP de salida ha cambiado en cuestión de segundos.

Matriz rápida de compatibilidad de herramientas

No todos los comandos reaccionan igual al pasar por un proxy. Aquí tienes una referencia rápida de qué funciona y qué requiere ajustes:

Consideraciones importantes

• Tráfico UDP y RAW: Tor solo enruta tráfico TCP nativo. Protocolos basados en UDP (como llamadas de voz, streaming en tiempo real o pings ICMP) no funcionarán a través de esta cadena.
• Velocidad vs Anonimato: Al saltar por múltiples nodos cifrados en diferentes partes del mundo, la latencia aumentará. Es una herramienta pensada para privacidad y anonimato puntual, no para descargas pesadas del día a día.

¡Excelente idea para una segunda entrega! Esta segunda parte complementa el primer artículo resolviendo el problema real con el que se topan casi todos los usuarios al intentar tunelizar Firefox hacia Tor.

Ejemplos prácticos de uso

• Navegación desde terminal:
  proxychains lynx https://check.torproject.org o proxychains elinks https://check.torproject.org para navegar por sitios web desde la terminal a través de Tor.
• Descarga de archivos:
  proxychains wget https://ejemplo.com/archivo.zip descargará el archivo de forma anónima.
• Clientes IRC:
  Si usas irssi o weechat, puedes lanzarlos con proxychains y así ocultar tu IP real en los chats.
• Escaneo de puertos con Nmap:
  proxychains nmap -sT -Pn -p 80,443 192.168.1.1 (nota: solo escaneo TCP, y con -Pn para omitir el ping ICMP). Es útil para hacer escaneos externos sin revelar tu IP, aunque ten en cuenta que Tor no está diseñado para escaneos masivos y puede ser lento.
• Conexiones SSH:
  proxychains ssh usuario@servidor te permite conectarte a un servidor SSH a través de Tor, aunque la latencia será alta.
• Uso con herramientas de pentesting:
  Muchas herramientas como sqlmap, nikto, etc., se pueden anteponer con proxychains para ocultar el origen.
• Clonar repositorios de Git de forma anónima:
  Descarga el código fuente de un proyecto público (o privado mediante HTTPS) sin dejar rastro de nuestra ubicación ni de nuestra IP pública en los registros (logs) de servidores como GitHub, GitLab o Bitbucket.
  proxychains git clone https://github.com/usuario/proyecto.git
  

Verificación final.

Verificación rápida: ejecuta este comando para confirmar que todo funciona:

proxychains curl https://check.torproject.org/api/ip

Si la respuesta contiene "IsTor": true, todo está correcto.

Conclusión

Como has visto, combinar Tor con Proxychains en Linux es una forma sencilla y efectiva de anonimizar el tráfico de cualquier aplicación de terminal. Ya sea para proteger tu privacidad al navegar, para realizar pruebas de seguridad o simplemente por curiosidad, esta dupla te ofrece un control total sobre el enrutamiento de tus conexiones.

Recuerda siempre mantener Tor actualizado y ser consciente de las limitaciones. La privacidad es un proceso, no un producto, y cada herramienta suma en ese camino.

Migrar un blog, especialmente cuando cambias el sistema operativo de base (en este caso, de un entorno Debian 12 a un Raspberry Pi OS basado en Debian 13), es un proyecto sumamente divertido y una oportunidad excelente para aprender.

El proceso es bastante sencillo si se siguen los pasos adecuados. Básicamente, consiste en empaquetar el blog (tanto los archivos como la base de datos) desde el disco antiguo para luego desempaquetarlo en el nuevo. A continuación, te guío paso a paso para que puedas hacerlo tú mismo sin perder absolutamente nada en el camino.

Resumen

1. Instalar WordPress: Hazlo en el nuevo disco, exactamente igual que aquí Instala WordPress en tu Raspberry Pi 4.
2. Respaldar el Blog Viejo (MX Linux): Hacer una copia de seguridad de los archivos de WordPress y de la base de datos.
3. Migrar los Datos al Nuevo Servidor: Copiar los archivos y la base de datos al disco nuevo.
4. Ajustar la Configuración: Revisar el archivo wp-config.php para que use la nueva base de datos.
5. Dar los Toques Finales: Aplicar los permisos correctos y listo.

Ahora, vamos a verlo en detalle.

Paso 1: Prepara tu Nuevo Servidor (Raspberry Pi OS)

Como la finalidad de esta entrada no es explicar cómo instalar WordPress desde cero, te recomiendo echar un vistazo a mi artículo «Instala WordPress en tu Raspberry Pi 4«. Aunque ya tiene algún tiempo, sigue siendo perfectamente vigente tanto para las nuevas versiones de Linux y de la base de datos, como para el propio CMS.

Prepara la Base de Datos:

Antes de crear la base de datos, toma nota del nombre y contraseña que usaste anteriormente, ejecutando en tu antiguo WordPress este comando.

sudo nano /var/www/html/wp-config.php

Busca las siguientes líneas y toma nota de los datos que ahí aparecen. (especialmente la contraseña):

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wordpress' );
define( 'DB_PASSWORD', 'tu_contraseña_segura' );
define( 'DB_HOST', 'localhost' );

Ahora crea la base de datos con los datos que hemos apuntado.

Accede a MariaDB usando los mismos nombres y contraseña que los del antiguo blog para evitar cambios.

sudo mysql -u root -p
CREATE DATABASE wordpress;
CREATE USER wordpress@localhost IDENTIFIED BY 'tu_contraseña_segura';
GRANT ALL PRIVILEGES ON wordpress.* TO wordpress@localhost;
FLUSH PRIVILEGES;
EXIT;

Paso 2: Respaldar el Blog en tu Raspberry Pi Vieja (MX Linux)

Este es el paso más crítico. Vamos a comprimir todos los archivos y a exportar la base de datos.

1- Comprime los archivos de WordPress:

En tu Raspberry Pi vieja, ejecuta:

# Ve al directorio donde está WordPress
cd /var/www/html/
# Comprime TODO el contenido en un archivo llamado 'mi_blog_backup.tar.gz'
sudo tar -czvf mi_blog_backup.tar.gz .

Este comando creará un archivo comprimido. Te recomiendo que lo muevas a tu carpeta de usuario para poder acceder a él fácilmente más tarde:

sudo mv mi_blog_backup.tar.gz /home/tu_usuario/

2- Exporta la base de datos:

Aún en la terminal de la Raspberry Pi vieja, ejecuta:

# Tenemos que ser root para trabajar con esto. No podemos hacerlo con sudo
sudo -i# Ahora que eres root, exporta toda la base de datos 'wordpress' a un archivo .sql 
mysqldump -u wordpress -p wordpress > wordpress_backup.sql 
# Te pedirá la contraseña del usuario 'wordpress' de la base de datos que ya viste cuando preparaste la base de datos

Al igual que con los archivos, si no estás en el directorio /home/tu_usuario/, te recomiendo mover el archivo .sql allí:

mv wordpress_backup.sql /home/tu_usuario/

Ahora ya puedes salir con un exit para volver a ser un plebeyo.

Paso 3: Copiar los Respaldos a la Nueva Raspberry Pi

Ahora tienes dos archivos en la Raspberry vieja: mi_blog_backup.tar.gz y wordpress_backup.sql. Vamos a pasarlos a la nueva.

El método más sencillo es usar es usar un pendrive o memoria usb, copiarlos y pegarlos en la nueva Raspberry.

Pero si por algún extraño motivo, no tienes acceso a la antigua raspberry porque está alojada en el bunker de la Casa Blanca y no quieres ir allí y tropezarte por los pasillos con Donald Trump, existe el modo de utiliizar rsync o scp desde la nueva Raspberry Pi.

En una terminal de tu nuevo sistema, ejecuta:

# Copia el archivo comprimido de los temas, plugins y medios
rsync -avz tu_usuario@IP_DE_LA_RASPBERRY_VIEJA:/home/tu_usuario/mi_blog_backup.tar.gz /tmp/

# Copia el archivo .sql de la base de datos
rsync -avz tu_usuario@IP_DE_LA_RASPBERRY_VIEJA:/home/tu_usuario/wordpress_backup.sql /tmp/

Recuerda cambiar tu_usuario por tu nombre de usuario y IP_DE_LA_RASPBERRY_VIEJA por su IP.

Paso 4: Restaurar los Datos en la Nueva Raspberry Pi

¡Ya estamos en la recta final! Ahora trabajaremos completamente en tu nueva Raspberry Pi.

Como siempre voy por el camino mas fácil, he transferido desde un pendrive los archivos a mi directorio home, con lo que trabajaremos desde ahí.

1- Restaura los archivos de WordPress

Limpia el directorio por defecto de Apache (por si acaso)

sudo rm -rf /var/www/html/*

Ve al directorio donde copiaste el backup, en mi caso en la /home

cd ~

Descomprime todo el backup directamente en el directorio web

sudo tar -xzvf mi_blog_backup.tar.gz -C /var/www/html/

2- Restaura la base de datos.

Aún en el directorio /home, importa el archivo .sql a tu nueva base de datos ‘wordpress’. Te pedirá la contraseña que creaste en el Paso 1 para el usuario ‘wordpress’ (o la que uses)

mysql -u wordpress -p wordpress < wordpress_backup.sql

Nota: Si cambiaste el nombre de la base de datos, el usuario o la contraseña en el Paso 1, debes actualizar el archivo de configuración de WordPress.

sudo nano /var/www/html/wp-config.php

Busca las siguientes líneas y asegúrate de que los datos son correctos (especialmente la contraseña):

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wordpress' );
define( 'DB_PASSWORD', 'tu_contraseña_segura' );
define( 'DB_HOST', 'localhost' );

Guarda el archivo con Ctrl+O, Enter, y luego Ctrl+X para salir.

3– Configura los permisos correctos:
Para que WordPress pueda funcionar sin problemas (instalar plugins, subir imágenes, etc.), el usuario del servidor web (www-data) debe ser el propietario de los archivos.

sudo chown -R www-data:www-data /var/www/html/

Paso 5: Toques Finales

Ya está. Ahora toca la mejor parte: comprobar que todo funciona.

1. Prueba tu blog: Abre un navegador web en la dirección IP de tu nueva Raspberry Pi (por ejemplo, http://192.168.1.XX).
   • Si ves tu blog con normalidad, ¡la migración ha sido un éxito!
   • Si ves un error de «Error al establecer la conexión con la base de datos», revisa de nuevo el paso 4.3 (el wp-config.php).
   • Si ves un error de «404» o «No encontrado» al intentar entrar al panel de administración (/wp-admin), prueba a volver a guardar los enlaces permanentes: ve a Escritorio > Ajustes > Enlaces permanentes y simplemente haz clic en «Guardar cambios». Esto regenerará las reglas de enrutamiento de WordPress .
2. Redirige el tráfico de Internet (Punto final): Cuando estés completamente seguro de que todo funciona en tu nueva Raspberry Pi, ha llegado el momento de hacer el cambio definitivo.
   • Actualiza tu DNS Dinámico (DuckDNS): Si usas DuckDNS, simplemente actualiza la IP en tu cuenta de DuckDNS para que apunte a la nueva IP de tu Raspberry Pi (esto asumiendo que ambas están en la misma red doméstica y usan la misma IP pública). Si la nueva Pi tiene una IP local diferente, asegúrate de que el reenvío de puertos (80 y 443) de tu router esté apuntando a la nueva IP.
   • Certificados SSL (Let’s Encrypt): Una vez que el tráfico ya se dirige a la máquina nueva, renueva el certificado SSL con Certbot en la nueva Raspberry Pi para que HTTPS siga funcionando. El comando es el mismo que usaste la primera vez:
     bash sudo certbot --apache
     Sigue las instrucciones y, cuando te pregunte sobre redirigir el tráfico, elige la opción 2 para redirigir de HTTP a HTTPS.

Ánimo, que con esta guía paso a paso es muy difícil equivocarse. Es un proceso muy gratificante. Si te surge alguna duda durante el proceso, puedes consultar foros como el de Raspberry Pi, donde hay mucha comunidad y suelen ayudar con estos temas .

¡Mucha suerte con la mudanza de tu blog!

Este es el último manual de una lista que debes poner en marcha en el siguiente orden.

1. WireGuard en Raspberry PI, VPN casera, segura y gratuita.
2. Pi-hole en Raspberry Pi: Instalación paso a paso.
3. Configura tu propio servidor DNS recursivo con Pi-hole y Unbound
4. El manual definitivo para navegar 100% seguro con WireGuard, Pi-hole y Unbound.

Comenzamos.

Una vez hayas completado todos los manuales anteriores, como vimos en WireGuard en Raspberry PI, VPN casera, segura y gratuita. no deberías usar las DNS de Google (8.8.8.8) que se detallaban en el apartado «6.2. Crear los archivos de configuración de cada cliente«.

Porque tu cliente de WireGuard en el móvil tiene grabada a fuego la directiva DNS = 8.8.8.8 en su perfil actual. Al levantar el túnel, el sistema operativo de tu móvil le hace caso a esa línea y envía las consultas DNS a Google a través del túnel.

El objetivo principal de montar tu propia infraestructura es mantener la privacidad y, de paso, aprovechar el bloqueo de publicidad y rastreadores de Pi-hole incluso cuando estás fuera de casa. Para lograrlo, la dirección IP que debes poner en el apartado DNS de las configuraciones de los clientes varía según cómo quieras resolver las peticiones dentro del túnel:

La prueba de dnsleaktest

Cuando estás conectado a la VPN con el DNS de Google (8.8.8.8), las páginas de test verán que tus peticiones vienen de los servidores de Google. Si usas tu servidor recursivo, verán la IP pública de tu casa (la de tu proveedor de internet).

1. Conéctate a la VPN desde fuera de casa (o quita el WiFi y usa datos móviles).
2. Entra en la página web: dnsleaktest.com
3. Verás tu IP pública actual. Haz clic en el botón «Standard test».
4. Analiza el resultado:
   • Si sale Google (generalmente con banderas de tu país, o donde esté el servidor más cercano) o ves IPs que no te pertenecen: Sigues usando el DNS de Google configurado en la interfaz.
   • Si sale únicamente tu proveedor de internet (Movistar, Digi, Orange, etc.) con la IP de tu casa: Significa que tu petición ha viajado por la VPN hasta tu Raspberry Pi, y de ahí Unbound ha salido a internet a resolverla. El sistema recursivo está funcionando.

La captura del test muestra claramente que las peticiones se están resolviendo a través de servidores pertenecientes a Google en Madrid. Esto significa que, aunque el resto de tu tráfico (la navegación general) sí vaya cifrado por la VPN, las preguntas de «¿a qué IP pertenece esta web?» se le siguen enviando directamente a Google en el formato tradicional, saltándose por completo tu Raspberry Pi con Pi-hole y Unbound.

Cómo solucionar el problema en 3 pasos:

Para solucionarlo y hacer que tu servidor recursivo tome el control total, tienes que actualizar la configuración del cliente.

Paso 1. Modifica el archivo en la Raspberry Pi: Ve a la ruta donde guardas los perfiles de los clientes:

sudo nano /etc/wireguard/clients/phone_dad.conf

y edita el archivo cambiando la línea del DNS = 8.8.8.8 por:

[Interface]
PrivateKey = [clave privadaa]
Address = 10.0.0.2/32
DNS = 10.0.0.1

[Peer]
PublicKey = [clave_publica]
Endpoint = linuxete.duckdns.org:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Paso 2. Asegura el cambio en Pi-hole: Confirma que aplicaste el cambio a «Permit all origins» en la pestaña DNS de Pi-hole (y dale a Save & Apply si no lo hiciste antes) para que acepte las consultas que le lleguen desde la interfaz de WireGuard.

Paso 3. Actualiza el perfil en tu móvil:

En la terminal de la Pi, vuelve a generar el código QR con el archivo modificado:

sudo cat /etc/wireguard/clients/phone_dad.conf | qrencode -t ansiutf8

Escanea el nuevo QR desde la app de WireGuard en el móvil.

Una vez hecho esto, activa la VPN con tus datos móviles y vuelve a pasar el dnsleaktest.com. Si todo está en orden, los 6 servidores de Google deberían desaparecer y, en su lugar, debería figurar únicamente tu proveedor de internet local de casa.

Ahora cuando mi móvil solicita resolver un dominio desde la red móvil (o cualquier WiFi pública), la consulta viaja encriptada por el túnel de Wireguard directo a mi Raspberry Pi. Pi-hole la procesa y se la pasa a Unbound.

Como Unbound es un servidor DNS recursivo propio, no le pregunta a ninguna entidad comercial (ni a Google, ni a Cloudflare, ni a tu operador), sino que sale directamente a los Root Servers de internet usando tu propia conexión física de casa. Por eso de cara al test, el encargado de resolver la petición es, a todos los efectos, tu IP pública fija.

Hemos conseguido el combo ideal: Privacidad absoluta (DNS recursivo sin intermediarios), bloqueo de publicidad en movilidad (Pi-hole) y conexión segura (WireGuard). ¡Objetivo cumplido!

¡Hazlo desde la terminal!

Puede ser que no dispongas de un entorno gráfico o un navegador a mano para ir a dnsleaktest.com, pero si tienes una terminal, ¡tienes un tesoro!

Para comprobar qué DNS estás utilizando, abre tu consola y lanza un nslookup apuntando a cualquier dominio:

nslookup google.com

Fíjate bien en la primera línea de la respuesta, ya que te indicará qué servidor ha resuelto la petición:

• Si muestra Server: 8.8.8.8, estás saliendo a través de los DNS de Google.
• Si muestra Server: 127.0.0.1 (o la IP local de tu servidor), ¡enhorabuena! Estás usando con éxito tu propio combo de Pi-hole + Unbound.

Si quieres forzar la consulta directamente contra tu servidor para probarlo, puedes añadir su IP al final del comando:

~ $ nslookup google.com 10.0.0.1
Server:		10.0.0.1
Address:	10.0.0.1#53

Non-authoritative answer:
Name:	google.com
Address: 216.58.205.110

El «Efecto Termux»: ¿Por qué no siempre coincide en Android?

Si estás haciendo esta prueba desde un teléfono Android, debes tener en cuenta un detalle importante sobre cómo interactúan las aplicaciones con la red:

1. La app oficial de WireGuard: Intercepta el tráfico a nivel de VpnService (la capa de red del sistema). Cuando usas el navegador web del móvil, la API de la VPN secuestra esa solicitud DNS y la fuerza a ir por el túnel hacia la IP de tu Pi-hole.
2. El caso de Termux: Las herramientas de consola dentro de entornos emulados como Termux a veces se saltan las rutas DNS modificadas por las APIs de la VPN de Android. Debido a esto, pueden saltarse el túnel y exponer los servidores DNS del sistema base (los de tus datos móviles o la red WiFi).

En resumen: Si estás en una terminal nativa de Linux, un simple nslookup google.com bastará. Si estás en Termux dentro de Android y quieres asegurarte de que el túnel responde, fuerza la consulta especificando la IP interna de tu servidor: nslookup google.com 10.0.0.1.