duplicate-cn dona a dos dispositius una sola identitat, no dues

Copieu el perfil a la tauleta, connecteu-vos i l'ordinador portàtil cau. Afegiu duplicate-cn, tots dos es queden connectats i el problema sembla resolt fins que els dos dispositius es barallen per la mateixa adreça de túnel o una tauleta perduda deixa tot el compte fora de línia. L'opció canvia una cosa i només una: si el servidor permet una segona sessió sota un nom que ja ha vist. Tot el que la gent espera que arregli, des de la independència dels dispositius fins a l'adreçament per dispositiu i la revocació selectiva, encara es fa per identitat, i la identitat aquí és el certificat.

El mite: una segona sessió és una segona identitat

La intuïció diu que dues connexions han de ser dos clients, i dos clients haurien de ser dos dispositius amb drets propis. El servidor no ho modela així. Veu un nom comú i, amb duplicate-cn activat, accepta més d'una sessió viva que porti aquest nom, i cadascuna rep el seu propi estat de sessió al dimoni.

Res d'aquesta acceptació no toca la verificació del certificat. El mateix certificat continua sent la credencial, la mateixa clau continua sent la clau privada, i qualsevol política basada en el subjecte del certificat encara es resol al mateix valor dues vegades. Una segona sessió és un segon socket, no una segona identitat.

Aquesta distinció és invisible mentre tot funciona. Es fa molt visible en el moment que cal distingir els dos dispositius, que normalment és el dia que un d'ells es perd.

Què canvia realment quan dues sessions comparteixen un nom

Sense l'opció, una connexió nova sota un nom comú que ja està connectat desplaça la sessió anterior. Per això l'ordinador portàtil cau quan es connecta la tauleta, i és una salvaguarda deliberada contra l'ambigüitat, no un error. Amb l'opció, totes dues sessions es mantenen vives i el servidor les segueix per separat per sessió, no per dispositiu.

Cada sessió continua tenint la seva pròpia connexió exterior i les seves pròpies claus negociades, així que el cabal simultani és realment simultani. El que comparteixen és tot el que deriva de la credencial: consultes de política, configuració específica del client, identitat als registres i revocació. L'estat de la sessió pertany a la connexió i mor amb ella, mentre que els fets a nivell de credencial persisteixen en totes dues. Per això la sortida d'estat pot llistar el mateix nom dues vegades mentre els comptadors es mantenen separats.

Comproveu què fa realment la vostra compilació abans de dissenyar-hi al voltant, perquè l'efecte de l'opció el defineix la mateixa opció i no la tradició oral:

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

L'adreça estàtica que us pensàveu que havíeu assignat

La configuració per client es busca pel nom, i aquí hi ha el parany. Un fitxer client-config-dir anomenat com el nom comú s'aplica a tots els dispositius que usen aquest nom, així que un ifconfig-push a dins dona als dos dispositius la mateixa adreça de túnel. La segona sessió o no s'estableix o col·lideix d'una manera que sembla una fallada d'encaminament.

Una piscina dinàmica es comporta millor per casualitat, perquè cada sessió rep una adreça de la piscina de manera independent. Això encara no us dona una adreça estable per dispositiu, i de cap manera us dona una política per dispositiu lligada a aquesta adreça.

Si el desplegament fa servir username-as-common-name, la clau de cerca passa a ser el nom d'usuari autenticat en lloc del subjecte del certificat, i la mateixa col·lisió es repeteix per a qualsevol que iniciï sessió dues vegades. El nom que impulsa la configuració ha de ser únic per dispositiu perquè la configuració per dispositiu signifiqui alguna cosa.

Què no pot fer una identitat compartida en el moment de la retirada

La revocació actua sobre el certificat, no sobre el nom visible ni sobre la sessió. Revogueu aquell certificat i tots els dispositius que en tinguin una còpia perden l'accés de cop, inclòs el que és a l'oficina i que ningú no vol destorbar. Manteniu-lo i el dispositiu perdut continua funcionant, perquè res del protocol no el distingeix de la còpia aprovada.

Els registres hereten la mateixa ambigüitat. La sortida d'estat mostra un nom comú i una adreça real, i tots dos poden pertànyer a qualsevol dels dos dispositius. Una revisió d'incident que necessiti saber quina màquina va fer què no pot respondre la pregunta amb els registres propis de la VPN, per molt detall que doni el nivell de registre.

No hi ha cap solució criptogràfica per a això. Dos dispositius que presenten el mateix certificat són, per al servidor, el mateix participant dues vegades, i qualsevol esquema que pretengui el contrari és una convenció de noms i no un control.

Quan compartir és correcte, i com limitar-ho

Compartir té usos legítims: un compte de laboratori usat per diverses màquines de prova, o una llar on els dispositius es gestionen junts i la granularitat de revocació no importa. En aquests casos, activeu l'opció deliberadament, manteniu la credencial compartida fora de la política per dispositiu i doneu espai a la piscina perquè les sessions no col·lideixin en una adreça.

Per a tot el que necessiti adreces separades, registres separats o retirada separada, emeteu certificats separats pel camí normal d'alta. Això dona a cada sistema posterior un objecte diferent en què basar-se, i l'opció deixa de tenir importància perquè els noms ja són únics.

Triïs el camí que triïs, proveu el model de gestió i no l'inici de sessió. Connecteu els dos dispositius, confirmeu que tenen adreces diferents, després simuleu una pèrdua i comproveu que podeu retirar exactament un d'ells. El manual d'openvpn(8) defineix l'abast de l'opció; el vostre procediment de retirada defineix si compartir és realment acceptable.