Contexto y objetivo
Organicé mi red doméstica como un entorno de aprendizaje de sistemas y redes: conectar los equipos, administrar servicios en Linux, acceder de forma remota y conservar copias recuperables de los datos.
El proyecto reúne tareas habituales de soporte e infraestructura: diagnóstico de conectividad, configuración de DNS, administración de acceso, almacenamiento y comprobación de servicios. También proporciona la base de red de mi laboratorio SOC.
Topología
La red combina un router doméstico, un switch gestionable TP-Link TL-SG105E, un punto de acceso Cisco WAP561, un PC Windows y una Raspberry Pi 5 con Linux.
El router enlaza con el switch, al que se conectan el PC, el punto de acceso y la Raspberry. Además de su conexión normal, la Raspberry recibe una copia del tráfico del PC mediante mirroring. El esquema omite las direcciones e identificadores privados.
El diagrama se carga al entrar en esta sección.
flowchart TD R["Router"] --- S["Switch gestionable"] S --- P["PC Windows"] S --- A["Punto de acceso Wi-Fi"] S --- L["Raspberry Pi y servicios"] P -. "Copia mediante switch" .-> LLa línea discontinua representa el flujo duplicado, no un cable directo entre PC y Raspberry. Las redes Wi-Fi configuradas no se presentan como segmentos aislados: la implantación de VLANs quedó pospuesta.
Mapa interactivo · topología simplificada
Explora mi laboratorio
Selecciona un equipo para ver cómo encaja en la red y qué funciones cumple. Este esquema representa la arquitectura, no un panel en directo.
Entrada y salida de la red
Router
El router del proveedor conecta la red doméstica con Internet y enlaza con el switch gestionable.
- Punto de partida de las conexiones locales.
- La topología no muestra direcciones ni ajustes privados.
Conexiones y copia de tráfico
Switch
Distribuye la conexión entre el PC, el punto de acceso y la Raspberry Pi. También duplica el tráfico del PC hacia el sensor para su análisis.
- Mirroring del PC en ambos sentidos hacia la Raspberry.
- No se presenta como una red segmentada por VLANs.
Equipo de usuario y virtualización
PC Windows
El equipo Windows genera eventos de seguridad y aloja la máquina virtual que ejecuta el servidor Wazuh.
- Agente Wazuh y Sysmon para los eventos del endpoint.
- VirtualBox aloja la VM de Wazuh.
Conectividad inalámbrica
Punto de acceso
El punto de acceso amplía la conectividad Wi-Fi de los equipos y dispositivos domésticos.
- Red principal y SSID para dispositivos IoT.
- Los SSID no implican aislamiento de red mediante VLANs.
Sensor Linux y servicios autogestionados
Raspberry Pi
La Raspberry Pi 5 recibe la copia de tráfico del PC y aloja las herramientas y servicios que gestiono en Linux.
- Suricata y agente Wazuh para detección y envío de eventos.
- Pi-hole, Tailscale, Nextcloud y Home Assistant como servicios de infraestructura.
Análisis y consulta de alertas
Servidor Wazuh
La máquina virtual ejecuta los componentes del servidor Wazuh y recibe eventos de los agentes Windows y Linux.
- Manager, Indexer y Dashboard en VirtualBox.
- La disponibilidad del servidor depende de que el PC anfitrión esté encendido.
Red, DNS y acceso remoto
- Visibilidad de tráfico. Configuré el mirroring del puerto del PC en ambos sentidos hacia el sensor y comprobé su recepción con una captura.
- Filtrado DNS. Instalé Pi-hole y probé consultas desde Windows por la red local y por Tailscale. El filtrado DNS complementa otras medidas; no sustituye un firewall.
- Acceso privado. Utilizo Tailscale para acceder por SSH a la Raspberry y por escritorio remoto al PC, sin abrir puertos de entrada en el router para esos accesos.
- Administración de Linux. Configuré el acceso SSH con claves y deshabilité el inicio de sesión de root y la autenticación por contraseña en la Raspberry.
Una incidencia documentada fue el aviso «DNS unavailable» de Tailscale en Android, cuya causa quedó sin demostrar. La resolución correcta desde Windows no permite dar ese aviso por resuelto.
Servicios y almacenamiento
Nextcloud funciona en contenedores con PostgreSQL y Redis, con HTTPS privado mediante Tailscale Serve. Separé la aplicación y la base de datos en SSD de los datos de usuario en HDD; los discos se montan por UUID para no depender del orden de detección USB.
Los servicios de la Raspberry pueden seguir disponibles aunque el PC esté apagado. En cambio, el servidor Wazuh virtualizado depende de ese equipo. Esta diferencia es relevante al diagnosticar una caída: no todos los servicios comparten la misma dependencia.
Copias y comprobación de recuperación
Preparé copias automáticas de configuraciones y bases de datos de Pi-hole, con retención e integridad mediante SHA-256. Para Nextcloud, la documentación recoge snapshots Restic y su duplicación en un segundo repositorio local, en el HDD.
Se recuperaron archivos de forma parcial, incluida una comparación SHA-256 idéntica entre el archivo original y el restaurado. También se probó un fallo simulado del monitor de copias y su recuperación, con el aviso correspondiente en Home Assistant.
Estas comprobaciones validan los escenarios ensayados. La restauración completa de Nextcloud con PostgreSQL sigue pendiente, y dos discos conectados al mismo equipo no equivalen a una copia externa.
Evidencias visuales
Esta selección muestra el equipo de red, la configuración de mirroring, un panel histórico de supervisión y un aviso de prueba del monitor de copias. Las lecturas son puntuales y el aviso no acredita una restauración integral de Nextcloud.
Selecciona una imagen para ampliarla. En el visor puedes usar las flechas y cerrar con Esc.
Qué me aportó
El trabajo me permitió relacionar problemas de DNS, conectividad y disponibilidad con sus dependencias reales. También reforzó una práctica útil en soporte: registrar qué cambio hice, cómo comprobé el resultado y qué queda por verificar.
Esta ficha se basa en la documentación del laboratorio con corte técnico del 25 de octubre de 2026. No expone direcciones, configuraciones originales ni accesos a los servicios. Se incorporan cuatro capturas revisadas; la validación de una recuperación integral de Nextcloud sigue pendiente.