OpenVPN auth-nocache: o que acontece no próximo login

Ative o auth-nocache e o aviso de cache da palavra-passe desaparece, junto com a cópia das credenciais que o OpenVPN guardava para a próxima renegociação. Se isso se torna um pedido, uma nova tentativa silenciosa ou um túnel cortado depende de onde vêm as credenciais da segunda vez. Por isso, isto é uma comparação entre formas de implementação e não um veredicto sobre a opção. Leia a forma que realmente executa antes de editar qualquer perfil.

De onde tem de vir o segundo conjunto de credenciais

O OpenVPN aplica o auth-nocache aos segredos recolhidos pelo auth-user-pass e pelo askpass: depois de usados, o processo descarta-os em vez de os guardar para o próximo handshake. A renegociação chega por temporizador, uma vez por hora por omissão, pelo que o segundo pedido chega muito depois de a pessoa que escreveu a palavra-passe ter seguido em frente. Essa lacuna é toda a história. Com a cache ligada, o cliente reproduz a cópia guardada sem perguntar a ninguém; com a cache desligada, tem de encontrar o segredo noutro sítio ou falhar.

Por isso, enumere todos os locais de onde o segredo pode vir naquele momento e seja honesto sobre quais deles existem no anfitrião. Uma pessoa num terminal, um ficheiro que o auth-user-pass ou o askpass consigam ler, ou um token de sessão emitido pelo servidor são os três que importam aqui. Se nenhum estiver disponível, a renegociação falha uma hora depois da alteração e não no momento em que a fez.

Três formas, três pontos de falha

Um cliente de ambiente de trabalho com uma pessoa à frente é o caso ligeiro: o pedido volta, alguém escreve a palavra-passe outra vez e o custo é atenção. Um serviço, contentor ou router que executa o OpenVPN sem terminal é o caso duro, porque não há ninguém para responder e a reconexão que antes era silenciosa agora termina o túnel. Um híbrido situa-se entre os dois e comporta-se como o caso de ambiente de trabalho até a sessão que podia responder ao pedido desaparecer. O que os separa não é haver uma GUI instalada, mas existir uma fonte de credenciais no momento da renegociação.

Mapeie a sua implementação para uma dessas três formas antes de mudar o que quer que seja, porque o conselho que encontra online é quase sempre escrito para a primeira. Aplicar a resposta de ambiente de trabalho a um serviço sem terminal é como um túnel que funcionou durante meses começa a cair a cada hora.

Diretiva ou flag: escolha uma e saiba qual usou

Dentro de um perfil, o auth-nocache é uma linha própria; numa invocação que nomeia um perfil explicitamente, é uma flag nessa linha de comandos, e o manual do OpenVPN lista ambas as formas. Ambas fazem o mesmo na retenção de credenciais e nenhuma toca no tipo de interface nem repara um aviso não relacionado no mesmo registo. A diferença é a persistência: a flag abrange apenas essa execução, pelo que um serviço reiniciado a partir de um ficheiro unit ou de um script envolvente não a terá, a menos que o envolvente também a passe.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Decida qual artefacto detém a definição, altere-a ali e em nenhum outro sítio. Um perfil editado num portátil mais uma unit do systemd que o substitui com uma flag é o par que produz comportamento contraditório após um reinício.

Um ficheiro de credenciais desloca o segredo em vez de o apagar

Apontar o auth-user-pass para um ficheiro dá uma fonte a cada renegociação posterior e também coloca a palavra-passe num local que sobrevive aos reinícios. Pergunte quem pode ler esse ficheiro, se o daemon ainda o consegue ler depois de abdicar de privilégios e o que acontece quando o sistema de ficheiros é montado só de leitura ou uma vista de contentor esconde o caminho. Um segredo no disco e um segredo em memória são problemas diferentes, e resolver um deixa o outro no seu lugar. A rotação é o passo que se salta: uma palavra-passe alterada no servidor mas não no ficheiro produz uma falha que se lê como um erro de rede.

Mantenha o ficheiro na posse da conta que executa o daemon, legível por mais ninguém e fora das cópias de segurança que saem do anfitrião. A opção auth-gen-token do lado do servidor do OpenVPN entrega ao cliente um token de sessão após um login bem-sucedido, o que é uma coisa menor para deixar por ali do que a palavra-passe da conta. Escreva o passo de rotação ao lado do ficheiro de qualquer forma, porque o ficheiro costuma sobreviver à pessoa que o criou.

Esticar a renegociação desloca o custo, não o elimina

A outra sugestão é subir o reneg-sec até o pedido ser suficientemente raro para ser ignorado. Isso reescreve o calendário de rotação de chaves da sessão e empurra o mesmo problema de credenciais para um momento mais tardio e menos previsível; não cria uma fonte de credenciais. Uma política que renova chaves segundo um calendário por algum motivo não deve ser relaxada só para evitar escrever uma palavra-passe.

Teste a reconexão e não a sessão em que está sentado, porque a sessão viva não prova nada. Deixe cair o túnel do lado do servidor, ou reinicie o serviço do cliente, e observe o que a renegociação seguinte faz sem ninguém ao teclado. Se voltar a ligar-se, nomeie o mecanismo que forneceu o segredo; se não, encontrou o custo real da opção neste anfitrião. Qualquer dos resultados lhe dá uma resposta que aguenta durante uma falha em vez de uma que aguentou durante os testes.

Numa frota gerida, quem detém a implementação deve saber nomear três coisas: de onde vêm as credenciais, onde são guardadas e quem as roda. Se alguma dessas respostas for a pessoa que configurou o anfitrião, a opção ainda não é segura ali.