Linux

Problema Los firewalls basados en pfSense suelen estar en producción durante meses o años. Cuando el proyecto lanza una versión mayor, como la 2.9.0, aparecen tres tipos de fricción recurrente: Actualización interrumpida – el proceso de upgrade falla o deja el appliance sin acceso a la UI. Incompatibilidad de certificados – los nuevos requisitos de fuerza TLS hacen que los certificados auto‑generados o de CAs internos dejen de ser aceptados. Nuevas opciones de NAT o algoritmos criptográficos – la configuración existente no reconoce los cambios y el tráfico comienza a comportarse de forma inesperada. Cualquier sysadmin que haya intentado subir una versión de pfSense en un entorno de producción sabe que, aunque la actualización sea “un clic”, la realidad está en los detalles que quedan fuera del asistente gráfico. ...

Problema En entornos de virtualización con Proxmox es frecuente que, después de un apagón inesperado o un reinicio forzado del host, alguna máquina virtual (VM) arranque sin problemas y sea accesible vía SSH, pero la consola integrada del panel web (noVNC) quede estática. El usuario ve una pantalla negra o un cursor que no responde, mientras que la VM sigue ejecutándose normalmente. Este comportamiento impide el uso rápido de la consola para tareas de diagnóstico o para máquinas sin acceso SSH. ...

Problema En entornos con cientos o miles de servidores Linux, la trazabilidad de cambios suele estar fragmentada. Los equipos de operaciones gestionan parches en un sistema (por ejemplo, un repositorio apt o dnf), la autorización de esos cambios se registra en una herramienta de tickets o una hoja de cálculo, y el acceso real a la máquina se controla mediante bastiones, claves estáticas o soluciones de gestión de secretos. Cuando un auditor pide evidencia de que “Juan Pérez estuvo autorizado a aplicar el parche X en la máquina host01 el 12‑03‑2024 y lo hizo con su propia credencial”, el responsable debe combinar logs de gestión de paquetes, registros de bastión y auditorías de tickets. Esa costosa costura manual genera errores, lagunas y, en el peor caso, incumplimiento. ...

Problema En infraestructuras que combinan Proxmox, TrueNAS, Docker, servidores Linux y Windows, cada componente genera su propio conjunto de métricas y eventos. Cuando el número de nodos crece, la rutina de abrir la consola de cada host, revisar el estado de los backups, validar los scrubs de ZFS, inspeccionar logs de contenedores y comprobar la salud de discos se vuelve una tarea diaria que consume tiempo y, lo peor, se abandona. La consecuencia típica es que fallos críticos (una copia de seguridad corrupta, un disco a punto de morir, un contenedor atrapado en bucle de reinicio) pasan desapercibidos hasta que provocan una interrupción visible. ...

Problema En entornos de auto‑hosting es frecuente querer que una aplicación específica, como SearXNG, utilice una VPN para todas sus peticiones externas. La necesidad surge cuando se desea ocultar la IP del servidor, evitar bloqueos geográficos o simplemente separar el tráfico de búsqueda del resto del tráfico de la máquina. El reto consiste en forzar que solo el proceso que corre bajo el usuario searxng (UID 999) salga por la interfaz wg-<nombre> sin afectar a los demás servicios ni romper la conectividad de la propia VM. ...

Problema En entornos Linux que requieren acceso a recursos protegidos por Azure VPN Point‑to‑Site (P2S) con autenticación Entra ID, la única herramienta oficial es un cliente GUI. Cuando se ejecuta en contenedores, CI/CD runners o servidores sin sesión de escritorio, esa dependencia se vuelve un bloqueo. El síntoma típico es que la conexión nunca se establece; el proceso OpenVPN finaliza después del handshake con un error de autenticación, aunque el usuario ya haya iniciado sesión con az login. La raíz del problema no es la falta de un token, sino que el cliente oficial usa un client‑id propio (41b23e61‑6c1e‑4545‑b367‑cd054e0ed4b4) como audiencia del token. Un token genérico de Azure CLI no coincide y el gateway lo descarta. ...

Problema En entornos homelab con Proxmox, es frecuente combinar varios tipos de discos (NVMe, HDD, SSD) y usar ZFS como capa de datos primaria. El reto aparece cuando se necesita exponer esos datos a usuarios finales mediante SMB o NFS, y se delega la gestión de usuarios y permisos a una instancia de OpenMediaVault (OMV). La arquitectura típica —ZFS en el hipervisor, OMV en una VM o LXC, y discos de respaldo en RAID‑1— genera conflictos de permisos, latencia en escritura y complejidad en la planificación de backups. El síntoma más común es que los clientes Windows o Linux ven archivos con UID/GID inesperados o que los snapshots de ZFS no se sincronizan correctamente con los procesos de rsync programados. ...

Problema En entornos Proxmox que utilizan LXC containers sobre un LVM‑Thin pool, es frecuente migrar el disco de arranque a un SSD más rápido o con mayor capacidad. Tras una clonación del disco (por ejemplo con Clonezilla) el nodo arranca sin problemas, pero los containers aparecen “desaparecidos” o fallan al iniciar con errores como: mount: /var/lib/lxc/.pve-staged-mounts/rootfs: wrong fs type, bad option, bad superblock on /dev/mapper/pve-vm--201--disk--0 pct start 201 --debug En la interfaz de local‑lvm los volúmenes aparecen con el tamaño correcto pero con “0 GB” consumidos. El síntoma típico es que el LV sigue existiendo en la tabla de LVM, pero el thin pool no reconoce los datos o la metadata está corrupta. El resultado es que los containers no pueden montar su raíz y el hook lxc-pve-prestart-hook aborta. ...

Problema Muchos entusiastas de homelab quieren reutilizar hardware antiguo para crear un NAS doméstico que ofrezca redundancia, snapshots y acceso remoto sin exponer servicios críticos a Internet. El desafío consiste en combinar un hipervisor ligero (Proxmox), un sistema de archivos robusto (ZFS) y un servidor de archivos (Samba) mientras se mantiene una estrategia de backup fuera del pool y se protege el acceso remoto. Causa Los fallos habituales en estos setups provienen de: ...

Problema Al montar varios servicios (gateway LLM, agente de mensajería, servidor multimedia y escritorio remoto) en una única VM de 4 vCPU, es frecuente encontrarse con que los contenedores arrancan, los puertos parecen abiertos y, sin embargo, nada responde. Los logs aparecen vacíos o con mensajes genéricos como “command not found” o “permission denied”. La raíz suele ser una combinación de reglas de firewall invisibles, políticas de reinicio que no reintentan, y permisos de usuario que no coinciden con los archivos creados durante la instalación. ...