Por qué un host de la LAN envía ARP para la dirección de un cliente OpenVPN

Los problemas de alcance entre un host de la LAN y un cliente VPN suelen remontarse al propio plan de direccionamiento. Dale a ese host una interfaz en 10.0.100.0/22 y tratará cada dirección desde 10.0.100.0 hasta 10.0.103.255 como directamente conectada, incluido un grupo de clientes colocado discretamente en 10.0.101.0/24. La respuesta nunca va a un router, porque desde el punto de vista del host no interviene ningún router. El paquete se dirige a un vecino y se reclama en el cable.

Ese mecanismo está detrás de toda una familia de informes: el túnel está activo, el servidor tiene una ruta y el host de la LAN sigue sin alcanzar al cliente.

El /22 que se traga el /24

Lee el prefijo como un rango, no como una cadena. Un /22 contiene 1024 direcciones, y 10.0.100.0/22 abarca de 10.0.100.0 a 10.0.103.255, así que un grupo en 10.0.101.0/24 queda enteramente dentro. El error sobrevive a la revisión porque los primeros octetos del grupo parecen distintos de los primeros octetos de la LAN, y solo el tercer octeto revela la contención. Escribe ambos rangos en cifras antes de declararlos separados.

La misma contención puede aparecer a la inversa. Un grupo que parece libre porque nada lo usa ahora puede caer igualmente dentro de un prefijo que anuncia algún router de sede, y el plan de direccionamiento es el único documento que lo muestra.

Enlace directo significa ARP, no enrutamiento

Cuando un host con una interfaz /22 envía a 10.0.101.25, el núcleo compara el destino con el prefijo de la interfaz y encuentra una coincidencia. El paquete pasa a ser una resolución de vecino en lugar de un paquete enrutado, y en Ethernet la resolución de vecino es una solicitud ARP para esa dirección. Si la dirección pertenece a un cliente VPN detrás de una puerta de enlace enrutada, ningún host de la LAN la posee, así que la solicitud queda sin respuesta y los paquetes se descartan. El túnel no tiene culpa, y el cliente nunca ve el tráfico.

Por eso el fallo parece asimétrico y a veces intermitente. El host VPN suele alcanzar la LAN porque sus propias rutas apuntan en la dirección correcta, mientras el host de la LAN no puede responder, y cualquier caché de una entrada ARP obsoleta hace parpadear el síntoma.

TUN, TAP y lo que transporta cada uno

Un dispositivo TUN transporta paquetes IP, y un dispositivo TAP transporta tramas Ethernet. Un enlace TUN enrutado no necesita transportar ARP para ofrecer alcance IP, y por eso mismo la solicitud sin respuesta de arriba es esperable y no un defecto. TAP con un puente deliberado puede ampliar el dominio de difusión y hacer funcionar ARP, pero cambia lo que el cliente puede ver, exige extremos que soporten el mismo entramado y es un rediseño del modelo de red en lugar de una reparación para un prefijo solapado. Pasar un despliegue enrutado a TAP para curar un error de plan de direccionamiento cambia un problema pequeño por uno mayor.

Anota dónde apareció la solicitud ARP y qué sistema la emitió antes de sacar conclusiones. El emisor te dice lo que cree sobre el destino, no lo que hace el túnel.

Diseña un grupo que no pueda solaparse

Elige un grupo fuera de cada prefijo conectado y de cada prefijo de sede anunciado, y luego añade las rutas que lo hacen alcanzable en ambos sentidos. Un rango como 10.8.0.0/24 en una parte sin usar del plan es fácil de razonar, y una LAN que necesita alcanzarlo recibe una ruta estática que apunta al servidor VPN. Cambia juntos la asignación, las rutas anunciadas, las direcciones de origen permitidas y las reglas del cortafuegos, porque describen un solo diseño y no cuatro ajustes.

El NAT de origen en el servidor puede ocultar el grupo tras una dirección enrutable desde la LAN, y es una herramienta de migración legítima. También reescribe el origen, así que la LAN pierde la capacidad de atribuir conexiones a clientes individuales y de aplicar reglas por cliente.

Para la aceptación, usa la dirección realmente asignada al cliente real y una solicitud de aplicación real desde un host de la LAN, y luego confirma que la respuesta sigue la puerta de enlace prevista y no el cable.