duplicate-cn dá a dous dispositivos unha soa identidade, non dúas

Copie o perfil na tableta, conéctese e o portátil cae. Engada duplicate-cn, ambos seguen conectados e o problema parece resolto ata que os dous dispositivos pelexan pola mesma dirección de túnel ou unha tableta perdida deixa toda a conta sen conexión. A opción cambia unha cousa e só unha: se o servidor permite unha segunda sesión baixo un nome que xa viu. Todo o que a xente espera que arranxe, desde a independencia dos dispositivos ata o direccionamento por dispositivo e a revogación selectiva, segue facéndose por identidade, e a identidade aquí é o certificado.

O mito: unha segunda sesión é unha segunda identidade

A intuición di que dúas conexións deben ser dous clientes, e dous clientes deberían ser dous dispositivos cos seus propios dereitos. O servidor non o modela así. Ve un nome común e, con duplicate-cn activado, acepta máis dunha sesión viva que leve ese nome, e cada unha recibe o seu propio estado de sesión no daemon.

Nada desa aceptación toca a verificación do certificado. O mesmo certificado segue sendo a credencial, a mesma clave segue sendo a clave privada, e calquera política baseada no suxeito do certificado segue resolvéndose ao mesmo valor dúas veces. Unha segunda sesión é un segundo socket, non unha segunda identidade.

Esa distinción é invisible mentres todo funciona. Vólvese moi visible no momento en que hai que distinguir os dous dispositivos, que adoita ser o día en que un deles se perde.

Que cambia realmente cando dúas sesións comparten un nome

Sen a opción, unha conexión nova baixo un nome común que xa está conectado despraza a sesión anterior. Por iso o portátil cae cando se conecta a tableta, e é unha salvagarda deliberada contra a ambigüidade, non un fallo. Coa opción, ambas as sesións seguen vivas e o servidor séguenas por separado por sesión, non por dispositivo.

Cada sesión segue tendo a súa propia conexión exterior e as súas propias claves negociadas, así que o caudal simultáneo é realmente simultáneo. O que comparten é todo o derivado da credencial: consultas de política, configuración específica do cliente, identidade nos rexistros e revogación. O estado de sesión pertence á conexión e morre con ela, mentres que os feitos a nivel de credencial persisten en ambas. Por iso a saída de estado pode listar o mesmo nome dúas veces mentres os contadores permanecen separados.

Comprobe que fai realmente a súa compilación antes de deseñar sobre ela, porque o efecto da opción defíneo a propia opción e non a tradición oral:

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

A dirección estática que pensaba que asignara

A configuración por cliente búscase por nome, e aí está a trampa. Un ficheiro client-config-dir co nome común aplicase a todos os dispositivos que usan ese nome, así que un ifconfig-push dentro del dá aos dous dispositivos a mesma dirección de túnel. A segunda sesión ou non se establece ou colide dun xeito que parece un fallo de encamiñamento.

Un pool dinámico compórtase mellor por casualidade, porque a cada sesión se lle asigna unha dirección do pool de forma independente. Iso segue sen darlle unha dirección estable por dispositivo, e desde logo non lle dá unha política por dispositivo ligada a esa dirección.

Se o despregamento usa username-as-common-name, a clave de busca pasa a ser o nome de usuario autenticado no canto do suxeito do certificado, e a mesma colisión repítese para calquera que inicie sesión dúas veces. O nome que impulsa a configuración ten que ser único por dispositivo para que a configuración por dispositivo signifique algo.

O que unha identidade compartida non pode facer ao retirar

A revogación actúa sobre o certificado, non sobre o nome visible nin sobre a sesión. Revogue ese certificado e todos os dispositivos que teñan unha copia perden o acceso á vez, incluído o que está na oficina e que ninguén quere molestar. Consérveo e o dispositivo perdido segue funcionando, porque nada no protocolo o distingue da copia aprobada.

Os rexistros herdan a mesma ambigüidade. A saída de estado mostra un nome común e unha dirección real, e ambos poden pertencer a calquera dos dous dispositivos. Unha revisión de incidentes que necesite saber que máquina fixo que non pode responder á pregunta cos propios rexistros da VPN, por moito detalle que dea o nivel de rexistro.

Non hai solución criptográfica para isto. Dous dispositivos que presentan o mesmo certificado son, para o servidor, o mesmo participante dúas veces, e calquera esquema que pretenda o contrario é unha convención de nomes e non un control.

Cando compartir é correcto e como delimitalo

Compartir ten usos lexítimos: unha conta de laboratorio usada por varias máquinas de proba, ou un fogar onde os dispositivos se xestionan xuntos e a granularidade de revogación non importa. Neses casos, active a opción deliberadamente, manteña a credencial compartida fóra da política por dispositivo e deixe marxe no pool para que as sesións non colidan nunha dirección.

Para todo o que necesite direccións separadas, rexistros separados ou retirada separada, emita certificados separados pola vía normal de alta. Iso dá a cada sistema posterior un obxecto distinto sobre o que basearse, e a opción deixa de importar porque os nomes xa son únicos.

Escolla a vía que escolla, probe o modelo de xestión e non o inicio de sesión. Conecte ambos os dispositivos, confirme que teñen direccións diferentes, logo simule unha perda e comprobe que pode retirar exactamente un deles. O manual de openvpn(8) define o alcance da opción; o seu procedemento de retirada define se compartir é realmente aceptable.