duplicate-cn dá a dois dispositivos uma só identidade, não duas

Copie o perfil para o tablet, ligue-se, e o portátil cai. Acrescente duplicate-cn, ambos ficam ligados, e o problema parece resolvido até os dois dispositivos disputarem o mesmo endereço de túnel ou um tablet perdido deixar a conta inteira offline. A opção muda uma coisa e apenas uma: se o servidor permite uma segunda sessão sob um nome que já viu. Tudo o que as pessoas esperam que corrija, da independência dos dispositivos ao endereçamento por dispositivo e à revogação seletiva, continua a ser feito por identidade, e a identidade aqui é o certificado.

O mito: uma segunda sessão é uma segunda identidade

A intuição diz que duas ligações devem ser dois clientes, e dois clientes deveriam ser dois dispositivos com os seus próprios direitos. O servidor não o modela assim. Vê um nome comum e, com duplicate-cn ativo, aceita mais do que uma sessão viva com esse nome, cada uma com o seu próprio estado de sessão no daemon.

Nada nessa aceitação toca na verificação do certificado. O mesmo certificado continua a ser a credencial, a mesma chave continua a ser a chave privada, e qualquer política baseada no assunto do certificado continua a resolver duas vezes para o mesmo valor. Uma segunda sessão é um segundo socket, não uma segunda identidade.

Essa distinção é invisível enquanto tudo funciona. Torna-se muito visível no momento em que precisa de distinguir os dois dispositivos, que costuma ser o dia em que um deles se perde.

O que muda realmente quando duas sessões partilham um nome

Sem a opção, uma nova ligação sob um nome comum que já está ligado desloca a sessão anterior. É por isso que o portátil cai quando o tablet se liga, e é uma salvaguarda deliberada contra a ambiguidade, não um erro. Com a opção, ambas as sessões permanecem vivas e o servidor segue-as separadamente por sessão, não por dispositivo.

Cada sessão continua a ter a sua própria ligação externa e as suas próprias chaves negociadas, por isso o débito simultâneo é realmente simultâneo. O que partilham é tudo o que deriva da credencial: consultas de política, configuração específica do cliente, identidade nos registos e revogação. O estado da sessão pertence à ligação e morre com ela, enquanto os factos ao nível da credencial persistem para ambas. É por isso que a saída de estado pode listar o mesmo nome duas vezes enquanto os contadores permanecem separados.

Confirme o que a sua compilação faz realmente antes de desenhar em torno dela, porque o efeito da opção é definido pela própria opção e não pela tradição oral:

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

O endereço estático que julgava ter atribuído

A configuração por cliente é procurada pelo nome, e é aí que está a armadilha. Um ficheiro client-config-dir com o nome comum aplica-se a todos os dispositivos que usam esse nome, pelo que um ifconfig-push lá dentro dá aos dois dispositivos o mesmo endereço de túnel. A segunda sessão ou não se estabelece, ou colide de uma forma que parece uma falha de encaminhamento.

Um pool dinâmico comporta-se melhor por acaso, porque a cada sessão é atribuído um endereço do pool de forma independente. Isso continua a não lhe dar um endereço estável por dispositivo, e muito menos uma política por dispositivo ligada a esse endereço.

Se a implementação usar username-as-common-name, a chave de procura passa a ser o nome de utilizador autenticado em vez do assunto do certificado, e a mesma colisão repete-se para quem inicie sessão duas vezes. O nome que comanda a configuração tem de ser único por dispositivo para que a configuração por dispositivo signifique algo.

O que uma identidade partilhada não pode fazer na altura da remoção

A revogação atua sobre o certificado, não sobre o nome apresentado e não sobre a sessão. Revoque esse certificado e todos os dispositivos que tenham uma cópia perdem o acesso de uma vez, incluindo o que está no escritório e que ninguém quer incomodar. Mantenha-o e o dispositivo perdido continua a funcionar, porque nada no protocolo o distingue da cópia aprovada.

Os registos herdam a mesma ambiguidade. A saída de estado mostra um nome comum e um endereço real, e ambos podem pertencer a qualquer dos dois dispositivos. Uma revisão de incidente que precise de saber que máquina fez o quê não consegue responder a essa pergunta com os próprios registos da VPN, por muito detalhe que o nível de registo dê.

Não há solução criptográfica para isto. Dois dispositivos que apresentam o mesmo certificado são, para o servidor, o mesmo participante duas vezes, e qualquer esquema que pretenda o contrário é uma convenção de nomes e não um controlo.

Quando partilhar é correto e como delimitá-lo

Partilhar tem usos legítimos: uma conta de laboratório usada por várias máquinas de teste, ou uma casa onde os dispositivos são geridos em conjunto e a granularidade da revogação não importa. Nesses casos, ative a opção deliberadamente, mantenha a credencial partilhada fora da política por dispositivo e dê margem ao pool para que as sessões não colidam num endereço.

Para tudo o que exija endereços separados, registos separados ou remoção separada, emita certificados separados pelo caminho normal de registo. Isso dá a cada sistema a jusante um objeto distinto em que se apoiar, e a opção deixa de importar porque os nomes já são únicos.

Qualquer que seja o caminho escolhido, teste o modelo de gestão e não o início de sessão. Ligue os dois dispositivos, confirme que têm endereços diferentes, depois simule uma perda e verifique que consegue remover exatamente um deles. O manual do openvpn(8) define o âmbito da opção; o seu procedimento de remoção define se a partilha é realmente aceitável.