AnyConnect cau quan es tanca un terminal: comprovacions de sessió

El túnel està actiu, tanqueu un terminal auxiliar i la VPN cau sense prémer cap tecla al client. Al client AnyConnect per a Linux la causa reportada és la comptabilitat de sessions, no l'encaminament: el client registra quines sessions d'inici existien quan es va aixecar el túnel i tracta el final de qualsevol d'elles com un motiu per ensorrar-lo. Les comprovacions següents s'executen en ordre, i la primera que falla us diu si esteu davant d'aquest comportament. Res a la sortida habitual del client no esmenta un terminal, i per això el primer impuls, culpar el concentrador, sol ser esforç perdut.

No comenceu editant fitxers del sistema. Cada pas o explica la caiguda o elimina un candidat, i els passos barats van primer.

Separeu una caiguda de sessió d'una caiguda de la xarxa subjacent

Torneu a connectar immediatament després de la desconnexió. Un túnel que torna en qüestió de segons, a la mateixa xarxa, sense credencials noves, apunta a un desencadenant local com una sessió tancada i no a un enllaç ascendent mort, a un canvi de xarxa Wi-Fi o a un temps d'espera per inactivitat al concentrador. Un túnel que es queda penjat a Connecting, o que falla fins que canvieu de xarxa, és un altre article.

Anoteu què estava obert quan es va aixecar el túnel: el terminal des del qual vau executar el client, qualsevol segon intèrpret, l'inici de sessió gràfic i qualsevol sessió SSH des d'una altra màquina. Necessitareu aquesta llista d'aquí a un moment, i reconstruir-la de memòria després de la propera caiguda no és fiable.

Comproveu què va registrar el client en connectar-se

El client no inspecciona els processos pare ni la propietat del terminal. Fa una instantània del conjunt de sessions d'inici presents en connectar-se i compara aquest conjunt més tard; quan un membre desapareix, la comparació falla i el túnel se'n va amb ell. Per això tancar la finestra des de la qual us vau connectar pot ser inofensiu mentre que tancar un terminal auxiliar no relacionat mata la connexió: el que importa és si aquella sessió era al conjunt original. La comprovació és una comparació de conjunts i no un recompte, i per això substituir una sessió pot ser tan fatal com perdre'n una.

Lliste què podia veure el client abans de canviar res:

who
w
last -n 10
sudo ls -l /run/utmp

Cada línia de who és una entrada de procés d'usuari a utmp. Si la vostra sessió apareix dues vegades, una per l'inici de sessió gràfic i una pel terminal, les dues entrades existien en connectar-se i totes dues són candidates.

Traieu només la vostra pròpia entrada d'utmp

La solució alternativa publicada fa invisible a utmp la sessió que esteu a punt d'utilitzar abans que arrenqui el client. Un petit programa en C recorre getutent(), troba el registre el ut_line del qual coincideix amb el TTY de l'entrada estàndard i després reescriu aquest registre. L'ordre és deliberat: setutent(), llegir l'entrada, copiar-ne el ut_id, posar ut_type a DEAD_PROCESS, esborrar els camps d'usuari i línia, tornar-la a escriure amb pututline() i després endutent().

Compileu-lo i executeu-lo com a root des de l'intèrpret que iniciarà el client:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Dos modes de fallada expliquen la majoria d'informes que diuen que l'eina no fa res. Actua sobre el TTY adjunt a l'entrada estàndard, així que executar-la des d'un script o una tasca cron sense terminal no li deixa res per emparellar. I /run/utmp no és escrivible pels usuaris normals, així que una execució sense root falla silenciosament tret que comproveu l'estat de sortida.

Verifiqueu que el túnel sobreviu al tancament

Proveu el mecanisme en lloc de suposar-lo. Connecteu-vos des d'una sessió que vulgueu mantenir, obriu un segon terminal, tanqueu el segon i després confirmeu que el túnel continua actiu amb vpn state i una ullada a la llista d'interfícies. Si el túnel sobreviu, el desencadenant era un tipus de sessió concret i no totes les sessions, i heu trobat la sessió que ha de quedar oberta.

Si encara cau, la sessió vigilada era en un altre lloc, sovint l'inici de sessió gràfic que va engendrar el vostre terminal, i treure una sola entrada de TTY no ajudarà. Repetiu l'observació amb la llista completa del primer pas en lloc d'afegir més cirurgia.

Quan reescriure utmp és la resposta equivocada

utmp és comptabilitat compartida, no una taula privada. Reescriure l'entrada d'una sessió que encara és viva fa que who, w i algunes eines d'auditoria la reportin per sota, i un programa que després tanqui la mateixa entrada pot fallar del tot. Manteniu l'eina limitada a la vostra pròpia sessió, guardeu una còpia del fitxer original i no la convertiu en un servei d'arrencada que elimini tots els registres.

Si el vostre lloc recull comptabilitat de sessions per compliment, la solució alternativa entra en conflicte amb aquest requisit i la resposta suportada és una altra versió del client o un altre mètode d'accés, no un utmp pedaçat. Per a la majoria de la gent la correcció menys invasiva és simplement iniciar el client des d'una sessió que romandrà oberta tot el dia i deixar aquella finestra tranquil·la.

Abans de tancar el tiquet, anoteu quina sessió vigilava el client quan es va aixecar el túnel. Aquesta sola línia és el que converteix una desconnexió misteriosa en una condició reproduïble per a la propera persona a la màquina.