AnyConnect cae ao pechar un terminal: comprobacións de sesión

O túnel está activo, pechas un terminal de máis e a VPN cae sen unha soa pulsación no cliente. No cliente AnyConnect para Linux a causa informada é a contabilidade de sesións e non o encamiñamento: o cliente rexistra que sesións de acceso existían cando se levantou o túnel e trata o final de calquera delas como motivo para derrubalo. As comprobacións seguintes execútanse en orde, e a primeira que falla diche se estás a ver este comportamento. Nada na saída habitual do cliente menciona un terminal, por iso o primeiro instinto, culpar o concentrador, adoita ser esforzo perdido.

Non comeces editando ficheiros do sistema. Cada paso ou explica a caída ou elimina un candidato, e os pasos baratos van primeiro.

Separa unha caída de sesión dunha caída da rede subxacente

Vólve conectar inmediatamente despois da desconexión. Un túnel que regresa en segundos, na mesma rede, sen credenciais novas, apunta a un desencadeante local como unha sesión pechada e non a unha ligazón ascendente morta, a unha itinerancia Wi-Fi ou a un tempo de espera por inactividade no concentrador. Un túnel que queda colgado en Connecting, ou que falla ata que cambias de rede, é outro artigo.

Anota que estaba aberto cando se levantou o túnel: o terminal desde o que executaches o cliente, calquera segundo intérprete, o acceso gráfico e calquera sesión SSH desde outra máquina. Necesitarás esa lista nun intre, e reconstruíla de memoria tras a seguinte caída non é fiable.

Comproba que rexistrou o cliente ao conectar

O cliente non inspecciona os procesos pai nin a propiedade do terminal. Toma unha instantánea do conxunto de sesións de acceso presentes ao conectar e compara ese conxunto máis tarde; cando un membro desaparece, a comparación falla e o túnel vaise con el. Por iso pechar a ventá desde a que conectaches pode ser inofensivo mentres que pechar un terminal de máis sen relación mata a conexión: o que importa é se esa sesión estaba no conxunto orixinal. A comprobación é unha comparación de conxuntos e non un reconto, por iso substituír unha sesión pode ser tan fatal como perder unha.

Enumera o que o cliente podía ver antes de cambiar nada:

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

Cada liña de who é unha entrada de proceso de usuario en utmp. Se a túa sesión aparece dúas veces, unha polo acceso gráfico e outra polo terminal, ambas as entradas existían ao conectar e ambas son candidatas.

Elimina só a túa propia entrada de utmp

O apaño publicado fai invisible en utmp a sesión que estás a piques de usar antes de que arrinque o cliente. Un pequeno programa en C percorre getutent(), atopa o rexistro cuxo ut_line coincide co TTY da entrada estándar e despois reescribe ese rexistro. A orde é deliberada: setutent(), ler a entrada, copiar o seu ut_id, pór ut_type en DEAD_PROCESS, borrar os campos de usuario e liña, escribila de novo con pututline() e logo endutent().

Compílao e execútao como root desde o intérprete que iniciará o cliente:

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

Dous modos de fallo explican a maioría dos informes de que a ferramenta non fai nada. Actúa sobre o TTY asociado á entrada estándar, así que executala desde un script ou unha tarefa cron sen terminal non lle deixa nada co que coincidir. E /run/utmp non é escribible polos usuarios normais, así que unha execución sen root falla en silencio agás que comprobes o estado de saída.

Verifica que o túnel sobrevive ao peche

Proba o mecanismo en lugar de supoñelo. Conéctate desde unha sesión que pretendas manter, abre un segundo terminal, pecha o segundo e logo confirma que o túnel segue activo con vpn state e unha ollada á lista de interfaces. Se o túnel sobrevive, o desencadeante era un tipo de sesión concreto e non todas as sesións, e atopaches a sesión que debe permanecer aberta.

Se aínda cae, a sesión vixiada estaba noutro sitio, case sempre o acceso gráfico que xerou o teu terminal, e quitar unha soa entrada de TTY non axudará. Repite a observación coa lista completa do primeiro paso en lugar de engadir máis cirurxía.

Cando reescribir utmp é a resposta equivocada

utmp é contabilidade compartida, non unha táboa privada. Reescribir a entrada dunha sesión que segue viva fai que who, w e algunhas ferramentas de auditoría a informen por baixo, e un programa que despois peche esa mesma entrada pode fallar por completo. Mantén a ferramenta limitada á túa propia sesión, garda unha copia do ficheiro orixinal e non a convirtas nun servizo de arranque que elimine todos os rexistros.

Se a túa organización recolle contabilidade de sesións por cumprimento, o apaño choca con ese requisito e a resposta admitida é outra versión do cliente ou outro método de acceso, non un utmp parcheado. Para a maioría da xente a corrección menos invasiva é simplemente iniciar o cliente desde unha sesión que permanecerá aberta todo o día e deixar esa ventá en paz.

Antes de pechar o tícket, anota que sesión vixiaba o cliente cando se levantou o túnel. Esa soa liña é o que converte unha desconexión misteriosa nunha condición reproducíbel para a seguinte persoa na máquina.