Por que openssl rand non pode crear a clave que tls-crypt quere

OpenSSL xa está instalado, o host ten entropía, e xerar unha clave con el parece o atallo obvio. A saída será aleatoria e secreta e completamente inutilizable, e o fallo chega como un erro do canal de control en lugar de como algo que mencione un formato de clave. Esa desorientación é a parte custosa, porque leva a xente a inspeccionar os seus cifrados. O que le a VPN é unha estrutura de ficheiro concreta, non un bloque arbitrario de bytes, e unha variante da función non se pode producir fóra do servidor en absoluto.

O que o ficheiro no disco ten que ser en realidade

Un ficheiro de clave estática de OpenVPN é texto. Comeza cunha liña de comentario que declara o que é, leva datos hexadecimais en filas de ancho fixo e suma 256 bytes de material de clave. OpenVPN léo como o segredo compartido do canal de control, non como un certificado, non como unha frase de paso e non como algo que unha biblioteca TLS recoñecería.

O mesmo tipo de obxecto serve as dúas funcións do canal de control. Con tls-auth, cada par tamén necesita unha dirección para que os paquetes dun lado non poidan reflectirse de volta cara a el. Con tls-crypt, un único segredo compartido cifra e autentica o canal de control en ambos os sentidos, o que oculta o aperta de mans ademais de protexelo.

Nada diso é coñecemento secreto, e o formato non é o punto. O punto é que o ficheiro ten que coincidir exactamente co que o lector espera: cabeceira, ancho de fila, salto de liña final e lonxitude total. Un ficheiro que se desvía nunha fila cárgase como lixo ou falla directamente. Comparar dous pares byte a byte é, por tanto, unha primeira proba lexítima, e é máis rápida que ler calquera dos dous ficheiros de configuración.

A forma admitida de crear un

Xere a clave estática simple coa ferramenta que a vai consumir e logo faga referencia a ela desde ambos os extremos:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

A grafía da opción cambiou co tempo: as instalacións antigas da era 2.4 usaban unha forma cun indicador separado antes do nome do ficheiro, mentres que as compilacións actuais aceptan a máis curta. En calquera caso, o ficheiro resultante é o mesmo tipo de obxecto, así que a comprobación é se ambos os pares teñen bytes idénticos.

A segunda xeración engade unha estrutura que ningún xerador externo pode inventar. Unha clave de servidor créase unha vez, e cada cliente recibe unha clave envolta derivada dela:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

O que recibe o cliente non é a propia clave do servidor duplicada. É un obxecto envolto que leva metadatos que só o servidor pode desenrolar, e ese envoltorio é a razón pola que un ficheiro por dispositivo se pode revogar sen tocar ningún outro dispositivo. Manteña a clave do servidor no servidor e trátea como a raíz desa confianza por dispositivo.

Onde fallan os bytes feitos a man

Imprimir 256 bytes aleatorios como hexadecimal baixo unha cabeceira correcta daría, en teoría, un ficheiro de clave estática que se carga. Segue sendo unha mala idea. Cada detalle de formato convértese nunha ocasión de producir material que falla ao cargar ou, peor, deixa dous pares con valores distintos que só se revelan como un fallo de autenticación.

Nada equivalente é posible coa variante v2. Unha clave de cliente envolta só existe como saída do proceso de clave do servidor, e o servidor conserva o material necesario para desenrolala. Un bloque aleatorio será rexeitado ou simplemente fallará ao descifrar, e ningunha das dúas mensaxes mencionará a aleatoriedade.

A compatibilidade de versións está por riba de todo isto. A primeira xeración necesita unha versión que a admita en ambos os extremos, e a segunda necesita outra versión máis nova. Un cliente compilado antes de que existise a función non pode completar un aperta de mans cun servidor que só acepta material envolto, e o fallo que informa apunta ao canal de control en lugar de á versión.

Rotar sen deixar a todos fóra

Rotar un único segredo compartido é un exercicio de coordinación, non técnico. Cada cliente necesita o ficheiro de substitución na man antes de que o servidor retire o anterior, e calquera máquina que aínda teña o valor antigo falla no momento en que iso ocorre. Non comece esa rotación no medio dunha xornada laboral.

Co esquema v2, a rotación é por dispositivo: emita unha nova clave envolta para unha máquina e retire a antiga só para esa máquina. Ese é o argumento principal para cambiar unha vez que todos os clientes estean nunha versión que o admita.

Os permisos de ficheiro pertencen á mesma conversa. A clave debería ser lexible só pola conta que executa o servizo, e non debería vivir no mesmo repositorio que os perfís que protexe. A referencia de OpenVPN 2.6 documenta as formas de xeración e as seccións de material de clave, que é unha fonte mellor que un comando copiado dunha publicación de foro.