Tu grupo de direcciones VPN no es el rango DHCP de la LAN: por qué falla

El atajo tentador es entregar a los clientes VPN direcciones del mismo rango que usa el servidor DHCP de la oficina, con la teoría de que todo es una sola red. No lo es. Un túnel enrutado transporta paquetes unicast entre dos extremos, mientras que el grupo de la LAN existe para responder solicitudes de difusión en un segmento físico. Reutilizar los números pone a dos asignadores al cargo de un mismo espacio de direcciones y deja la ruta de retorno sin definir.

Dos asignadores, un espacio de direcciones

El servidor DHCP de la LAN sabe qué direcciones ha arrendado y a qué dirección MAC, y las defiende con ARP. El servidor VPN tiene su propio grupo y no sabe nada de esos arriendos. Ninguno se equivoca; sencillamente nunca se los presentaron.

Una dirección del grupo de la LAN que entregue el servidor VPN puede pertenecer ya a una impresora. Ahora dos dispositivos reclaman una dirección en el mismo prefijo, y la tabla de reenvío del conmutador decide cuál responde.

Ese es el fallo con el que la gente se topa primero: un cliente que se conecta con éxito y luego llega a la máquina equivocada, o llega a la correcta de forma intermitente.

Por qué el enrutador no reparte direcciones VPN

El descubrimiento DHCP es una difusión, y las difusiones se detienen en un límite enrutado. Salvo que el diseño puentee el túnel o ejecute un relé DHCP con la autoridad correspondiente, la solicitud del cliente nunca llega al servidor de la LAN.

Por eso el servidor VPN asigna la dirección él mismo: un grupo en la configuración del servidor, una dirección por par en una instalación de WireGuard, o una dirección empujada por la capa de autenticación en un despliegue de IKEv2. Esos mecanismos son independientes de la base de datos de arriendos de la LAN, y es exactamente por eso que necesitan un rango propio.

El mismo razonamiento explica por qué cambiar el ámbito DHCP no arregla a un cliente VPN que nunca obtiene dirección. El cliente no pregunta al servidor de la LAN, y ninguna edición del ámbito hará que pregunte.

El solapamiento se manifiesta como conflicto, no como red lenta

Dos redes que comparten un prefijo sin un diseño admitido son un problema distinto de la propiedad duplicada, y a menudo se confunden. Si el grupo VPN es un prefijo separado, el solapamiento solo importa cuando una ruta envía el tráfico al lado equivocado. Si el grupo está dentro del prefijo de la LAN, el conflicto es inmediato y local.

En la práctica ves respuestas ARP del dispositivo equivocado, conexiones que se reinician a mitad de camino y un cliente cuya propia dirección reclama otro. Nada de eso parece un problema de enrutamiento, por eso la corrección se aplica en la capa equivocada. Un arriendo duplicado es fácil de confirmar y molesto de soportar. También sobrevive a los reinicios, porque ambos asignadores siguen insistiendo en la misma dirección.

La ruta de retorno es un problema aparte

Incluso con un grupo limpio y distinto, los equipos de la LAN necesitan saber cómo responder a un cliente. Su puerta de enlace predeterminada es el enrutador, y el enrutador necesita una ruta para el grupo que apunte al servidor VPN, salvo que el diseño traduzca el tráfico del cliente.

Lee la ruta en ambos sentidos antes de cambiar nada. En la puerta de enlace, pregunta qué interfaz usaría el núcleo para una dirección de cliente; en el cliente, pregunta qué ruta usa para una dirección de la LAN.

Estos comandos muestran la decisión de reenvío en la puerta de enlace y las entradas de vecinos que revelan un duplicado:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Si el primer comando responde con la interfaz del túnel, la ruta de retorno existe. Si responde con la interfaz de la LAN, el enrutador cree que el cliente está en el cable e intentará hacer ARP por él.

Hay diseños puenteados, pero hay que elegirlos

Puentear un túnel hacia la LAN es un diseño real, usado cuando los clientes deben recibir difusiones o ser descubiertos por protocolos que suponen un solo segmento. Exige que el servidor sea dueño de ese comportamiento de puente y del manejo de direcciones que lo acompaña.

Lo que no funciona es imitar el resultado copiando números. Un grupo compartido sin puente te da el conflicto sin el descubrimiento, que es lo peor de ambas disposiciones.

Elige capa tres con un grupo distinto salvo que la aplicación necesite de verdad el segmento, y documenta el grupo para que el siguiente administrador no reutilice el rango DHCP por pura pulcritud.