AnyConnect паѓа кога ќе затворите терминал: проверки на сесиите

Тунелот е кренат, затворате резервен терминал, и VPN-от паѓа без ниту едно притиснато копче во клиентот. Кај Linux AnyConnect клиентот пријавената причина е сметководство на сесии, а не рутирање: клиентот запишува кои најавени сесии постоеле кога тунелот се кренал и крајот на која било од нив го смета за причина да го урне. Проверките подолу се изведуваат по ред, а првата што ќе падне ви кажува дали воопшто гледате во ова однесување. Во вообичаениот излез на клиентот не се спомнува терминал, затоа првиот инстинкт, да се обвини концентраторот, обично е залуден труд.

Не почнувајте со уредување системски датотеки. Секој чекор или го објаснува паѓањето или отстранува кандидат, а ефтините чекори доаѓаат први.

Одделете паѓање на сесија од паѓање на основната врска

Поврзете се повторно веднаш по прекинот. Тунел што се враќа во рок од неколку секунди, на истата мрежа и без нови акредитиви, укажува на локален предизвикувач, како затворена сесија, а не на мртва врска, Wi-Fi роаминг или неактивен тајмаут на концентраторот. Тунел што виси на Connecting или што не успева додека не ја смените мрежата е друг напис.

Запишете што било отворено кога тунелот се кренал: терминалот од кој го стартувавте клиентот, секоја втора школка, графичкото најавување и секоја SSH сесија од друга машина. Таа листа ќе ви треба за миг, а нејзиното реконструирање од сеќавање по следното паѓање е несигурно.

Проверете што клиентот запишал при поврзувањето

Клиентот не ги испитува родителите на процесите ниту сопственоста на терминалот. Тој прави снимка од множеството најавени сесии присутни при поврзувањето и подоцна го споредува тоа множество; кога член ќе исчезне, споредбата паѓа и тунелот оди со неа. Затоа затворањето на прозорецот од кој се поврзавте може да е безопасно, додека затворањето на неоврзан резервен терминал ја убива врската: важно е дали таа сесија била во првобитното множество. Тоа е споредба на множество, а не броење, затоа замената на сесија може да биде исто толку фатална како губењето една.

Наведете што можел да види клиентот пред да смените нешто:

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

Секој ред од who е запис за кориснички процес во utmp. Ако вашата сесија се појавува двапати, еднаш за графичкото најавување и еднаш за терминалот, двата записи постоеле при поврзувањето и двата се кандидати.

Отстранете само сопствениот запис од utmp

Објавеното решение ја прави сесијата што ќе ја користите невидлива во utmp пред клиентот да стартува. Мала C програма поминува низ getutent(), го наоѓа записот чиј ut_line е еднаков на TTY на стандардниот влез, потоа го препишува тој запис. Редоследот е намерен: setutent(), читање на записот, копирање на неговиот ut_id, поставување на ut_type на DEAD_PROCESS, бришење на полињата за корисник и линија, враќање со pututline(), потоа endutent().

Компајлирајте ја, потоа стартувајте ја како root од школката што ќе го стартува клиентот:

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

Два режима на неуспех објаснуваат повеќето извештаи дека алатката не прави ништо. Таа делува на TTY прикачен на стандардниот влез, па стартувањето од скрипта или cron задача без терминал не ѝ остава ништо за совпаѓање. И /run/utmp не е запишлив за обични корисници, па стартувањето без root тивко пропаѓа, освен ако не го проверите излезниот статус.

Проверете дали тунелот го преживува затворањето

Тестирајте го механизмот наместо да го претпоставувате. Поврзете се од сесија што имате намера да ја задржите, отворете втор терминал, затворете го вториот, потоа потврдете со vpn state и преглед на листата на интерфејси дека тунелот е сè уште кренат. Ако тунелот преживее, предизвикувачот бил одреден тип на сесија, а не секоја сесија, и ја најдовте сесијата што мора да остане отворена.

Ако сè уште паѓа, набљудуваната сесија била на друго место, најчесто графичкото најавување што го создало вашиот терминал, и отстранувањето на еден TTY запис нема да помогне. Повторете го набљудувањето со целосната листа од првиот чекор, наместо да додавате уште операции.

Кога препишувањето на utmp е погрешен одговор

utmp е заедничко сметководство, не приватна табела. Препишувањето на записот на сесија што е сè уште жива прави who, w и некои алатки за ревизија да ја прикажуваат помалку, а програма што подоцна ќе го затвори истиот запис може целосно да откаже. Ограничете ја алатката на сопствената сесија, чувајте копија од оригиналната датотека и не претворајте ја во услуга при подигање што брише секој запис.

Ако вашата организација собира сметководство на сесии за усогласеност, решението е во спротивност со тоа барање, а поддржаниот одговор е верзија на клиентот или друг метод на пристап, а не исправен utmp. За повеќето луѓе најмалку инвазивното решение е едноставно да го стартуваат клиентот од сесија што ќе остане отворена цел ден и да го остават тој прозорец на мир.

Пред да го затворите тикетот, запишете која сесија ја набљудувал клиентот кога тунелот се кренал. Таа единствена линија ја претвора мистериозната врска во повторлив услов за следниот човек на машината.