Por qué un cliente VPN en la LAN de la oficina pierde todas las respuestas

Un portátil está en la /24 de la oficina por Ethernet y también se une a un servidor OpenVPN que vive en esa misma /24. Un compañero hace ping a la dirección del túnel; la petición llega con claridad y no vuelve nada. El registro del túnel está limpio y la navegación sigue funcionando, así que el túnel es el sospechoso equivocado. La validación de origen IPv4 en la máquina receptora tira el paquete antes de que nada lo lea.

El descarte ocurre antes de que nada lea el paquete

La validación de origen hace una pregunta sobre cada paquete entrante: si este equipo respondiera a ese origen, ¿la respuesta saldría por la interfaz por la que acaba de llegar el paquete? Cuando la respuesta es no, el núcleo tira el paquete al llegar. Ni un socket ni una ruta de reenvío lo ven jamás, y por eso una captura en el túnel sigue registrando una petición que la aplicación nunca recibe.

El cliente de aquí tiene 10.66.0.9 en su túnel, y el servidor OpenVPN responde en 192.168.80.10 dentro del prefijo de la oficina. Un compañero en 192.168.80.25 hace ping a la dirección del túnel, así que la petición cruza la LAN, el servidor la encamina al túnel y llega a la interfaz del túnel del cliente con una dirección de origen de la oficina. En la tabla de rutas de esa máquina el prefijo de la oficina pertenece al dispositivo Ethernet, no al túnel. La validación compara la interfaz de llegada con la ruta, encuentra una discrepancia y descarta el paquete, así que el compañero ve una pérdida total mientras ambos extremos informan de un túnel sano.

La dirección espejo tiene la misma forma: cuando el cliente inicia hacia la oficina, las respuestas pueden descartarse en el lado de la oficina por el mismo motivo. Una corrección verificada solo en una dirección suele volver como un segundo tique.

Demuestre el modo vigente antes de tocar un sysctl

Lea los valores efectivos en lugar de fiarse de un valor por defecto de la distribución, porque el ajuste por interfaz es solo la mitad de la decisión. El modo vigente es el mayor entre el valor de la interfaz y el valor de all, así que un cero en la interfaz del túnel no significa nada mientras all sea uno. La decisión del modo estricto es una decisión de encaminamiento, así que ejecute la consulta que ejecuta el núcleo y compare su respuesta con la interfaz por la que el paquete llegó de verdad.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Después repita el ping mientras vigila el contador de errores. Un contador que sube junto a una petición que la captura ya muestra es la firma de este descarte, no la de una ruta ausente. Active el registro de paquetes marcianos mientras está allí, para que el núcleo nombre el origen y la interfaz que rechazó. Juntos descartan el cifrado, el cortafuegos y un iroute ausente como explicaciones.

Anote la línea base antes de cambiar nada: ambos valores, el dispositivo que eligió la consulta y el contador que vigiló. Ese registro es lo que le dirá después si el cambio hizo lo que usted cree.

Qué acepta realmente cada modo de rp_filter

El núcleo expone tres valores por interfaz, y no son tres matices de una misma regla. Cero desactiva la comprobación. Uno es estricto y exige que el origen se encamine de vuelta por la interfaz de llegada. Dos es laxo y solo exige que exista alguna ruta hacia el origen en la tabla, apunte donde apunte.

La fila que importa aquí es la laxa, y lo que sigue rechazando. Un origen falsificado que sea encaminable en cualquier parte de su tabla pasa, mientras que un origen sin ninguna ruta todavía se rechaza. En un portátil es una concesión estrecha; en un router que reenvía tráfico de otras personas es amplia. El modo pertenece al equipo, así que el mismo número tiene distinto peso en los dos sitios.

Qué fila necesita esta topología se deduce de la tabla y no de la costumbre. El paquete es legítimo y su origen es encaminable, así que el laxo lo acepta y el estricto no. Nada del caso pide cero, y elegir cero quitaría una comprobación que aquí no cuesta nada.

Elija el cambio más pequeño que elimina la ambigüedad

El modo laxo es el cambio más pequeño que encaja, y es una reducción real del rigor, no un interruptor inocuo. Existe una opción mejor siempre que la topología lo permita: elimine la superposición y la ambigüedad desaparece.

Donde el prefijo de la oficina solo se necesita por Ethernet, quítelo de las rutas que arrastra el perfil y la dirección pasa a ser alcanzable por un solo camino. Cuando ambos caminos tienen que coexistir de verdad, fije el origen y el dispositivo con una regla de política en lugar de aflojar la validación en cada interfaz. Eso mantiene el filtrado estricto para todo lo demás en la máquina y documenta la excepción donde el siguiente ingeniero la buscará.

Sea cual sea el camino que elija, anótelo en un drop-in de sysctl y no en un comando en vivo. Defina las claves all y default juntas, para que una reconexión no pueda restaurar el modo estricto en silencio.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Qué cede el modo laxo, y dónde

El modo laxo sigue rechazando un origen que ninguna ruta podría alcanzar, y deja de rechazar un origen falsificado que resulta ser encaminable. En un portátil es una concesión estrecha. En un dispositivo que reenvía tráfico que no posee, la misma elección es mucho más amplia. Por eso el mismo ajuste tiene dos significados muy distintos según dónde se ejecute.

Apagar la comprobación del todo, en un equipo que reenvía tráfico para otras personas, es la única reparación que conviene evitar. Cero tira la validación que el modo laxo cuida de mantener. Si el equipo reenvía para otros, defienda en cambio la opción de la regla de política de la sección anterior.

Deje una nota que nombre las dos interfaces, el prefijo solapado y la prueba exacta que ahora tiene éxito. Eso es más útil para el siguiente ingeniero que una línea que diga que se ajustó el filtrado.