VPN entre oficinas + DHCP: cómo evitar conflictos de IP y el caos

El modelo mental: qué se rompe realmente cuando conectas oficinas

Un VPN sitio a sitio no es magia. Es una tubería. Las tuberías no negocian semántica; mueven paquetes. El caos comienza
cuando esos paquetes contienen suposiciones que eran aceptables en aislamiento:

• Suposición #1: “192.168.1.0/24 significa mi oficina.” Después del VPN, puede significar “ambas oficinas.” Eso no es un significado; es una colisión.
• Suposición #2: DHCP es “local e inofensivo.” No lo es. DHCP es un plano de control para identidad (IP), enrutamiento (gateway por defecto) y resolución de nombres (DNS).
• Suposición #3: El descubrimiento por broadcast funcionará entre oficinas. No lo hará, a menos que deliberadamente hagas bridging, y el bridging es cómo importas cada problema L2 a tu red L3.
• Suposición #4: “El VPN es lento” cuando una ruta está mal, el DNS está dividido, o la MTU está silenciosamente devorando tus paquetes.

El VPN cambia el dominio de fallos. Un error tipográfico en una oficina ahora falla en ambas. Un servidor DHCP malicioso en una oficina ahora
tiene un campo de caza mayor (dependiendo de bridging/relays). Y tu resolución de problemas se complica porque
los síntomas aparecen lejos de las causas.

Si quieres una sola frase que guíe tu diseño, úsala:
Mantén cada oficina como un dominio L3 independiente, conéctalas por enrutamiento y centraliza solo lo que puedas monitorear y restringir.

Una cita digna de una nota adhesiva para trabajo con VPN y DHCP: La esperanza no es una estrategia. — Gene Kranz.
Sí, viene del control de misión, no de redes. El punto se mantiene.

Chiste #1: Un VPN sitio a sitio es como un matrimonio: no soluciona tus problemas de comunicación, solo los hace más ruidosos.

Datos interesantes y contexto histórico (porque la historia se repite)

1. RFC 1918 (1996) nos dio rangos IPv4 privados (10/8, 172.16/12, 192.168/16). Resolvió la escasez de direcciones y creó el deporte moderno de las subredes solapadas.
2. DHCP se estandarizó a principios de los 1990 (como evolución de BOOTP). Fue diseñado para LANs con broadcast; la historia “a través de una WAN” llegó después mediante relays.
3. Los dominios de broadcast siempre fueron un límite de escalado. Las redes de campus aprendieron rápido que la expansión L2 convierte “un equipo defectuoso” en “misterio a nivel empresa”.
4. IPsec (finales de los 1990) buscaba asegurar IP en Capa 3. Muchas implementaciones aún construyen accidentalmente comportamiento de Capa 2 encima y lo pagan caro.
5. NAT no estaba pensado para ser para siempre. Fue un parche práctico por el agotamiento de IPv4. Aún está aquí y sigue rompiendo supuestos end-to-end y complicando el troubleshooting.
6. Split DNS existe porque la realidad es desordenada. La idea de respuestas diferentes según dónde preguntes es anterior a muchos equipos “cloud-native”.
7. “El VPN es lento” se volvió un tropo porque los problemas de MTU son silenciosos. La historia de los agujeros negros de PMTUD es larga y llena de pérdida de paquetes.
8. Los conjuntos de opciones DHCP se convirtieron en un sistema de configuración de facto. Teléfonos, arranque PXE, impresoras y controladores Wi‑Fi esperan opciones específicas, así que errores en DHCP causan apagones sorprendentemente concretos.
9. BGP sobre IPsec es común hoy para enrutamiento dinámico entre sitios, pero solo funciona bien cuando tu plan de direccionamiento es sensato desde el inicio.

Estrategia de direccionamiento IP: la parte que debes decidir desde el inicio

Regla 1: nunca permitas subredes solapadas entre sitios

Si la Oficina A y la Oficina B usan 192.168.1.0/24, no tienes un “problema de VPN.” Tienes un problema de identidad.
La tabla de enrutamiento no puede distinguir “192.168.1.50 en Oficina A” de “192.168.1.50 en Oficina B.” Verás:
enrutamiento asimétrico, rarezas de ARP si haces bridge, y conectividad intermitente si alguien añade NAT como parche.

La opinión tajante: renumera un sitio a menos que tengas una razón comercial de corto plazo para usar NAT como táctica puente.
NAT a veces es necesario, pero nunca es el estado limpio final.

Regla 2: asigna desde un plan real, no desde sensaciones

Elige un rango privado lo bastante grande para crecer, luego divide por sitio y función. Un patrón simple:

• 10.64.0.0/10 reservado para redes internas corporativas.
• Cada oficina recibe un /16: Oficina A = 10.64.0.0/16, Oficina B = 10.65.0.0/16, etc.
• Dentro del /16, divide en /24: usuarios, servidores, voz, impresoras, Wi‑Fi, invitados, gestión.

¿Por qué /16 por sitio? Porque renumerar es caro, y la gente subestima el crecimiento y las redes “temporales”.
También hace las rutas simples y resumibles.

Regla 3: decide dónde vive el gateway por defecto de cada VLAN

Si tienes un router/firewall por sitio, mantiene los gateways por defecto locales. Un gateway por defecto remoto sobre VPN convierte cada
paquete en tráfico WAN. Tus usuarios lo notarán. Tu cola de incidentes lo notará más.

Regla 4: documenta la fuente de la verdad autorizada

Necesitas un enfoque mínimo de IPAM, aunque sea “un repositorio Git con YAML.” Lo que importa es que exista un lugar único
donde subredes, ámbitos DHCP, reservas y direcciones estáticas clave estén registradas y revisadas.

Patrones de DHCP sobre VPN (y por qué la mayoría son malos)

Patrón A: DHCP permanece local en cada oficina (recomendado)

Cada sitio ejecuta su propio servidor DHCP (o par HA) para sus subredes locales. El VPN solo lleva tráfico enrutado.
Este es el dominio de fallo más simple: si el servidor DHCP del Sitio B muere, al Sitio A no le importa.

Centraliza DNS si quieres. Centraliza autenticación si debes. Pero mantiene DHCP cerca de los clientes a menos que
tengas razones operativas sólidas.

Patrón B: servidor DHCP central con relay DHCP en cada sitio (funciona, pero sé disciplinado)

Esto puede funcionar si quieres gestión centralizada de ámbitos y opciones consistentes. La clave es que los relays deben estar
correctamente configurados, y el VPN debe ser fiable. Recuerda: los leases expiran incluso si tu WAN está caída.

Si eliges esto, ajusta tiempos de lease más largos para sitios remotos y asegúrate de que la información del agente relay (Opción 82)
se use intencionalmente o se desactive de forma consistente. La descoincidencia de opciones puede convertir la resolución de problemas en algo que parece encantado.

Patrón C: puentear L2 a través del VPN (no lo hagas, a menos que te guste el dolor)

Hacer bridging significa que el broadcast DHCP atraviesa el VPN, ARP atraviesa el VPN y cada “quién tiene” se convierte en una conversación
entre sitios. Esto empeora la seguridad y la estabilidad. Puede justificarse en casos de nicho (protocolos heredados,
redes muy pequeñas, migraciones breves), pero debe venir con un plan de salida explícito.

Patrón D: NAT para ocultar solapamiento (aceptable como vía de escape temporal)

Cuando las subredes se solapan y no puedes renumerar de inmediato, puedes NATear un lado para que el otro vea un rango traducido.
“Funciona” en el sentido de que los paquetes se mueven. Falla en el sentido de que la identidad se vuelve extraña: los logs mienten, las ACLs se vuelven
incómodas, y cualquier cosa que incruste IPs (algunos VoIP, ciertos sistemas de licencias, rarezas antiguas de SMB) puede romperse.

Chiste #2: NAT es como barrer la suciedad bajo la alfombra—impresionante hasta que tropiezas con la alfombra.

Diseño de ámbitos DHCP: evita las trampas sutiles

• Reserva rangos para estáticos (equipos de red, servidores, hipervisores). No “simplemente elijas algo fuera del pool” sin documentarlo.
• Usa reservas DHCP para impresoras y endpoints especiales. Las IPs aleatorias de impresoras son cómo las colas de tickets alcanzan la inmortalidad.
• Estandariza conjuntos de opciones (servidores DNS, dominios de búsqueda, NTP). Si tienes varios servidores DHCP, mantiene las opciones consistentes mediante gestión de configuración.
• Mantén tiempos de lease sensatos: 8–24 horas para redes de usuarios, más largos para dispositivos estables. Leases ultra-cortos crean churn durante la inestabilidad de la WAN.

Enrutamiento, NAT y por qué “simplemente hacer NAT” es una trampa

Rutas estáticas vs enrutamiento dinámico

Para dos oficinas con un puñado de subredes, las rutas estáticas están bien. Añade un tercer sitio, o múltiples VLAN por sitio,
y las rutas estáticas se vuelven un impuesto de gestión de cambios. Ahí es cuando consideras:

• OSPF para enrutamiento interno si controlas ambos extremos y quieres convergencia rápida.
• BGP si quieres control explícito de rutas y resúmenes limpios a través de túneles.

El enrutamiento dinámico no es “teatro empresarial.” Es cómo dejas de olvidar una ruta durante una migración estresante.

Túnel dividido vs malla completa

No hagas hairpin del tráfico de Internet a través de un VPN “por seguridad.” Es una decisión de política con un coste de rendimiento.
Si lo haces, hazlo conscientemente: dimensiona los enlaces, ajusta la MTU, monitoriza y acepta que voz/video se quejarán primero.

MTU: el saboteador silencioso

IPsec añade overhead. GRE añade overhead. WireGuard añade overhead. Si no ajustas MTU o no aplicas clamp MSS, obtienes
fragmentación y problemas de PMTUD. El síntoma clásico: pings pequeños funcionan, transferencias grandes se congelan, y HTTPS a veces
caduca de maneras que parecen aleatorias.

Límites de seguridad

Un VPN no es un modelo de permisos. Aún necesitas políticas de firewall: qué subredes pueden comunicarse, qué puertos están permitidos,
dónde viven las interfaces de administración y cómo registras los denegados. “Las pusimos en un VPN para que accedan a todo” es cómo
conviertes un PC comprometido en una oficina en un incidente multisito.

Tres mini-historias de la vida corporativa

Mini-historia 1: un incidente causado por una suposición errónea

Una compañía mediana adquirió una firma más pequeña y apresuró la “conexión de oficinas” para que finanzas pudiera acceder al ERP.
Los diagramas de red se veían limpios. El VPN subió en el primer intento. Todos felicitaron al equipo y volvieron a sus calendarios.

En pocas horas, el helpdesk recibió tickets: impresoras en la oficina adquirida estaban “offline,” luego “online,” luego “offline”
otra vez. Los teléfonos VoIP se reiniciaban al azar. Algunos portátiles podían alcanzar sistemas internos; otros no. Se culpó al VPN.

La suposición errónea fue simple: ambos lados usaban 192.168.0.0/24 para la LAN principal, porque claro que sí. Las tablas de enrutamiento en ambos firewalls tenían redes conectadas idénticas.
Así que cada lado creía que 192.168.0.50 era local. Los paquetes ni siquiera entraban al túnel. La gente intentó añadir rutas estáticas (lo que no ayudó) y ajustar tiempos de IPsec
(que tampoco ayudó).

La solución no fue glamorosa: renumerar la oficina adquirida a una subred única, luego actualizar ámbitos DHCP, configuraciones de impresoras
y un puñado de dispositivos estáticos. Durante la transición, usaron NAT temporal para permitir que algunos sistemas críticos hablaran.
Cuando la renumeración terminó, la “inestabilidad del VPN” desapareció de la noche a la mañana.

La lección: el túnel no es tu capa de identidad. El direccionamiento IP lo es. Trátalo como tal.

Mini-historia 2: una optimización que salió mal

Otra organización quiso “simplificar la gestión” centralizando DHCP en el data center principal. La oficina remota solo ejecutaría un relay.
Sonaba limpio: una configuración de ámbito, un lugar para auditar opciones, un proceso de cambio.

Luego un proveedor WAN tuvo una semana mala. Caídas cortas—30 segundos aquí, dos minutos allá. Nada lo bastante largo como para declarar una caída total.
Lo bastante largo para ser infinitamente molesto.

Lo que falló no fueron los clientes existentes; fue el churn. Los teléfonos se reiniciaron tras parpadeos de energía, portátiles se movieron entre SSIDs,
y clientes Wi‑Fi intentaron renovar. Los relays no pudieron alcanzar el servidor DHCP central durante las caídas. Los clientes cayeron a APIPA o retuvieron leases obsoletos
que ya no coincidían con DNS. Parecía que “el Wi‑Fi es inestable,” porque así fue como lo percibieron las personas.

“Optimizaron” más bajando tiempos de lease para hacer el reuso de IP más eficiente. Eso incrementó la frecuencia de renovaciones,
lo que aumentó la dependencia de la WAN inestable. El equipo construyó una máquina de fallos de alta frecuencia y luego se preguntó por qué era ruidosa.

La solución: mover DHCP de vuelta al sitio (o añadir un par de failover local), aumentar tiempos de lease y tratar la centralización como
una herramienta—una que tiene requisitos de fiabilidad. Centraliza cuando el enlace sea tan aburrido como la electricidad. Si no, mantenlo local.

Mini-historia 3: la práctica aburrida pero correcta que salvó el día

Una empresa regulada tenía una política que parecía burocrática: cada asignación de subred iba a una hoja IPAM respaldada por un repositorio Git,
revisada por dos personas. Los cambios de ámbito DHCP requerían un ticket corto y una lista de verificación de validación previa/post.
A nadie le encantaba. Todos cumplían porque las auditorías eran reales.

Durante una mudanza apresurada de oficina, un contratista instaló un router “temporal” con DHCP habilitado sobre un banco de laboratorio. En muchos lugares,
ahí la historia se convierte en una caída de dos días. Aquí, se convirtió en una molestia de 20 minutos.

El ingeniero on-call siguió la lista: verificar ofertas DHCP, identificar la IP del servidor, encontrar el puerto del switch vía tabla MAC,
cerrar el puerto y luego validar la renovación en un cliente de prueba. Los registros IPAM hicieron obvio qué ámbitos eran legítimos y cuáles no.
El historial del ticket de cambio mostró una actualización de ámbito planificada que aún no se había aplicado, evitando un segundo traspié.

La revisión del incidente fue casi aburrida. Ese es el punto. El “impuesto del proceso” se pagó por adelantado, así que la factura por la caída fue pequeña.

Guía de diagnóstico rápido

Cuando “VPN + DHCP” se sale de madre, puedes perder horas adivinando. No lo hagas. Triagera como si lo sintieras.
Tu objetivo es encontrar la clase de cuello de botella rápidamente: solapamiento de direcciones, enrutamiento, autoridad DHCP, DNS o MTU.

Primero: confirma si tienes redes solapadas

• Compara las LAN(s) del sitio local con las LAN(s) del sitio remoto. Si hay solapamiento, detente y planifica remediación o NAT.
• Revisa rutas: si el mismo prefijo existe como “conectado” en ambos extremos, tienes un conflicto de diseño.

Segundo: confirma la simetría de enrutamiento y la política de firewall

• ¿Puede el Sitio A alcanzar la interfaz del router del Sitio B? ¿Puede el Sitio B alcanzar la del Sitio A?
• ¿Existen rutas de retorno? ¿La política permite el tráfico en ambas direcciones?
• Revisa reglas de NAT asimétricas que reescriben solo una dirección.

Tercero: decide si es DHCP, DNS o MTU

• Problema DHCP si los clientes reciben gateway/DNS incorrectos, advertencias de IP duplicada o direcciones APIPA.
• Problema DNS si ping por IP funciona pero los nombres fallan, o nombres internos resuelven a destinos públicos/incorrectos.
• Problema MTU si pings pequeños funcionan, cargas grandes fallan y HTTPS/SMB son inestables.

Cuarto: captura paquetes en el lugar correcto

Capturar en el cliente está bien. Capturar en la interfaz del router hacia la LAN es mejor.
Capturar en la interfaz del túnel es lo mejor cuando estás demostrando qué cruzó el VPN.

Tareas prácticas con comandos (qué ejecutar, qué significa, qué decidir)

Estas tareas asumen routers/servidores basados en Linux para ejemplos. Las ideas se traducen directamente a pfSense/OPNsense, DHCP de Windows,
y firewalls gestionados; lo importante es qué verificas y por qué.

Tarea 1: listar interfaces locales y subredes (detecta solapamientos obvios)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.64.10.2/24
eth1             UP             10.64.20.1/24

Qué significa: este host está directamente conectado a 10.64.10.0/24 y 10.64.20.0/24.
Decisión: compara estos prefijos con los prefijos de la oficina remota. Si hay solapamiento, estás en modo de remediación, no de ajuste.

Tarea 2: inspeccionar la tabla de enrutamiento (demuestra a dónde irá el tráfico)

cr0x@server:~$ ip route
default via 10.64.10.1 dev eth0
10.64.10.0/24 dev eth0 proto kernel scope link src 10.64.10.2
10.64.20.0/24 dev eth1 proto kernel scope link src 10.64.20.1
10.65.0.0/16 via 10.64.10.254 dev eth0

Qué significa: el tráfico a 10.65.0.0/16 (oficina remota) va vía 10.64.10.254 (probablemente el router VPN).
Decisión: si las redes remotas no están presentes aquí, añade rutas (estáticas o dinámicas). Si ves una ruta más específica que apunta a otro lado, corrige ese conflicto primero.

Tarea 3: verificar estado del túnel (no investigues DHCP a través de un túnel caído)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2lQf...redacted...
  listening port: 51820

peer: 3mHf...redacted...
  endpoint: 203.0.113.10:51820
  allowed ips: 10.65.0.0/16
  latest handshake: 42 seconds ago
  transfer: 1.23 GiB received, 980 MiB sent

Qué significa: WireGuard está arriba e intercambiando tráfico recientemente.
Decisión: si los handshakes están obsoletos, arregla el túnel primero (claves, firewall, NAT, alcanzabilidad). Ninguna lógica DHCP importa hasta que los paquetes fluyan.

Tarea 4: probar alcance y ruta (confirma enrutamiento y ACLs)

cr0x@server:~$ ping -c 3 10.65.10.1
PING 10.65.10.1 (10.65.10.1) 56(84) bytes of data.
64 bytes from 10.65.10.1: icmp_seq=1 ttl=63 time=22.1 ms
64 bytes from 10.65.10.1: icmp_seq=2 ttl=63 time=21.7 ms
64 bytes from 10.65.10.1: icmp_seq=3 ttl=63 time=22.4 ms

--- 10.65.10.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Qué significa: existe conectividad L3 al menos hasta el gateway remoto.
Decisión: si el ping falla, revisa rutas y firewall. Si el ping funciona pero las aplicaciones fallan, probablemente estés tratando con DNS, MTU o filtrado a nivel de puerto.

Tarea 5: probar MTU con pings “sin fragmentar” (encuentra el agujero negro)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.65.10.1
PING 10.65.10.1 (10.65.10.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420

--- 10.65.10.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Qué significa: tu MTU efectiva en el camino es menor que 1500; 1420 es común para WireGuard.
Decisión: aplica clamp TCP MSS en el túnel o establece MTU apropiada en las interfaces. Si ignoras esto, seguirás “depurando” SMB/HTTPS inestables para siempre.

Tarea 6: mostrar leases DHCP en un servidor Linux (valida el comportamiento de ámbitos)

cr0x@server:~$ sudo tail -n 8 /var/lib/dhcp/dhcpd.leases
lease 10.64.10.101 {
  starts 5 2025/12/27 10:22:10;
  ends 5 2025/12/27 22:22:10;
  cltt 5 2025/12/27 10:22:10;
  binding state active;
  hardware ethernet 3c:52:82:aa:bb:cc;
  client-hostname "laptop-hr";
}

Qué significa: el servidor está entregando direcciones en la subred esperada a una MAC conocida.
Decisión: si los leases muestran direcciones de un ámbito equivocado o subredes inesperadas, has configurado mal ámbitos o relays (o tienes un servidor DHCP malicioso en otra parte).

Tarea 7: olfatear ofertas DHCP (atrapa DHCP rogue y relays mal configurados)

cr0x@server:~$ sudo tcpdump -ni eth0 -vvv 'port 67 or port 68' -c 6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:31:00.102345 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:52:82:aa:bb:cc, length 300
10:31:00.105210 IP 10.64.10.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, yiaddr 10.64.10.101, Server-ID 10.64.10.5
10:31:00.106901 IP 10.64.10.250.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, yiaddr 10.64.10.199, Server-ID 10.64.10.250

Qué significa: dos servidores DHCP diferentes están ofreciendo leases (10.64.10.5 y 10.64.10.250).
Decisión: encuentra y desactiva el servidor rogue o aíslalo. En un escenario VPN multisito, confirma que no hayas puenteado L2 accidentalmente o relayed DHCP donde no debes.

Tarea 8: comprobar si hay un relay DHCP configurado (y a dónde reenvía)

cr0x@server:~$ ps aux | grep -E 'dhcrelay|isc-dhcrelay' | grep -v grep
root      1123  0.0  0.1  18720  4120 ?        Ss   10:01   0:00 /usr/sbin/dhcrelay -4 -i eth1 10.64.10.5

Qué significa: esta máquina reenvía solicitudes DHCP desde la interfaz eth1 al servidor DHCP 10.64.10.5.
Decisión: si ese servidor está al otro lado del VPN, asegúrate de que el relay tenga enrutamiento estable, que el firewall permita UDP 67/68 y que los tiempos de lease sean apropiados para la dependencia WAN.

Tarea 9: validar resolución DNS desde un sitio remoto (separa DNS de enrutamiento)

cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.64.20.10
       DNS Servers: 10.64.20.10 10.64.20.11
        DNS Domain: corp.example

Link 2 (eth0)
Current Scopes: DNS

Qué significa: el sistema usa servidores DNS internos (10.64.20.10/.11).
Decisión: si un cliente de oficina remota apunta a un servidor DNS inalcanzable (por falta de rutas o firewall), DHCP “funciona” pero entrega configuración inutilizable. Corrige las opciones DHCP o el enrutamiento.

Tarea 10: demostrar resolución de nombres vs conectividad (deja de culpar al VPN por el DNS)

cr0x@server:~$ getent hosts fileserver.corp.example
10.65.20.20     fileserver.corp.example

Qué significa: DNS (o NSS) resuelve el nombre a una IP remota.
Decisión: si la resolución falla pero el ping a la IP funciona, debes arreglar el DNS (forwarders, split-horizon, dominios de búsqueda u opción DHCP 15/6). Si la resolución funciona pero la conexión falla, es enrutamiento/firewall/MTU.

Tarea 11: trazar la ruta (detecta saltos asimétricos o inesperados)

cr0x@server:~$ tracepath 10.65.20.20
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.64.10.254                                          1.012ms
 2:  10.65.0.1                                            22.104ms
 3:  10.65.20.20                                          23.001ms reached
     Resume: pmtu 1420 hops 3 back 3

Qué significa: el tráfico cruza el router VPN y alcanza el destino; PMTU es 1420.
Decisión: si la lista de saltos muestra hairpin por Internet o un router inesperado, corrige tus rutas. Si PMTU es bajo y las apps fallan, aplica clamp MSS.

Tarea 12: comprobar contadores de firewall para tráfico descartado (demuestra problemas de política)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "eth1" ip saddr 10.65.0.0/16 ip daddr 10.64.20.0/24 accept
    counter packets 0 bytes 0 drop
  }
}

Qué significa: la política forward por defecto es drop; solo se permite un flujo específico wg0→eth1. Existe un contador de drop que puede estar aumentando en otros lugares.
Decisión: si los contadores muestran drops para flujos esperados, ajusta la política intencionalmente. Si “permites todo temporalmente” para probar, recuerda revertir; las reglas temporales tienen la costumbre de volverse arquitectura permanente.

Tarea 13: detectar IPs duplicadas desde un endpoint (ARP te denunciará)

cr0x@server:~$ ip neigh show dev eth0 | grep '10.64.10.101'
10.64.10.101 lladdr 3c:52:82:aa:bb:cc REACHABLE

Qué significa: la IP mapea a una MAC en este momento.
Decisión: si esta MAC cambia frecuentemente sin que el dispositivo se mueva, puedes tener conflictos de IP o un servidor DHCP rogue. Correlaciona con logs DHCP y tablas MAC del switch.

Tarea 14: identificar el puerto del switch para una MAC sospechosa (encuentra la caja rogue)

cr0x@server:~$ ssh admin@switch-a01 "show mac address-table address 3c:52:82:aa:bb:cc"
Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    3c:52:82:aa:bb:cc DYNAMIC     Gi1/0/24

Qué significa: la MAC se aprendió en el puerto Gi1/0/24 en VLAN 10.
Decisión: si ese puerto conduce a un switch no gestionado o a un router “temporal”, ciérralo o muévelo a una VLAN aislada. Luego vuelve a probar ofertas DHCP.

Tarea 15: validar identidad del servidor DHCP desde un cliente Windows (común en oficinas)

cr0x@server:~$ ssh user@winclient "ipconfig /all | findstr /I \"DHCP Server IPv4 Address\""
   DHCP Server . . . . . . . . . . . . : 10.64.10.5
   IPv4 Address. . . . . . . . . . . : 10.64.10.101

Qué significa: el cliente está obteniendo lease de 10.64.10.5.
Decisión: si el servidor DHCP cambia entre renovaciones, tienes múltiples respondedores DHCP. Eso es un problema de contención, no un “ajuste de VPN”.

Tarea 16: confirmar opciones DHCP entregadas (errores de gateway/DNS parecen cortes de VPN)

cr0x@server:~$ sudo dhclient -v -1 eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 10.64.10.120 from 10.64.10.5
DHCPREQUEST for 10.64.10.120 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.64.10.120 from 10.64.10.5
bound to 10.64.10.120 -- renewal in 36000 seconds.

Qué significa: la negociación DHCP tuvo éxito.
Decisión: inspecciona la ruta aplicada y resolv.conf después de esto. Si el gateway apunta a un sitio remoto sobre VPN por accidente, corrige las opciones del ámbito; no culpes al túnel por hacer lo que le dijiste.

Errores comunes: síntoma → causa raíz → solución

1) “Algunos usuarios pueden alcanzar la oficina remota, otros no”

• Síntoma: acceso intermitente; un escritorio funciona, otro no; reiniciar “lo arregla” brevemente.
• Causa raíz: subredes solapadas, o múltiples servidores DHCP asignando gateways/DNS distintos.
• Solución: elimina el solapamiento renumerando; olfatea ofertas DHCP; apaga el DHCP rogue; estandariza opciones de ámbito.

2) “El VPN está arriba pero nada enruta”

• Síntoma: el túnel muestra conectado/handshake OK, pero las subredes remotas son inalcanzables.
• Causa raíz: rutas faltantes (o allowed IPs faltantes en WireGuard), o política de forward del firewall bloqueando.
• Solución: añade rutas explícitas en ambos lados; verifica reglas de forward/NAT; confirma la simetría de ruta de retorno con tracepath.

3) “DNS funciona localmente, falla desde la otra oficina”

• Síntoma: ping por IP funciona; nombres hacen time out; o resuelven a targets equivocados.
• Causa raíz: DHCP entrega servidores DNS inalcanzables; split DNS mal configurado; firewall bloquea TCP/UDP 53 a través del VPN.
• Solución: asegúrate de que sitios remotos puedan alcanzar los servidores DNS; añade resolvers caché locales si es necesario; permite DNS a través del VPN; valida con getent/dig.

4) “SMB/HTTPS es inestable, pero el ping funciona”

• Síntoma: copias de archivos se estancan; apps web cargan parcialmente; RDP a veces se congela.
• Causa raíz: MTU/agujero PMTUD; falta de clamp MSS.
• Solución: aplica clamp TCP MSS en el túnel; ajusta MTU en interfaces; vuelve a probar con ping -M do y tracepath PMTU.

5) “Tras conectar el VPN, las impresoras empezaron a duplicarse o cambiar IPs”

• Síntoma: las IPs de impresoras cambian; las colas de impresión fallan; aparecen advertencias de IP duplicada.
• Causa raíz: impresora en DHCP con configuración estática recordada; dos sitios usan la misma subred de impresoras; o no se usan reservas DHCP.
• Solución: reserva MACs de impresoras; mantén impresoras en una VLAN dedicada por sitio; evita subredes de impresoras solapadas; documenta estáticos en IPAM.

6) “La Wi‑Fi de invitados puede ver recursos corporativos tras el proyecto VPN”

• Síntoma: clientes invitados alcanzan IPs o servicios internos.
• Causa raíz: dominios de encriptación VPN/allowed IPs demasiado amplios; reglas de firewall no segmentadas; rutas filtradas entre VRFs/VLANs.
• Solución: restringe selectores/allowed IPs del VPN a las subredes necesarias; aplica política inter-VLAN; bloquea explícitamente guest→corp sobre el túnel.

7) “Todo se rompe durante caídas de WAN, luego se recupera lentamente”

• Síntoma: tras breves caídas, muchos endpoints pierden conectividad; la recuperación toma horas.
• Causa raíz: DHCP centralizado dependiente de la WAN; tiempos de lease cortos; dependencia DNS remota sin caché local.
• Solución: mantiene DHCP local o añade failover local; alarga leases; despliega resolvers caché locales; trata la WAN como poco fiable hasta comprobar lo contrario.

8) “Arreglamos el solapamiento con NAT, ahora los logs y ACLs son raros”

• Síntoma: las herramientas de seguridad muestran la gateway NAT como origen; reglas por host no funcionan bien; el troubleshooting es más difícil.
• Causa raíz: NAT oculta direcciones reales por diseño; cambiaste claridad de enrutamiento por complejidad de traducción.
• Solución: usa NAT solo como herramienta de migración con tiempo limitado; implementa renumeración; actualiza ACLs para coincidir con el direccionamiento real; mejora logs con registros de traducción NAT durante la transición.

Listas de verificación / plan paso a paso

Paso a paso: diseñar un nuevo VPN entre oficinas sin arrepentimientos futuros

1. Inventaria las subredes en ambos sitios. Lista cada VLAN/subred, incluyendo Wi‑Fi de invitados, voz, impresoras, gestión y redes “temporales” de laboratorio.
2. Elige un plan de direcciones consistente. Asigna al menos un /16 por sitio si puedes. Escríbelo en tu fuente de la verdad.
3. Define qué debe ser alcanzable. Matriz subnet-a-subnet: quién necesita hablar con quién, en qué puertos. Denegar por defecto, luego permitir deliberadamente.
4. Elige el modelo DHCP. Prefiere DHCP local por sitio. Si centralizas, comprométete con la configuración de relays, monitorización y leases más largos.
5. Decide la arquitectura DNS. Resolutores centrales están bien si son alcanzables; si no, usa cachés locales que reenvíen a centrales. Planifica split DNS para zonas internas.
6. Elige la estrategia de enrutamiento. Rutas estáticas para entornos pequeños y estables. Enrutamiento dinámico cuando el crecimiento o la frecuencia de cambios es alta.
7. Ingeniería de MTU desde el inicio. Ajusta MTU/MSS del túnel temprano. Valida con pruebas do-not-fragment.
8. Restringe selectores/allowed IPs del VPN. Publicita solo los prefijos internos que intentas enrutar. Nada de “0.0.0.0/0 porque funcionó”.
9. Monitorización y logs. Estado túnel, latencia, pérdida de paquetes, salud del servidor DHCP, latencia DNS, denegados de firewall. Si no puedes verlo, no puedes operarlo.
10. Ejecuta un plan de pruebas pre-cutover. Lease DHCP, resolución DNS, conectividad a servicios clave y una prueba de transferencia de archivos (SMB/HTTPS) para detectar MTU.

Paso a paso: cuando ya tienes subredes solapadas

1. Confirma el solapamiento e identifica el radio mínimo de impacto. ¿Qué prefijos se solapan? ¿Qué sistemas deben comunicarse ahora?
2. Elige una vía de remediación:
   • Mejor: renumerar un sitio (o al menos las subredes que necesitan conectividad intersite).
   • Temporal: NATear un lado a un rango de traducción que no se solape.
   • Evitar: hacer bridging para “convertirlo en una LAN.” Eso es fusionar dominios de broadcast, no una solución.
3. Si renumeras: crea nuevos ámbitos DHCP, actualiza gateways, DNS y reservas; migra VLAN por VLAN; conserva un plan de rollback.
4. Si usas NAT: registra las traducciones, documenta el mapeo y fija una fecha de expiración. Revisa aplicaciones que dependan de la IP origen.
5. Después de la remediación: elimina NAT/reglas temporales, endurece el firewall y actualiza IPAM/fuente de la verdad.

Checklist operacional: prevenir el caos DHCP

• Habilita DHCP snooping en switches de acceso cuando esté disponible, y confía solo en uplinks hacia tus servidores/relays DHCP reales.
• Mantén servidores DHCP como autoritativos para sus ámbitos; evita definiciones duplicadas de ámbitos en múltiples lugares a menos que uses failover real.
• Estandariza conjuntos de opciones DHCP y versionéalos.
• Usa reservas para dispositivos “semi-estáticos” (impresoras, teléfonos, lectores de tarjetas).
• Audita en busca de DHCP rogue trimestralmente (o después de mudanzas de oficina).
• Monitorea el agotamiento del pool y alerta antes de que se acabe.

Preguntas frecuentes (FAQ)

1) ¿Puedo ejecutar un solo servidor DHCP para ambas oficinas sobre un VPN?

Sí, mediante relay DHCP. Pero estás moviendo una dependencia crítica del plano de control a tu WAN. Si la WAN no es extremadamente estable,
mantiene DHCP local o despliega failover local.

2) ¿Por qué DHCP no puede simplemente “atravesar el VPN” de forma natural?

DHCP usa broadcast para descubrimiento en una LAN. Los VPNs enrutados no transportan broadcasts. Necesitas un relay, o hacer bridging L2,
y el bridging suele ser el intercambio erróneo.

3) ¿Cuál es la solución más limpia para subredes solapadas?

Renumera un lado a un prefijo único. Es trabajo, pero compra corrección. NAT es aceptable como táctica de migración con tiempo limitado,
no como tu personalidad permanente.

4) Si debemos usar NAT, ¿qué debemos vigilar?

Los logs y el control de acceso pierden granularidad, algunas apps incrustan IPs y el troubleshooting se vuelve más difícil porque las trazas muestran
identidades traducidas. Documenta el mapeo y planifica eliminarlo.

5) ¿Por qué pings pequeños funcionan pero las transferencias fallan a través del VPN?

Clásico problema de MTU/PMTUD. La encapsulación reduce la MTU efectiva. Sin clamp MSS o ajustes correctos de MTU, los paquetes grandes se descartan
y TCP se queda atascado de maneras que parecen “lentitud aleatoria.”

6) ¿Cómo detecto rápidamente un servidor DHCP rogue?

Ejecuta una captura de paquetes para ofertas DHCP en la VLAN afectada y busca múltiples Server-ID. Luego localiza la MAC en la tabla MAC del switch
y cierra/aisla ese puerto.

7) ¿Deben ambas oficinas compartir los mismos servidores DNS?

Pueden, pero asegúrate de alcanzabilidad y baja latencia. Un buen patrón es resolvers caché locales en cada oficina que reenvíen a servidores
autorizados centrales. Eso reduce la dependencia del VPN para cada consulta DNS.

8) ¿Rutas estáticas o enrutamiento dinámico para una empresa pequeña?

Dos sitios, un par de subredes: rutas estáticas están bien. Más sitios, cambios frecuentes o muchas VLAN: usa OSPF o BGP para que dejes de
olvidar rutas durante trabajos urgentes.

9) ¿Qué tiempo de lease debería usar para clientes de oficina remota?

Si DHCP es local, tiempos estándar (8–24 horas para redes de usuarios) están bien. Si DHCP está centralizado a través del VPN, usa leases más largos
para que breves problemas de WAN no desencadenen renovaciones masivas y churn.

10) ¿Es aceptable hacer bridging a través de un VPN sitio a sitio?

Rara vez, y generalmente temporalmente: necesidades heredadas de nicho, migraciones cortas o entornos muy pequeños donde aceptas los riesgos conscientemente.
Si haces bridging, documenta el plan de salida desde el día uno.

Conclusión: próximos pasos que realmente reducen el riesgo

Los proyectos VPN entre oficinas fallan de maneras predecibles. No porque los túneles sean misteriosos, sino porque direccionamiento, DHCP,
DNS y enrutamiento son problemas de gobierno que se hacen pasar por problemas de conectividad.

Haz esto a continuación, en orden:

1. Escribe cada subred en cada sitio y elimina solapamientos. Si no puedes eliminarlo de inmediato, usa NAT con un plan de retirada explícito.
2. Elige tu modelo DHCP deliberadamente: local por sitio por defecto; relay a central solo cuando la WAN y la madurez operativa lo justifiquen.
3. Bloquea enrutamiento y política de firewall exactamente a lo que necesitas, luego monitoriza drops y salud del túnel.
4. Valida MTU/MSS temprano para que no pases una semana culpando “al VPN” por un problema de aritmética de tamaño de paquetes.
5. Hazlo aburrido: una pequeña fuente de la verdad IPAM, listas de verificación repetibles y competencia en capturas de paquetes vencen a los héroes cada vez.

Si haces esto bien, el VPN se vuelve lo que siempre debió ser: un transporte sin novedades. Tus usuarios no lo notarán.
Eso es el éxito.