Un par VPN hace ping a otras interfaces porque son locales

Un cliente de WireGuard se conecta y hace ping a una dirección en una interfaz completamente distinta, y la respuesta llega. Las capturas muestran la petición solo en el túnel. Nada está roto, y el ajuste de reenvío que se desactivó con cuidado no tiene nada que ver. Esta es una comparación entre dos rutas que parecen iguales en un diagrama y son completamente distintas en el kernel.

Una ruta reenvía paquetes para otro; la otra los entrega al propio host.

Un paquete dirigido al host se queda en el host

El cliente remoto envía un paquete IP a una dirección que posee el host. El enrutamiento hace una pregunta sobre ese paquete: ¿este destino es local? Cada dirección que tiene el host aparece en la tabla de enrutamiento local, y esa tabla se consulta antes que la principal, así que el paquete va a la pila propia del host en lugar de salir por otra interfaz. La respuesta se genera localmente, y vuelve por el túnel porque de allí vino la consulta.

Ese es todo el mecanismo. No se produce ningún reenvío, no interviene ningún cambio de estado de la interfaz, y la dirección en cuestión no necesita ser alcanzable desde ningún otro sitio.

Por qué ip_forward no se aplica

El reenvío gobierna los paquetes que deben salir por una interfaz distinta de aquella por la que llegaron. Un ping al propio host nunca toma esa ruta: el paquete se consume localmente y la respuesta se genera localmente. Por eso, establecer net.ipv4.ip_forward=0 no cambia nada aquí, y una regla en la cadena de reenvío nunca ve ese tráfico. El control correcto está en la ruta de entrada, limitado por la interfaz entrante o la fuente.

Por eso, desactivar el reenvío y suponer que el host está aislado produce una falsa sensación de seguridad.

Lea la tabla local que decidió

ip rule show normalmente informa de una regla con prioridad cero que envía todas las consultas primero a la tabla local, y ip route show table local enumera las direcciones propias del host con ámbito local. Esa tabla incluye direcciones en interfaces administrativamente caídas pero aún configuradas. Las direcciones IPv4 asignadas estáticamente suelen sobrevivir a una caída del enlace, y así es como un ping a un puente caído puede seguir teniendo éxito y sorprender al operador.

IPv6 discrepa exactamente en este punto. Sus direcciones normalmente se retiran cuando cae el enlace, salvo que keep_addr_on_down esté establecido. Compare las familias en lugar de suponer que una regla cubre ambas.

A qué llega realmente un par

Una respuesta desde la dirección propia del router en un segmento no dice nada sobre las máquinas detrás de ese segmento. El par no puede llegar a un host detrás de la otra interfaz por esta ruta; solo llega a las direcciones que el propio router posee. Probar un servicio en un host de LAN separado, en lugar de hacer ping a la dirección del router, es lo que establece si el reenvío está permitido siquiera.

Restringir un par a los servicios ligados a la dirección del túnel es una cuestión de política de entrada. Permita el servicio deseado en la interfaz del túnel y restrinja las fuentes que pueden usarlo, porque el paquete llega de verdad allí.

Revise también las direcciones que pensaba retirar. Quitar una dirección de una interfaz es más fiable que apilar reglas de cortafuegos sobre una obsoleta.