Dos grupos de clientes, un servidor: dónde aplicar la política

Poner dos grupos de clientes en subredes distintas parece aislamiento, y no lo es. Las direcciones describen de dónde parece venir un paquete, mientras que el permiso es una decisión que toma quien lo reenvía. Esa pregunta la responde la configuración y no la máscara, así que decida qué componente reenvía el tráfico entre pares antes de escribir cualquier regla.

Una subred es una etiqueta, no una regla

Asignar un grupo de direcciones por grupo le da direcciones legibles y nada más. Un cliente que acepta una ruta adicional ha ganado alcanzabilidad, y la alcanzabilidad no es autorización. El permiso para hablar está en la decisión de reenvío, que puede vivir en el demonio o en el núcleo según cómo esté configurado el servidor.

La propiedad de la dirección es lo que hace que un prefijo sea utilizable como selector de grupo. Cada identidad autenticada debe corresponder a una dirección o un rango predecible, y esa correspondencia falla en cuanto varios dispositivos comparten una credencial y una asignación. Resuelva la identidad y la concurrencia antes de confiar en un prefijo de origen, porque una política que adivina qué máquina llama autoriza a la equivocada en el peor momento.

Elija la ruta que transporta el tráfico entre pares

Cuando el demonio reenvía paquetes entre pares dentro de su propio proceso, esos paquetes nunca llegan al enganche de reenvío del host, así que una regla del núcleo no puede verlos. Desactive ese reenvío interno y el núcleo se convierte en el punto de reenvío, donde se aplican las reglas de reenvío ordinarias.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

Los canales de datos descargados y los servidores gestionados por el producto publican sus propios modelos de aplicación, así que confirme cuál ejecuta en lugar de suponer el comportamiento de la comunidad. El fallo que merece evitarse es una regla que parece correcta en una revisión y nunca se consulta en tiempo de ejecución.

Escriba la matriz antes de escribir reglas

Una matriz breve es más fácil de revisar que un conjunto de reglas, y es el contrato que la implementación debe cumplir: pares del mismo grupo permitidos, pares entre grupos denegados, ambos grupos permitidos hacia un servicio compartido con nombre, todo lo demás denegado. Escriba esas cuatro líneas antes de abrir un editor de cortafuegos. Un revisor que no lee la sintaxis de las reglas aún puede comprobar la matriz. Luego la implementación solo tiene que coincidir con las líneas.

Mantenga separadas las tres clases de destino mientras la escribe. Un servicio en el host de VPN es entrada local, otro cliente es tránsito entre pares y una máquina detrás de la puerta de enlace es una ruta de reenvío distinta. Una regla generosa puede conceder las tres por accidente, y así es como una política de grupo se convierte en una red plana con pasos extra. Escriba la clase junto a cada fila para que la intención sobreviva a la próxima edición.

Ponga las reglas donde sobreviven

Añada las decisiones en el mismo lugar donde se mantiene el resto del cortafuegos, antes de cualquier regla permisiva que de otro modo se las tragaría. El orden de las reglas forma parte de la política, y una regla correcta colocada después de una aceptación amplia no aplica nada. Anote los números de regla antes y después del cambio. Una política que existe en un editor pero no en el conjunto de reglas en ejecución es un plan, no un control.

Decida qué ocurre con los flujos que ya existen cuando cambia la política, porque una sesión abierta antes del cambio puede seguir ejecutándose después. Si un miembro que se va debe perder el acceso de inmediato, el conjunto de reglas necesita una forma de terminar ese estado en lugar de esperar a que la conexión se cierre sola.

Haga persistentes las reglas mediante el mecanismo que posee el resto del cortafuegos, y registre la matriz junto a ellas. Una política no registrada se vuelve a derivar de la memoria durante el siguiente incidente, normalmente por alguien con prisas.

Demuéstrelo desde ambos lados

Pruebe la alcanzabilidad dentro del mismo grupo, el fallo entre grupos y el servicio compartido desde un cliente de cada grupo. Una sola prueba desde un solo cliente demuestra la mitad de la matriz, y la mitad que deja fuera suele ser la equivocada. Repita la dirección de denegación dos veces, porque una sesión en caché puede ocultar un error de aplicación. Registre qué par probó para que la siguiente persona no lo repita.

Repita la comprobación en IPv6 si el túnel lo transporta, y mantenga la autenticación normal de las aplicaciones. Un prefijo de origen no es una cuenta, así que pasar la política de red no significa que un servicio deba confiar en quien llama.