duplicate-cn da a dos dispositivos una sola identidad, no dos

Copie el perfil en la tableta, conéctese y el portátil se cae. Añada duplicate-cn, ambos siguen conectados y el problema parece resuelto hasta que los dos dispositivos se pelean por la misma dirección de túnel o una tableta perdida deja toda la cuenta sin conexión. La opción cambia una cosa y solo una: si el servidor permite una segunda sesión bajo un nombre que ya ha visto. Todo lo que la gente espera que arregle, desde la independencia de dispositivos hasta el direccionamiento por dispositivo y la revocación selectiva, sigue haciéndose por identidad, y la identidad aquí es el certificado.

El mito: una segunda sesión es una segunda identidad

La intuición dice que dos conexiones deben ser dos clientes, y dos clientes deberían ser dos dispositivos con sus propios derechos. El servidor no lo modela así. Ve un nombre común y, con duplicate-cn activado, acepta más de una sesión viva que lleve ese nombre, y cada una recibe su propio estado de sesión en el demonio.

Nada de esa aceptación toca la verificación del certificado. El mismo certificado sigue siendo la credencial, la misma clave sigue siendo la clave privada, y cualquier política basada en el sujeto del certificado sigue resolviéndose al mismo valor dos veces. Una segunda sesión es un segundo socket, no una segunda identidad.

Esa distinción es invisible mientras todo funciona. Se vuelve muy visible en el momento en que hay que distinguir los dos dispositivos, que suele ser el día en que uno de ellos se pierde.

Qué cambia realmente cuando dos sesiones comparten un nombre

Sin la opción, una conexión nueva bajo un nombre común que ya está conectado desplaza la sesión anterior. Por eso el portátil se cae cuando se conecta la tableta, y es una salvaguarda deliberada contra la ambigüedad, no un fallo. Con la opción, ambas sesiones siguen vivas y el servidor las rastrea por separado por sesión, no por dispositivo.

Cada sesión sigue teniendo su propia conexión exterior y sus propias claves negociadas, así que el caudal simultáneo es realmente simultáneo. Lo que comparten es todo lo derivado de la credencial: consultas de política, configuración específica del cliente, identidad en los registros y revocación. El estado de sesión pertenece a la conexión y muere con ella, mientras que los hechos a nivel de credencial persisten en ambas. Por eso la salida de estado puede listar el mismo nombre dos veces mientras los contadores permanecen separados.

Compruebe qué hace realmente su compilación antes de diseñar sobre ella, porque el efecto de la opción lo define la propia opción y no la tradición oral:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

La dirección estática que creía haber asignado

La configuración por cliente se busca por nombre, y ahí está la trampa. Un archivo client-config-dir con el nombre común se aplica a todos los dispositivos que usan ese nombre, así que un ifconfig-push dentro de él entrega a ambos dispositivos la misma dirección de túnel. La segunda sesión o no se establece o colisiona de una forma que parece un fallo de enrutamiento.

Un pool dinámico se comporta mejor por casualidad, porque a cada sesión se le asigna una dirección del pool de forma independiente. Eso sigue sin darle una dirección estable por dispositivo, y desde luego no le da una política por dispositivo ligada a esa dirección.

Si el despliegue usa username-as-common-name, la clave de búsqueda pasa a ser el nombre de usuario autenticado en lugar del sujeto del certificado, y la misma colisión se repite para cualquiera que inicie sesión dos veces. El nombre que impulsa la configuración tiene que ser único por dispositivo para que la configuración por dispositivo signifique algo.

Lo que una identidad compartida no puede hacer al retirar

La revocación actúa sobre el certificado, no sobre el nombre visible ni sobre la sesión. Revoque ese certificado y todos los dispositivos que tengan una copia pierden el acceso a la vez, incluido el que está en la oficina y que nadie quiere molestar. Consérvelo y el dispositivo perdido sigue funcionando, porque nada en el protocolo lo distingue de la copia aprobada.

Los registros heredan la misma ambigüedad. La salida de estado muestra un nombre común y una dirección real, y ambos pueden pertenecer a cualquiera de los dos dispositivos. Una revisión de incidentes que necesite saber qué máquina hizo qué no puede responder a esa pregunta con los propios registros de la VPN, por mucho detalle que aporte el nivel de registro.

No hay solución criptográfica para esto. Dos dispositivos que presentan el mismo certificado son, para el servidor, el mismo participante dos veces, y cualquier esquema que pretenda lo contrario es una convención de nombres y no un control.

Cuándo compartir es correcto y cómo acotarlo

Compartir tiene usos legítimos: una cuenta de laboratorio usada por varias máquinas de prueba, o un hogar donde los dispositivos se gestionan juntos y la granularidad de revocación no importa. En esos casos, active la opción a propósito, mantenga la credencial compartida fuera de la política por dispositivo y deje margen en el pool para que las sesiones no colisionen en una dirección.

Para todo lo que necesite direcciones separadas, registros separados o retirada separada, emita certificados separados por la vía normal de alta. Eso da a cada sistema posterior un objeto distinto sobre el que basarse, y la opción deja de importar porque los nombres ya son únicos.

Elija la vía que elija, pruebe el modelo de gestión y no el inicio de sesión. Conecte ambos dispositivos, confirme que tienen direcciones diferentes, luego simule una pérdida y compruebe que puede retirar exactamente uno de ellos. El manual de openvpn(8) define el alcance de la opción; su procedimiento de retirada define si compartir es realmente aceptable.