Networking

Problema En entornos de auto‑hosting es frecuente combinar un contenedor que necesita salir a Internet (por ejemplo, qbittorrent) con una VPN basada en WireGuard. La práctica consiste en montar un archivo wg0.conf dentro del container y delegar la resolución DNS a un resolvedor interno como Unbound. Cuando la configuración parece correcta pero cualquier llamada a curl, ping o la propia aplicación muestra errores de tipo “Could not resolve host”, el contenedor queda sin acceso a la red externa aunque la interfaz wg0 esté UP. ...

Problema Muchos entusiastas de homelab llegan a un punto donde la combinación de varios nodos Proxmox y una red doméstica basada en VLANs empieza a mostrar limitaciones: la capacidad de la ISP no se aprovecha plenamente, la segmentación genera cuellos de botella y añadir nuevos servidores SFF complica la topología. El patrón típico es una infraestructura que crece sin una base de routing y switching que garantice aislamiento, rendimiento y facilidad de expansión. El reto es diseñar una arquitectura que: ...

Problema En entornos domésticos o de pequeña oficina, la mayoría de los filtros DNS se basa en listas negras estáticas. Esa aproximación funciona para bloquear anuncios o malware, pero no permite definir políticas diferenciadas por dispositivo ni por tipo de contenido. Cuando se necesita, por ejemplo, que los teléfonos de los niños bloqueen todo contenido adulto y juegos de apuestas mientras que los equipos de trabajo solo restrinjan redes sociales, la gestión manual de varias listas se vuelve inmanejable. El reto es crear un servicio DNS que: ...

Problema Los entornos auto‑alojados que combinan varios VPS, dispositivos locales y servicios críticos (bases de datos, agentes IA, stacks de trading) suelen optar por una topología hub‑and‑spoke basada en WireGuard. Cuando la red crece, aparecen tres patrones de falla recurrentes: Conexiones inter‑nodo inestables: la pérdida de un peer o la caída del hub corta el acceso a bases de datos y a los procesos de recolección. Backups que dejan de estar cifrados o no se replican: la ausencia de una capa de cifrado de disco y de un proceso de sincronización fiable expone datos sensibles. Superficie de ataque ampliada: sin filtros de tráfico, IDS/IPS y control de acceso, cualquier nodo comprometido puede convertirse en punto de salida para ataques externos. El reto es diseñar una arquitectura que mantenga la conectividad, garantice el cifrado de repositorios y minimice la exposición a amenazas, sin depender de servicios de terceros. ...

Problema En entornos domésticos o de pequeña oficina es frecuente delegar la resolución de nombres internos a un Pi‑hole instalado en un contenedor LXC. El objetivo es que cualquier dispositivo que consulte DNS obtenga tanto la filtración de publicidad como los registros locales (por ejemplo test.lan). Cuando los dispositivos siguen enviando consultas al router y el router reenvía a un servidor externo (Cloudflare, Google), los nombres internos no se resuelven y el navegador muestra “server IP address could not be found”. El síntoma típico es: ...

Problema Muchos usuarios de self‑hosting tienen el router de su casa detrás de un NAT estricto, una IP pública dinámica o simplemente no quieren exponer directamente la dirección IP del ISP. En esos entornos, publicar un servicio (web, SSH, Plex, etc.) requiere una solución que atraviese el NAT sin abrir puertos innecesarios en el router y sin depender de servicios de terceros como DynDNS. La necesidad recurrente es crear un túnel fiable entre la red doméstica y un punto accesible en Internet, y luego redirigir el tráfico entrante hacia los servidores internos. ...

Problema En muchos despliegues de Kubernetes se usan dos capas de balanceo: un VIP gestionado por Keepalived y un HAProxy que reenvía el tráfico a los pods de Traefik. Cuando el tráfico proviene de la red interna (VPN, túnel) llega sin problemas, pero cualquier petición desde la WAN termina en un reset o en una respuesta 404 de un servidor inesperado (por ejemplo, Microsoft‑HTTPAPI/2.0). El dashboard de HAProxy muestra cero sesiones para la IP pública, mientras que las capturas del firewall indican que el paquete se ha encaminado al VIP. El síntoma típico es: ...

Problema En entornos donde WireGuard se usa como puente entre una máquina cliente y un servidor de retransmisión, es frecuente encontrarse con que el cliente envía paquetes pero el servidor nunca los contabiliza como tráfico recibido. El túnel parece “up”, los handshakes aparecen en el cliente, pero en el servidor la estadística de transferencia permanece en 0 B y la conexión nunca se establece. El síntoma típico es: wg show muestra la interfaz activa en ambos extremos. tcpdump confirma que los paquetes UDP llegan al puerto 51820 del servidor. No hay handshakes visibles en el servidor para el peer problemático. El tráfico de retorno (respuesta del servidor al cliente) tampoco llega. Este comportamiento se traduce en una VPN que solo permite tráfico en una dirección o, peor aún, que parece estar operativa pero no transporta datos. El problema puede aparecer en despliegues con máquinas virtuales, entornos de nube, o redes con NAT y reglas de firewall complejas. ...