Un cliente VPN con dirección LAN no está en la LAN

El cliente se conecta, recibe 10.50.0.200 y no puede llegar al servidor en 10.50.0.20 aunque ambos números están en la misma /24. La creencia detrás de esa configuración es que una dirección del prefijo de la LAN convierte al cliente en parte de la LAN. No lo hace. El cliente está en un enlace punto a punto, el servidor cree que el destino es local, y la pieza que falta es una respuesta de vecino que nadie envía.

El mito: el mismo prefijo significa el mismo segmento

Un prefijo de dirección dice a un equipo qué destinos puede alcanzar directamente y cuáles necesitan un enrutador. No le dice cómo está conectado físicamente el destino, y desde luego no garantiza que el destino pueda responder a una petición de capa de enlace. Son preguntas distintas, que responden tablas distintas del equipo. La máscara responde a la primera y la tabla de vecinos a la segunda, y solo la primera está bajo tu control desde el lado de la VPN.

Cuando el servidor envía a 10.50.0.200, compara el destino con su propia máscara, decide que la dirección está on-link y pide al segmento local la dirección de hardware que la posee. Esa petición sale por la interfaz Ethernet, y el cliente VPN no está allí para oírla.

Nada en la configuración del cliente puede arreglarlo desde su lado. La ruta de respuesta depende de que un dispositivo en la LAN responda en nombre del cliente, o de que el cliente tenga una dirección que el servidor no considere local.

Qué hace realmente el equipo local con la dirección

El comportamiento es fácil de observar y merece observarse antes de cambiar nada. Mira la tabla de vecinos en un equipo de la LAN después de que intente llegar al cliente: una entrada incompleta o fallida es todo el diagnóstico en una línea. Esa línea también te dice que el fallo es local al segmento y no en algún punto dentro del túnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

La consulta de ruta informará del destino como on-link por la interfaz Ethernet, y ese es exactamente el problema. Si la entrada de vecino sigue incompleta mientras la sesión VPN está activa, has confirmado que la pieza que falta es la resolución en la capa de enlace y no el enrutamiento o la política del cortafuegos.

Haz la misma comprobación desde un equipo en otra subred y compara. Un equipo que llega al cliente a través de un enrutador no necesita ninguna entrada de vecino, y esa diferencia es la decisión de diseño en miniatura.

Cómo el proxy ARP proporciona un siguiente salto

El proxy ARP hace que la puerta de enlace responda a la petición de capa de enlace en nombre de un destino al que puede llegar por otra interfaz. El equipo de la LAN recibe una dirección de hardware, envía la trama a la puerta de enlace, y la puerta de enlace reenvía el paquete a la sesión VPN. Desde el punto de vista del equipo, el cliente simplemente parece estar detrás de la puerta de enlace. Nada de la configuración del cliente cambia.

La documentación de ARP de RouterOS de MikroTik describe ese uso para clientes de acceso telefónico que toman prestado el espacio de direcciones de la LAN conectada. El mecanismo es una reparación de la resolución de vecinos, y funciona porque la puerta de enlace está realmente en ambos caminos.

Eso no es lo mismo que puentear el cliente dentro de la LAN. La puerta de enlace todavía tiene que reenviar el paquete a la sesión activa correcta, y su enrutamiento y su política de cortafuegos todavía tienen que permitir el servicio. El proxy ARP cambia quién responde a la petición de vecino, no quién tiene permiso para hablar.

Lee con cuidado los nombres de modo de la plataforma. RouterOS separa proxy-arp de local-proxy-arp, y el segundo gestiona el tráfico que entra y sale por la misma interfaz. No son grafías intercambiables, y activar ambos sin criterio no es un atajo.

Lo que el proxy ARP no te da

No proporciona descubrimiento por broadcast ni multicast. Un cliente que necesita encontrar un servicio por broadcast seguirá fallando, porque la puerta de enlace reenvía unicast a la sesión y no convierte al cliente en miembro del dominio de broadcast de la LAN. Los protocolos de descubrimiento que dependen del broadcast son una fuente habitual de informes de que funciona para una cosa y no para otra en diseños con direcciones prestadas.

No reserva la dirección. Si el número prestado también está en un grupo DHCP o en una asignación estática, dos dispositivos pueden acabar con la misma dirección y el comportamiento resultante depende del momento. Un inicio de sesión correcto no es una reserva.

Y no elimina la necesidad de coordinarse con quien es dueño de la LAN. Una entrada de proxy ARP que sorprende al dueño del plan de direcciones es un incidente de soporte esperando una semana tranquila.

Comparación con un grupo enrutado por separado

La alternativa es dar a los clientes VPN su propio prefijo y dejar que los equipos de la LAN enruten hacia él. Entonces el servidor envía respuestas fuera de enlace a su puerta de enlace, la puerta de enlace enruta el prefijo hacia el extremo de la VPN, y no se necesita ninguna resolución de vecinos en el segmento de la LAN. Eso son menos piezas móviles que una dirección prestada más una respuesta proxy.

Ese diseño es más fácil de razonar y de auditar, porque el rango de clientes está visiblemente separado del rango de la LAN. Cuesta una ruta, un camino de vuelta y una regla de acceso, que son las mismas cosas que el diseño con proxy ARP necesita en un lugar menos obvio.

Elige entre los modelos a propósito y no por accidente. El proxy ARP repara una relación concreta; un grupo enrutado evita necesitar esa reparación. Anota cuál elegiste y por qué, y la siguiente persona no tendrá que redescubrirlo a partir de una entrada de vecino fallida.