Por qué una regla de bloqueo de cliente OpenVPN nunca llega a FORWARD

Dos clientes en el mismo servidor OpenVPN pueden alcanzarse aunque hayas añadido una regla DROP para su grupo de direcciones. La regla está en la cadena FORWARD, el tráfico fluye con claridad y el contador de esa regla sigue en cero. La conclusión natural es que el cortafuegos está roto. Lo más habitual es que el paquete ni siquiera haya entrado en la cadena.

Hay dos caminos que un paquete de un par puede seguir a través de un servidor OpenVPN, y los decide la configuración, no el cortafuegos. Saber qué camino está en uso te dice si una regla del host está siquiera en el lugar correcto.

Dos caminos que puede seguir un paquete de un par

Con la opción de reenvío interno desactivada, un paquete del cliente A llega a la interfaz del túnel con un destino dentro de la dirección asignada al cliente B. La tabla de rutas del servidor lo envía de vuelta por la misma interfaz del túnel, porque el servidor es dueño de la ruta hacia la dirección de B. Es un flujo de entrada y salida a través del host, y lo evalúa la ruta de reenvío IPv4.

Con la opción de reenvío interno activada, el proceso del servidor empareja el paquete con un cliente conectado y lo escribe de vuelta a ese mismo cliente. El paquete se maneja dentro del demonio y nunca vuelve a entrar en el dispositivo del túnel, así que la ruta de reenvío del host se salta por completo. El manual de OpenVPN 2.6 describe esta opción como reenvío interno de cliente a cliente, y es exactamente por eso por lo que una regla del cortafuegos del host no puede verlo.

Existe una tercera variante en despliegues que descargan el canal de datos a un módulo del núcleo. La decisión de reenvío y el cifrado salen del espacio de usuario, y que netfilter observe el flujo depende de cómo esté construido el camino de descarga. Nunca des por hecho que un conjunto de reglas antiguo se comporta en un servidor con descarga igual que en uno de espacio de usuario. Confirma el modo a partir de la configuración en ejecución, no de la versión del paquete.

Cuando el contador nunca se mueve

Un contador a cero significa que el paquete no coincidió con esa regla en ese punto, y hay varias razones. La primera es el desvío anterior: el tráfico nunca llegó a la cadena. La segunda es una discrepancia en la interfaz, la dirección, el origen o el destino, algo habitual cuando el grupo se ha renumerado y la regla todavía nombra el prefijo antiguo.

La tercera es la posición. Una regla anterior en la cadena puede aceptar el flujo antes de que se evalúe tu DROP, y una regla posterior puede ser la que realmente decide el resultado. Lee la cadena en orden con los contadores visibles y luego comprueba qué contador aumenta cuando repites la prueba.

Haz un intercambio controlado entre dos clientes cuyas direcciones reales hayas confirmado a partir del propio estado del servidor, no de un arrendamiento que recuerdes. Si el contador relevante sigue sin moverse, sospecha del camino antes de reescribir la coincidencia. Si se mueve pero la conexión sigue funcionando, el descarte se está anulando más adelante y el problema es el orden. Esa respuesta decide si la reparación es un cambio de regla o un cambio de topología, así que obténla antes de editar nada.

Elegir un límite que pueda filtrar

Si la política tiene que vivir en el cortafuegos del host, pon el tráfico donde el cortafuegos pueda verlo. Desactivar el reenvío interno es la forma admitida de hacer que el tráfico entre pares atraviese la interfaz del túnel y la ruta de reenvío, a costa de enviar cada paquete de par por la pila del host.

Después empareja el flujo con precisión. El tráfico llega a la interfaz del túnel y sale por la interfaz del túnel, en ambos sentidos, así que las reglas que solo consideran la interfaz física no coincidirán. Las reglas basadas en direcciones necesitan el grupo actual y deben tener en cuenta el sentido de retorno tanto como el de ida.

Muchos despliegues se sirven mejor filtrando a nivel de cliente o de grupo, donde la identidad es conocida y la política sigue al usuario en lugar de a una dirección que cambia al reconectar. Ese es un mecanismo distinto de una cadena del host, y los dos no deberían mezclarse sin una razón clara.

No traslades sin cambios el conjunto de reglas de una topología antigua a través de una migración. Los grupos de direcciones, los nombres de interfaz y los modos de reenvío influyen todos en si una regla coincide, y una regla copiada que antes funcionaba es el tipo de evidencia más engañoso. Empieza por el flujo que quieres permitir y escribe la regla que coincida con él.

Probar el aislamiento en vez de confiar en una regla

Prueba el caso prohibido y el caso permitido en la misma ejecución. Inicia una conexión nueva de un cliente al otro y confirma que falla, y luego confirma que una conexión que debería permitirse sigue funcionando. Si solo se prueba lo primero, un cortafuegos que bloquea todo parece un éxito.

Repite después de recargar la configuración del servidor y de que un cliente se reconecte, porque el reenvío interno y las asignaciones de grupo son estado en tiempo de ejecución. Comprueba los contadores en ambos sentidos, ya que una regla que coincide en un sentido y no en la respuesta produce un aislamiento parcial difícil de notar en una prueba rápida.

El aislamiento es el resultado observado en el límite que realmente transporta el flujo. Una regla DROP en algún lugar del host no es evidencia; una conexión fallida más un contador movido en la regla que la causó sí lo es.