PSK de L2TP/IPsec rexeitada: percorre o diálogo e despois os ficheiros

Pegas a clave precompartida da mensaxe do administrador no diálogo de NetworkManager, marcas a caixa para mostrala e coincide carácter por carácter. A conexión aínda remata nun fallo de autenticación antes de que o túnel estea levantado. A primeira vez que o vin supuxen que a clave estaba mal; non o estaba. Outras dúas cousas deciden o que le realmente o demo: o ficheiro de segredos que o complemento escribe para esa conexión e se o valor atravesou o diálogo sen cambios.

O percorrido de abaixo segue a clave do campo ao ficheiro, e esa é a orde que che di onde se perdeu. Faino na máquina que falla, non na que funciona, porque a diferenza entre esas dúas máquinas adoita ser a disposición dos ficheiros e non a clave.

Comeza polo diálogo, pero non confíes no campo

Abre a lapela IPsec da conexión e volve escribir a clave en lugar de pegala. Unha clave copiada dunha mensaxe de chat, dun PDF ou dun xestor de contrasinais pode chegar cun salto de liña final que o campo non mostra, e os caracteres visibles seguen parecendo correctos.

Fai clic no control de mostrar contrasinal e mira o final da cadea, non o medio. Se o cursor deixa unha liña baleira baixo o texto, bórraa e volve escribir o último carácter. Esa única corrección resolve unha parte sorprendente destes informes e custa menos que ler calquera rexistro.

Se a clave vén dun sistema de tíckets que parte as liñas longas, pídela por unha canle que non as parta. Compara as lonxitudes co administrador en vez de mirar dúas cadeas unha ao lado da outra; un carácter perdido nun punto de corte é invisible nunha fonte proporcional.

Segue a clave dentro de /etc/ipsec.d

O complemento nunca entrega a PSK ao demo de IPsec como argumento nunha liña de ordes. No seu lugar garda o valor nun ficheiro de segredos e fai que o demo inclúa ese ficheiro, engadindo unha liña include a /etc/ipsec.secrets se non hai ningunha. O que garda o diálogo é unha entrada para ese ficheiro xerado, non o valor en uso.

Enumera o que existe antes de cambiar nada:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

As versións antigas do complemento escribían un ficheiro por conexión, co nome do UUID da conexión, por exemplo /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Borrar un perfil na aplicación non borra ese ficheiro de forma fiable. Se un ficheiro vello dun servidor anterior segue no disco e aínda se inclúe, o demo pode escoller un segredo que pertence a un perfil que xa non usas, e a conexión falla mentres o campo visible é correcto.

Entende que fixo o cambio 1.2.12 coas actualizacións

A versión 1.2.12 do complemento substituíu os ficheiros de segredos por conexión por un único ficheiro compartido, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Unha actualización non limpa os ficheiros antigos por UUID, e unha liña include /etc/ipsec.d/*.secrets existente séguenos incluíndo. A versión 1.2.16 cambiou o tratamento das propostas predeterminadas, non a disposición dos segredos.

Esa historia explica por que dúas máquinas co que parece o mesmo perfil se comportan distinto. A clave é idéntica; o conxunto de ficheiros que o demo inclúe non o é. Cando retires un ficheiro orfo, móveo a un lado en lugar de borralo, confirma a conexión e bórrao cando o estado funcional estea rexistrado. Renomealo mantén o valor antigo recuperable se resulta que o fallo está noutro sitio.

Separa os caracteres que o formato de almacenamento non pode conter

A documentación de strongSwan para a cadea de segredo compartido indica que o valor non pode conter un salto de liña nin un carácter de comiñas dobres. Unha clave pegada desde un documento pode levar calquera dos dous sen ningunha diferenza visual nun diálogo normal.

Desde 1.2.12 o valor gardado non é texto simple. O complemento codifica a PSK en base64 antes de que chegue ao ficheiro, e as notas da versión presentan esa codificación como a razón pola que agora se acepta unha comiña dobre nunha clave. Unha comiña escrita no campo é, polo tanto, representable; o mesmo non vale para todos os caracteres de control.

A lonxitude é outra restrición. Non hai un mínimo universal no software L2TP/IPsec: algúns clientes aceptan claves máis curtas de vinte caracteres e algunhas pasarelas impoñen un mínimo. Se se rexeita unha clave curta, a regra pertence á política do servidor ou á validación dese cliente, e subir algo en local non o cambiará.

Le que capa de autenticación fallou

Executa primeiro ipsec --version, porque strongSwan e Libreswan usan nomes de ficheiro e sintaxe distintos, e un consello para un pode danar o outro. Despois le a etapa do fallo na mensaxe do cliente ou no rexistro do demo: unha queixa sobre a clave precompartida é un evento distinto dun nome de usuario e un contrasinal rexeitados.

A PSK autentica os extremos do túnel. O nome de usuario e o contrasinal autentican a persoa dentro de L2TP, e PPP encárgase deles unha vez levantada a asociación IPsec. Unha PSK correcta cunha conta equivocada segue fallando, e cambiar a conta non reparará unha clave que o demo nunca leu ben.

Cando peches o tícket, anota as catro cousas: versión do complemento, ficheiro de segredos en uso, se a clave se reescribiu ou se pegou e a capa que nomea o erro. Así, quen repita este percorrido máis adiante poderá saltar directo á diferenza entre a máquina que funciona e a que falla.