Falta o aviso TOTP de OpenConnect en NetworkManager: catro comprobacións

A pasarela acepta o contrasinal, pide un código e o diálogo non ofrece ningún campo para el. Non se escribiu nada mal: o complemento de NetworkManager completou o intercambio de segredos sen solicitar o valor de seis díxitos. Faga as catro comprobacións seguintes en orde, porque só unha delas cambia o cliente. O resto da lista descarta a pasarela, a conta e a compilación do complemento.

Primeira comprobación: lea onde se detivo a autenticación

Un contrasinal incorrecto falla de inmediato. Un segundo factor ausente falla despois do paso de credenciais, normalmente cunha petición repetida ou un tempo de espera esgotado no lado da pasarela. O momento e o rexistro da pasarela indican que rolda quedou sen resposta.

Lea o rexistro da conexión antes de tocar o perfil. Se a pasarela informa dunha autenticación incompleta ou dun desafío caducado, o cliente nunca enviou o código. Se informa de credenciais non válidas, o problema é o contrasinal e ningún axuste de TOTP o arranxará.

Anote a secuencia exacta de peticións que espera a pasarela: nome de usuario, contrasinal e despois código, ou nome de usuario, código e despois contrasinal. Algunhas pasarelas reordenan as roldas, e un cliente que só coñece a primeira orde atascará na segunda.

Segunda comprobación: use o cliente que posúe o desafío

O propio OpenConnect implementa toda a conversa, incluída a rolda de desafío. Executalo directamente é a forma máis previsible de confirmar que a conta e a pasarela funcionan:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

O cliente pregunta na orde en que pregunta a pasarela. O axente de usuario importa porque algunhas pasarelas adaptan o fluxo de inicio de sesión a un cliente coñecido, e unha cadea xenérica pode producir un fluxo máis curto que nunca pida o código. Execúteo unha vez en primeiro plano antes de preparar calquera servizo en segundo plano.

Se a liña de ordes pregunta correctamente, a conta, a pasarela e o segundo factor están ben. O problema restante é o diálogo do complemento, non o servizo de autenticación. Iso illa o compoñente que falla sen tocar o servidor. Garde a saída da orde xunto co rexistro do incidente.

Se a liña de ordes tamén omite a petición, detéñase e comprobe a configuración da pasarela co seu responsable. Ningún cliente de escritorio pode responder a un desafío que o servidor nunca envía.

Terceira comprobación: vexa se o seu complemento expón o modo TOTP

Algunhas compilacións de NetworkManager OpenConnect expoñen un modo de token e un campo de axente de usuario na pestana Identity da conexión. Axuste o axente de usuario ao valor que espera a pasarela, seleccione a entrada manual de TOTP e garde a conexión.

Que eses campos existan depende da versión do complemento e de que editor de conexións use o escritorio. Un editor independente pode mostrar opcións que o panel de GNOME oculta, ou ao revés. Comprobe a versión do paquete instalado antes de buscar un axuste oculto.

Se o modo de token existe e a petición segue sen aparecer, a compilación carece da transferencia de desafío entre o complemento e o diálogo xenérico de segredos. Reescribir o contrasinal, reinstalar o mesmo paquete ou limpar o chaveiro non creará un campo que a compilación non implemente.

Cuarta comprobación: trate un código xerado como un compromiso

Un script pode chamar a oathtool para o código actual e pasar o nome de usuario, o contrasinal e o código a nmcli connection up --ask. A secuencia funciona, pero o segredo compartido acaba almacenado nun lugar lexible por calquera que poida abrir o script, e ese lector pode fabricar códigos para sempre. Iso é unha extensión permanente da superficie de credenciais, non unha solución do cliente.

Quen o elixa debe restrinxir o ficheiro de segredo a root, manter os valores xerados fóra do historial da shell e tratar o script como material de credenciais. Un envoltorio que mostra o código no terminal tira o segundo factor. Probe primeiro o envoltorio cunha conta refugable.

O script tamén debe seguir a orde de peticións da pasarela. Se o servidor pide o código antes do contrasinal, unha secuencia de entrada fixa envía o valor equivocado á petición equivocada e produce a mesma autenticación incompleta. Ensáeo cunha conta de proba antes de conectalo a unha tarefa de inicio de sesión.

Confirme a mesma pasarela e a mesma conta

Probe cada solución alternativa contra a mesma pasarela, a mesma conta e o mesmo grupo de túnel. Unha pasarela que tamén esixe un certificado de dispositivo pode rexeitar o cliente de liña de ordes por un motivo alleo a TOTP, e a orde das peticións pode diferir da que ensaiou.

Anote o cliente, a súa versión, o axente de usuario e a secuencia de peticións que funcionou. Ese rexistro di á seguinte persoa se o problema é a compilación do complemento, o fluxo da pasarela ou a política da conta, sen outra rolda de restablecementos de contrasinal.

Remate reconectando unha vez tras un peche de sesión completo. Un segredo en caché pode facer que un fluxo roto pareza arranxado ata a sesión seguinte, e é na segunda conexión onde a petición ausente adoita volver.