Sencilla protección desde nuestro router

Móviles, consolas, tabletas y televisores inteligentes forman parte de lo cotidiano en nuestro hogar. No sólo los adultos se conectan, y la seguridad y el control de contenidos en nuestra red doméstica pesa más cada día. Mejorar la protección de todos los dispositivos disponibles en el hogar se pueden hacer de forma muy sencilla configurando los servidores DNS del router.

He probado el Cloudflare Family DNS (Sistema de Nombres de Dominio), que está basado en el uso de las direcciones 1.1.1.3 y 1.0.0.3

Un servidor DNS se encarga de traducir las direcciones web en direcciones ip que son las que los dispositivos realmente entienden. Siempre tiene que haber un servidor DNS, que siempre ofrece el proveedor de Internet, pero puede ser sustituido por otros más rápidos y seguros. Así, Cloudflare Family DNS  es una versión especial del DNS público de Cloudflare que ofrece las siguientes ventajas:

• Bloquea sitios de malware
• Filtra contenido adulto
• Mantiene una alta velocidad de respuesta
• No necesita registro ni aplicaciones adicionales

Las direcciones que se utilizan son:

• DNS primario: 1.1.1.3
• DNS secundario: 1.0.0.3

Al configurarlas en el router, todos los dispositivos de casa se benefician automáticamente. 

 En mi caso, que así es en la mayoría de los router, para entrar en el router tecleamos en la barra de direcciones del navegador la siguiente ip: 192.168.1.1

Después de escribir el usuario y la contraseña, buscamos la opción LAN Devices, y hacemos clic en LAN setting:

En la pestaña IPV4, hacemos clic en DHCP Server:

 Y es aquí donde añadimos las ip de los DNS primario y secundario:

Procurar tomar nota de los DNS anteriores, los del proveedor, por si queréis volver a usar los que tenéis por defecto.

Atinar mq-deadline para un mini PC con SSD

 Reducir la latencia y evitar el colapso del sistema cuando se ejecutan las operaciones de lectura y escritura hacia el SSD es el cometido de mq-deadline (Multi-Queue deadline. Multi colas con tiempo máximo). El planificador por defecto de las operaciones de lectura y escritura hacia el SSD en los kernel modernos es mq-deadline, que usa blk-mq (Multi-Queue Block Layer), la moderna arquitectura del kernel que aprovecha las CPUs multinúcleo y dispositivos rápidos como SSD y NVMe.

mq-deadline se basa en tres principios simples:

• Separación de lecturas y escrituras. Las lecturas tienen prioridad, ya que bloquean procesos y afectan directamente a la fluidez del sistema.
• Deadlines por petición. Cada operación tiene un tiempo máximo de espera. Si se alcanza ese límite, la petición se ejecuta inmediatamente, aunque no sea la más eficiente de agrupar.
• Reordenamiento moderado. Agrupa peticiones cercanas cuando es posible, pero sin la complejidad de schedulers (planificadores) antiguos pensados para discos mecánicos.

El resultado es un comportamiento predecible, estable y de baja latencia, ideal para hardware moderno. 

 ¿Por qué mq-deadline es ideal para mini PC?

En mini PC con SSD o NVMe:

• El tiempo de acceso es muy bajo
• La prioridad es la latencia estable
• El consumo de CPU debe ser mínimo

mq-deadline cumple perfectamente estos objetivos:

• Excelente rendimiento en escritorio
• Buena respuesta bajo carga
• Comportamiento robusto en multitarea
• Muy bajo overhead (recursos redundantes para ejecutar una misma cosa)

Por eso es el scheduler por defecto en la mayoría de distribuciones.

 En un Terminal comprobamos si está activo mq-deadline por defecto ejecutando:

 cat /sys/block/sda/queue/scheduler

 

Si devuelve  none [mq-deadline] es que está activo. Si el SSD no está en sda, en el comando anterior ponerle el correspondiente.

Ahora, afinamos esos parámetros que idealizarán la ejecución de mq-deadline en nuestro mini PC:

Ejecutamos en un Terminal con permisos administrativos (root) los siguientes comandos:

echo 0 | tee /sys/block/sda/queue/rotational
echo 256 | tee /sys/block/sda/queue/nr_requests 

(Si usamos sudo, sería asi:

 echo 0 | sudo tee /sys/block/sda/queue/rotational
echo 256 | sudo tee /sys/block/sda/queue/nr_requests )

Reiniciamos el mini PC.
 

Aquí podemos ver el cambio realizado:

Comprobamos con el siguiente comando que está cargado:

ls /sys/block/sda/queue/iosched/

Si aparecen los siguientes archivos después de ejecutar el comando, todo OK.

fifo_batch, read_expire, write_expire, writes_starved

 Con el siguiente comando podemos ver cómo trabaja y cambian los valores de las variables cada vez que lo ejecutamos:

cat /sys/block/sda/stat

En una red social que uso, cuando navegaba --debido a la lentitud de la red WIFI-- tenía un lag que me ponía nervioso, y aunque también me enfurecía por lo que dicen en los comentarios de estas peculiares redes, lo cierto es que en esto y en otros menesteres se nota mejoría evidente.

El Mini con N5100, sin ventilar y ruido alguno, mola con estas pequeñas cosas. 

 

¿CUBIC o BBR+FQ? En mi caso, sin duda, BBR+FQ

 TCP Cubic es uno de los algoritmos de control de congestión de red, y suele ser el predeterminado en Linux, Unix y Windows. Funciona mejor en redes simples, sin WIFI, sin muchos flujos y saturaciones. Suele generar ping largos, lag y microcortes, porque empieza bien, apura locamente hasta que satura los buffers y empieza a perder paquetes, entendiendo así que debe reducir su velocidad, y repite el ciclo. 

A una red WIFI como la mía le va algo más  "inteligente", algo que, de antemano, mida el ancho de banda real, el RTT (Round Trip Delay o tiempo de ida y vuelta en redes sin perder paquetes), y ajuste el flujo de datos a una velocidad de crucero sin perder paquete alguno. Este protocolo es BBR (Botteneck Bandwidth and RTT) + FQ (Fair Queueing)  se ajusta mejor al perfil de las nuevas redes, y el otro, el TCP Cubic está más experimentado, pero nació en otro tiempo.

En todo tráfico tiene que haber un policía, ese es FQ (Fair Queuing), y depende del Kernel, diviendo el flujo en varias colas, reparte justamente la conexión, evita que aparezca el chupón de datos, como la pelota en el fútbol, y reduce el bufferbloat (colas demasiado largas, llenas de ingentes cantidades de datos). Buen poli.  

Hoy, con la IA, cualquiera puede ampliar este tema e investigar sobre ello lo que quiera, pero la experiencia propia todavía se requiere cuando realmente queremos saber hasta qué punto merece la pena cambiar. 

Todo esto es muy interesante, pero la verdad se vive, y no se enseña (cita de Hermann Hesse), por eso me propuse compararlos en la práctica en un miniPC como el mío. 

En un miniPC usado como ordenador personal creamos en /etc/sysctl.d/ el archivo 99-bbr.conf

Yo usé Thunar lanzado desde un terminal con permisos administrativos (root), y luego de forma gráfica cree el archivo en la carpeta correspondiente:

 

A ese archivo le añadimos el siguiente contenido abriendo el archivo, por ejemplo, con Mousepad:

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr 

 

Guardar y reiniciar.

 Podemos comprobar si está activado en nuestro sistema usando el siguiente comando en un terminal:

sysctl net.ipv4.tcp_congestion_control 

 

Tendrá que devolvernos bbr 

Usando este otro comando, podemos verificar si el policía se persona en la red:

 tc qdisc show

 

Debe de mostrar algo así:

qdisc fq 0: dev enp1s0 root refcnt 2 limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028b initial_quantum 15140b low_rate_threshold 550Kbit refill_delay 40ms timer_slack 10us horizon 10s horizon_drop

No colgaría esta entrada  si no tuviera la convicción de que  mereció la pena. En una red precaria como la mía mi miniPC parece agradecerlo, mostrando una agilidad en el "flow" de la WIFI que antes no percibía.

 Ya me contarán. Gracias.

 

WiFi 6 con AX201 y AX101

Dispongo de un miniPC Chuwi con el microprocesador N5100, al que no podía darle vida plena porque no era capaz de que Debian 12 reconociera el chip de Intel AX101. Por fin, después de darle muchas vueltas, logré lo imposible; ahora, no sólo reconoce el chip, sino que fui capaz de darle vida para disfrute completo del equipo. 

El N5100 es un microprocesador que tiene un rendimiento por vatio increíble. El chip que integra la WiFi y el Bluetooth es el AX101 (aunque en la imagen anterior aparece como AX201), que no parece llevarse muy bien con los núcleos y los controladores que en el mismo hay para que el sistema operativo trabaje adecuadamente, en concreto, con este hardware. Así, debido a esto, y como no quiero ser palizas, iremos al grano buscando un núcleo simpático que trague con un controlador que me tenía muy buena pinta de "trixie", la versión siguiente de "bookworm", y además no reclama dependencia alguna (un quebradero de cabeza menos).

 

El kernel o núcleo con el que va es el 6.12.27, y lo podemos instalar añadiendo previamente en el archivo /etc/apt/sources.list  el repositorio de backsports correspondiente. Editamos el archivo, y añadimos el siguiente repositorio:

 #Repositorios Backports

deb https://ftp.debian.org/debian/ bookworm-backports contrib main non-free non-free-firmware

Luego, usando en un Terminal el comando siguiente, instalaremos la versión del núcleo que precisamos:

apt install -t bookworm-backports linux-image-amd64

No olviden REINICAR EL EQUIPO después de instalar el nuevo núcleo.