VPN + DNS - Infraestructura de Red Centralizada

12 contenedores. 1 solo dominio de red. 10 túneles WireGuard + 2 servidores DNS con sinkhole que operan como una unidad: acceso remoto segmentado con resolución DNS controlada en cada conexión.

Por qué están unificados

VPN y Pi-hole no son capas independientes en esta infraestructura — son interdependientes. Los túneles WireGuard exponen segmentos de red interna a clientes remotos, y los Pi-hole operan como resolvedores DNS autoritativos para la red local (10.2.2.0/24) a los que cada túnel delega sus consultas por defecto. Esto implica:

Cada cliente que establece un túnel WireGuard recibe automáticamente: - Resolución DNS mediante un sinkhole que intercepta consultas, las coteja contra adlists y responde con NXDOMAIN (0.0.0.0 ::1) para dominios no autorizados - Reenvío (forwarding) recursivo a un resolver DNS upstream público con filtrado para el resto de consultas - La misma política de resolución centralizada sin importar desde dónde se conecte

Separar ambos componentes en documentación independiente rompe la visibilidad de su relación funcional. Unificados exponen el cuadro completo: una red privada con acceso tunelizado escalable y control de resolución DNS en cada capa.

Resumen

10 túneles WireGuard + 2 resolvedores con sinkhole = 1 dominio de red unificado con resolución DNS centralizada y segmentación de acceso por túnel.

Diagrama de Red

graph TB
    subgraph DNS_Upstream["Upstream DNS"]
        CF[Resolver Público Recursivo<br/>con filtrado]
    end

    subgraph Docker_Host["Host - Motor de Contenedores"]

        subgraph VPN_Prod["Segmento Producción<br/>10.2.2.0/24"]
            WG1["Túnel WireGuard 1<br/>wg-easy"]
            WG2["Túnel WireGuard 2<br/>wg-easy"]
            WG3["Túneles WireGuard 3-9<br/>wg-easy"]
            PH_P["Pi-hole Admin<br/>DNS Sinkhole<br/>10.2.2.100"]
        end

        subgraph VPN_Test["Segmento Pruebas<br/>10.9.0.0/24"]
            WG_T["Túnel WireGuard Test<br/>wg-easy"]
            PH_T["Pi-hole Test<br/>DNS Sinkhole<br/>10.2.2.200"]
        end

    end

    WG1 -->|"consulta DNS"| PH_P
    WG2 -->|"consulta DNS"| PH_P
    WG3 -->|"consulta DNS"| PH_P
    PH_P -->|"forwarding recursivo"| CF

    WG_T -->|"consulta DNS"| PH_T
    PH_T -->|"forwarding recursivo"| CF

    style Docker_Host fill:#1a1a2e,color:#fff,stroke:#16213e
    style VPN_Prod fill:#0f3460,color:#fff,stroke:#e94560
    style VPN_Test fill:#16213e,color:#fff,stroke:#e94560
    style DNS_Upstream fill:#533483,color:#fff,stroke:#e94560
    style CF fill:#e94560,color:#fff

Stack tecnológico

Los túneles de producción delegan su resolución DNS al Pi-hole Admin, que aplica filtrado por adlists y reenvía al upstream recursivo público. El túnel de pruebas utiliza su propia instancia Pi-hole aislada para validar configuraciones sin impacto en el segmento productivo.

Qué problemática resuelve

Conjunto de 10 instancias WireGuard y 2 instancias Pi-hole que operan de forma conjunta para proporcionar acceso remoto seguro y segmentado con resolución DNS centralizada y controlada a nivel de red. Los túneles convergen en el mismo segmento interno (10.2.2.0/24) y todos delegan su resolución DNS en el Pi-hole de producción como resolver autoritativo local. Esto implica que cualquier dispositivo que se conecte a cualquier túnel envía sus consultas DNS al sinkhole antes de que estas se reenvíen al upstream recursivo. El Pi-hole de pruebas permite ajustar listas de filtrado (adlists), whitelist y blacklist sin afectar la resolución de los clientes activos en producción. Esta arquitectura elimina la necesidad de configurar resolución DNS dispositivo por dispositivo y segmenta el acceso a la red interna por cliente o proyecto sin multiplicar servidores físicos.

WireGuard - Túneles VPN

Qué resuelve

Diez instancias WireGuard independientes que segmentan el acceso a la red interna por cliente, proyecto o entorno sin compartir configuración ni bases de usuarios. Cada instancia opera como un túnel VPN autónomo con panel de administración wg-easy, gestión de peers, exportación de configuración mediante QR y políticas de resolución DNS propias, todo sobre la misma infraestructura subyacente (mismo host, mismo segmento 10.2.2.0/24, mismo resolver DNS Pi-hole). Esto evita desplegar un servidor VPN por cada necesidad, centraliza la administración de túneles y permite añadir o aislar instancias sin afectar las existentes. La instancia de prueba sobre segmento bridge aislado (10.9.0.0/24) permite validar configuraciones sin riesgos para los túneles productivos.

Túneles 1-9 (Producción)

Stack común

Túnel de Pruebas

Segmento aislado sobre bridge propio (10.9.0.0/24) para experimentar con configuraciones de túneles sin impacto en los entornos productivos.

| Túnel | WireGuard (wg-easy:15) | | Segmento de red | Bridge aislado 10.9.0.0/24 |

Pi-hole - Servidor DNS con Sinkhole

Qué resuelve

Servidor DNS centralizado que opera como sinkhole: recibe consultas DNS de toda la red, las coteja contra listas de dominios no autorizados (adlists) y responde con NXDOMAIN (0.0.0.0 / ::1) antes de que la consulta se reenvíe al upstream recursivo. Con dos instancias Pi-hole se separa el plano de resolución: la instancia de producción opera como resolver autoritativo para toda la VPN con forwarding condicional al upstream público con filtrado, y la instancia de pruebas permite validar adlists, whitelist y blacklist sin afectar la resolución de los clientes activos. Esto evita configurar resolución DNS por dispositivo y proporciona un entorno de staging para ajustar políticas de filtrado antes de promoverlas a producción.

Pi-hole Admin (Producción)

Servidor DNS con sinkhole: recibe consultas del segmento 10.2.2.0/24, las filtra contra adlists y responde con NXDOMAIN para dominios bloqueados antes de alcanzar el upstream recursivo. Mejora los tiempos de resolución mediante caché de respuestas (TTL configurable) y reduce consultas recursivas innecesarias hacia el upstream.

Configuración: - Autenticación web vía WEBPASSWORD - DNSMASQ_LISTENING: all (interfaz compartida) - Volúmenes persistentes: /etc/pihole + /etc/dnsmasq.d

Pi-hole Test (Entorno de Pruebas)

Entorno aislado para validar configuraciones de resolución DNS (adlists, whitelist, blacklist, upstream alternativos) sin afectar el resolver principal que sirve al segmento productivo.