¿Desaparecen las respuestas de la VPN en Linux? Compruebe rp_filter y la ruta

Las peticiones salen de la máquina, el par de la VPN responde y la respuesta nunca llega al socket. El túnel está levantado, los registros del par muestran que el paquete se envía y nada en la aplicación explica el silencio. En Linux uno de los sospechosos habituales es el filtrado de ruta inversa: un paquete IPv4 entrante puede rechazarse cuando la validación de origen no coincide con la ruta que el núcleo espera para ese origen. Recorrerlo en orden le dice si eso es la causa o una coincidencia. También le evita desactivar un control de seguridad para arreglar una ruta que falta.

Qué decide la validación de origen

El núcleo comprueba si la dirección de origen de un paquete es verosímil para la interfaz por la que llegó, consultando la tabla de enrutamiento para una ruta de vuelta a ese origen. Si la ruta inversa apunta a otro sitio, el paquete puede descartarse antes de que lo vea cualquier regla de cortafuegos o socket de la aplicación. Esa comprobación existe para dificultar ciertos patrones de suplantación, y también es el motivo por el que los diseños asimétricos y enrutados por política tropiezan con ella mientras que cualquier cliente corriente de la misma red funciona bien. Los clientes corrientes tienen enrutamiento simétrico, que es exactamente lo que supone la comprobación.

La palabra importante es verosímil. El paquete puede ser perfectamente legítimo y aun así fallar la comprobación, porque no se está probando la legitimidad.

Lea el modo efectivo, no un solo campo

Existen tres modos: desactivado, estricto y laxo. El estricto impone una expectativa de ruta distinta de la del laxo, y el ajuste global interactúa con los de cada interfaz, así que leer un solo archivo puede describir mal lo que está realmente en vigor. Lea ambos, y léalos en la interfaz que recibe la respuesta, no en la de la ruta predeterminada.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

La consulta de ruta de esa tercera línea es la parte que la gente se salta. Le dice qué cree el núcleo sobre el origen, que es exactamente la entrada de la comprobación.

Encuentre la discrepancia antes de cambiar la comprobación

Averigüe por qué la respuesta llega por esa interfaz y si su ruta inversa debería ser distinta. Una regla de política que envía las peticiones por un camino mientras las respuestas vuelven por otro es un diseño legítimo, y también es el diseño que rechaza la validación estricta. Las marcas usadas en el enrutamiento por política también pueden importar aquí, porque cambian lo que devuelve la consulta inversa.

Si la ruta inversa simplemente falta, añadirla arregla la causa en lugar de desactivar una comprobación. Una ruta que falta, un rechazo del cortafuegos y un selector de tráfico equivocado producen el mismo síntoma visible, y solo uno de ellos tiene que ver con la validación de origen.

No desactive las comprobaciones de origen globalmente como primera respuesta. Eso cambia un diagnóstico concreto por un cambio de comportamiento amplio que tendrá que recordar después.

Un ajuste selectivo que puede defender

Si un ajuste estrecho es realmente necesario, limítelo a la interfaz que lo necesita, anote por qué y póngalo en la configuración que posee esa interfaz para que sobreviva a un reinicio. Después vuelva a probar el flujo exacto que falló, del mismo origen al mismo destino, en lugar de un ping a algo cómodo.

Incluya un caso que todavía debería rechazarse. Si ese caso ahora tiene éxito, el ajuste debilitó más que el único camino que quería reparar.

Mantenga IPv4 e IPv6 separados

Un sysctl de aspecto familiar no es una política para cada familia de direcciones. IPv6 tiene su propio comportamiento y sus propios ajustes, y una máquina puede ser estricta en una familia y permisiva en la otra sin que nadie lo note hasta que falla un destino concreto. Compruebe ambos si la carga de trabajo usa ambos.

Registre el modo, la interfaz, la salida de la consulta de ruta y el motivo del cambio en un solo lugar. La siguiente persona encontrará el ajuste y ninguna explicación, y o lo quitará o lo copiará donde no corresponde.