Falta l’indicació de TOTP d’OpenConnect a NetworkManager: quatre comprovacions

La passarel·la accepta la contrasenya, demana un codi i el diàleg no ofereix cap camp per a ell. No s’ha escrit res malament: el connector del NetworkManager ha completat l’intercanvi de secret sense demanar el valor de sis xifres. Feu les quatre comprovacions següents en ordre, perquè només una d’elles canvia el client. La resta de la llista descarta la passarel·la, el compte i la compilació del connector.

Comprovació primera: llegiu on s’ha aturat l’autenticació

Una contrasenya incorrecta falla de seguida. Un segon factor absent falla després del pas de credencials, normalment amb una sol·licitud repetida o un temps d’espera esgotat a la banda de la passarel·la. El moment i el registre de la passarel·la indiquen quina ronda ha quedat sense resposta.

Llegiu el registre de la connexió abans de tocar el perfil. Si la passarel·la informa d’una autenticació incompleta o d’un repte caducat, el client no ha enviat mai el codi. Si informa de credencials no vàlides, el problema és la contrasenya i cap ajust de TOTP no ho arreglarà.

Anoteu la seqüència exacta de sol·licituds que espera la passarel·la: nom d’usuari, contrasenya i després codi, o nom d’usuari, codi i després contrasenya. Algunes passarel·les reordenen les rondes, i un client que només coneix el primer ordre s’encallarà al segon.

Comprovació segona: feu servir el client que posseeix el repte

El mateix OpenConnect implementa tota la conversa, inclosa la ronda de repte. Executar-lo directament és la manera més previsible de confirmar que el compte i la passarel·la funcionen:

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

El client pregunta en l’ordre que pregunta la passarel·la. L’agent d’usuari importa perquè algunes passarel·les adapten el flux d’inici de sessió a un client conegut, i una cadena genèrica pot produir un flux més curt que no demani mai el codi. Executeu-lo una vegada en primer pla abans de preparar cap servei en segon pla.

Si la línia d’ordres pregunta correctament, el compte, la passarel·la i el segon factor estan bé. El problema restant és el diàleg del connector, no el servei d’autenticació. Això aïlla el component que falla sense tocar el servidor. Guardeu la sortida de l’ordre amb el registre de l’incident.

Si la línia d’ordres també omet la sol·licitud, atureu-vos i comproveu la configuració de la passarel·la amb el seu responsable. Cap client d’escriptori no pot respondre a un repte que el servidor no envia mai.

Comprovació tercera: mireu si el vostre connector exposa el mode TOTP

Algunes compilacions de NetworkManager OpenConnect exposen un mode de testimoni i un camp d’agent d’usuari a la pestanya Identity de la connexió. Poseu l’agent d’usuari al valor que espera la passarel·la, trieu l’entrada manual de TOTP i deseu la connexió.

Que aquests camps existeixin depèn de la versió del connector i de quin editor de connexions faci servir l’escriptori. Un editor independent pot mostrar opcions que el tauler del GNOME amaga, o al revés. Comproveu la versió del paquet instal·lat abans de buscar un ajust amagat.

Si el mode de testimoni hi és i la sol·licitud encara no apareix, la compilació no té el traspàs de repte entre el connector i el diàleg genèric de secrets. Reescribir la contrasenya, reinstal·lar el mateix paquet o netejar l’anell de claus no crearà un camp que la compilació no implementi.

Comprovació quarta: tracteu un codi generat com un compromís

Un script pot cridar oathtool per al codi actual i passar el nom d’usuari, la contrasenya i el codi a nmcli connection up --ask. La seqüència funciona, però el secret compartit acaba desat en un lloc llegible per qui pugui obrir l’script, i aquell lector pot fabricar codis per sempre. Això és una extensió permanent de la superfície de credencials, no una solució del client.

Qui ho triï ha de tancar el fitxer de secret a root, mantenir els valors generats fora de l’historial de l’intèrpret i tractar l’script com a material de credencials. Un embolcall que fa eco del codi al terminal llança el segon factor. Prova primer l’embolcall amb un compte temporal.

L’script també ha de seguir l’ordre de sol·licituds de la passarel·la. Si el servidor demana el codi abans de la contrasenya, una seqüència d’entrada fixa envia el valor equivocat a la sol·licitud equivocada i produeix la mateixa autenticació incompleta. Assageu-ho amb un compte de prova abans de connectar-ho a una tasca d’inici de sessió.

Confirmeu la mateixa passarel·la i el mateix compte

Proveu cada solució alternativa contra la mateixa passarel·la, el mateix compte i el mateix grup de túnel. Una passarel·la que també exigeix un certificat de dispositiu pot rebutjar el client de línia d’ordres per un motiu aliè a TOTP, i l’ordre de les sol·licituds pot diferir del que heu assajat.

Anoteu el client, la seva versió, l’agent d’usuari i la seqüència de sol·licituds que ha funcionat. Aquest registre diu a la persona següent si el problema és la compilació del connector, el flux de la passarel·la o la política del compte, sense una altra ronda de restabliment de contrasenyes.

Acabeu reconnectant una vegada després d’un tancament de sessió complet. Un secret en memòria cau pot fer que un flux trencat sembli arreglat fins a la sessió següent, i és en la segona connexió on la sol·licitud absent sol tornar.