Direcciones de túnel estáticas en pfSense: ¿preferencia o reserva?

Dos diseños se parecen sobre el papel y se comportan de forma muy distinta cuando una regla depende de ellos. Uno escribe una dirección en una anulación de cliente y confía en esa dirección como identidad. El otro cierra por completo la admisión dinámica, de modo que un extremo o tiene una asignación única o no se conecta. Solo el segundo convierte una dirección en un dato de política que se puede defender, y la diferencia merece entenderse antes de escribir una sola regla de cortafuegos.

Qué promete realmente una dirección de anulación

Una anulación específica de cliente lleva opciones por cliente, incluida una dirección de túnel preferida. Netgate describe esa dirección como una preferencia y no como una reserva, lo que significa que el grupo dinámico no cede la dirección a nadie más.

Eso suele estar bien. Una colisión es rara, y el cliente normalmente recibe lo que pidió, lo cual basta para la comodidad y no para la autorización. Comodidad y autorización son requisitos distintos, y solo uno de ellos sobrevive a una colisión.

Con topología de subred, el campo toma la dirección del cliente junto con la máscara de la red del servidor, así que una dirección dentro de un túnel 10.90.0.0/24 se escribe como 10.90.0.10/24.

Nada de eso reserva el número. Un cliente cuya anulación no coincide, o una sesión duplicada, puede acabar en otra parte del grupo, y una regla basada en la dirección describe entonces a alguien que no está allí.

Cerrar la vía dinámica con un valor por defecto acotado

La alternativa es un servidor solo estático: cada extremo admitido tiene su propia identidad y su propia dirección única, y nada más entra.

Implementarlo implica una anulación DEFAULT acotada a ese único servidor con el bloqueo de conexiones activado. Un cliente sin una anulación coincidente no puede entonces recurrir a la admisión dinámica ordinaria. Esa sola línea es lo que convierte una preferencia en un conjunto cerrado.

El alcance importa. Una anulación por defecto aplicada a cada instancia de VPN de la máquina bloqueará túneles no relacionados, y ese fallo parece un servicio roto en lugar de una decisión de política. Vínculela al único servidor cuyo modelo de admisión está cambiando. Luego anote el alcance en el registro de cambios, porque la siguiente persona no recordará a qué túnel pertenece.

Audite después todo el conjunto permitido. El bloqueo por defecto no corrige una anulación con nombre que quedó sin dirección, y ese extremo simplemente no podrá conectarse sin una pista obvia de por qué.

Coincidir con la identidad que el servidor usa de verdad

Una anulación coincide con algo. En un servidor que compara nombres comunes de certificado, el nombre de la anulación debe ser ese nombre común, no el nombre visible de la persona. Cópielo del certificado en lugar de la lista de cuentas.

Un servidor configurado para usar el nombre de usuario como nombre común compara con una clave completamente distinta, y una anulación nombrada por el certificado nunca se activará. Lea el ajuste en vez de deducirlo de lo que muestra la lista de cuentas.

Mantenga los factores de autenticación adicionales que exige el despliegue. Un modelo de direcciones cerrado cambia quién puede conectarse y qué dirección recibe; no sustituye la comprobación del certificado ni el segundo factor.

Escribir las reglas de acceso cuando el mapa sea sólido

Una vez cerrado el mapa de identidad a dirección, las reglas pueden referirse a direcciones sin fingir que son personas. Un alias que agrupa los extremos de una persona puede alcanzar un servicio concreto mientras otro alias alcanza otra cosa. El alias se convierte en el objeto revisable, y la dirección pasa a ser un detalle de implementación dentro de él.

Mantenga explícitos los destinos y los puertos. Permitir toda la red local desde todo el grupo de túneles es justo el diseño que este ejercicio debía sustituir.

Lea las reglas flotantes, de grupo y de interfaz en su orden real de evaluación, porque un paso amplio anterior anula uno estrecho posterior. Desactivar el reenvío interno de cliente a cliente mantiene el tráfico entre pares en el límite donde se revisan esas reglas. Una regla que solo existe en el papel no es aplicación.

Probar los casos negativos

Ejercite cuatro conexiones nuevas: un extremo con nombre, uno sin ninguna anulación, un servicio que debería ser alcanzable y otro que no debería. El extremo no listado es el caso importante, porque es el que el diseño existe para detener. Si se conecta, el bloqueo por defecto no está haciendo su trabajo.

Compruebe IPv6 por separado, ya que una política de direcciones IPv4 no dice nada sobre una segunda pila. Luego confirme que la aplicación sigue autorizando al usuario, porque una dirección de túnel es un hecho de red y no una prueba de quién está en el teclado. Ambas comprobaciones pertenecen a la nota de aceptación.

Por último, planifique la migración. Las nuevas anulaciones y reglas estrechas no cambian de forma retroactiva las sesiones ya establecidas, así que los estados existentes tienen que caducar o borrarse deliberadamente.