Bumabagsak ang AnyConnect kapag nagsara ng terminal: mga pagsusuri ng sesyon

Nakaupo ang tunnel, nagsara ka ng ekstrang terminal, at bumabagsak ang VPN nang walang kahit isang pagpindot sa client. Sa AnyConnect client sa Linux, ang iniulat na dahilan ay accounting ng sesyon at hindi routing: itinatala ng client kung aling mga sesyon ng pag-login ang umiiral noong umakyat ang tunnel at itinuturing na dahilan ang pagtatapos ng alinman sa mga ito para ibagsak ito. Ang mga pagsusuri sa ibaba ay sunod-sunod, at ang unang bumagsak ang magsasabi kung ito nga ang nakikita mo. Walang binabanggit na terminal ang karaniwang output ng client, kaya ang unang instinct, ang sisihin ang concentrator, ay karaniwang sayang na pagod.

Huwag magsimula sa pag-edit ng mga file ng system. Ang bawat hakbang ay nagpapaliwanag ng pagbagsak o nag-aalis ng isang kandidato, at ang murang hakbang ang nauuna.

Ihiwalay ang pagbagsak ng sesyon sa pagbagsak ng underlay

Kumonekta muli agad pagkatapos ng pagputol. Ang tunnel na bumabalik sa loob ng ilang segundo, sa parehong network at walang bagong kredensyal, ay tumuturo sa lokal na trigger tulad ng saradong sesyon at hindi sa patay na uplink, Wi-Fi roam o idle timeout sa concentrator. Ang tunnel na nakabitin sa Connecting, o nabigo hanggang magpalit ka ng network, ay ibang artikulo.

Isulat kung ano ang bukas noong umakyat ang tunnel: ang terminal na pinagpatakbuhan mo ng client, anumang pangalawang shell, ang graphical na pag-login, at anumang sesyon ng SSH mula sa ibang makina. Kakailanganin mo ang listahan maya-maya, at ang muling pagbuo nito mula sa memorya pagkatapos ng susunod na pagbagsak ay hindi mapagkakatiwalaan.

Suriin kung ano ang itinala ng client noong kumonekta

Hindi sinusuri ng client ang mga magulang ng proseso o pagmamay-ari ng terminal. Kumukuha ito ng snapshot ng set ng mga sesyon ng pag-login na umiiral noong kumonekta at ihinahambing ang set na iyon mamaya; kapag may nawalang miyembro, bumagsak ang paghahambing at kasama ang tunnel. Kaya maaaring walang pinsala ang pagsara ng window na pinagkonektahan mo, habang ang pagsara ng walang kaugnayang ekstrang terminal ay pumapatay ng koneksyon: ang mahalaga ay kung ang sesyong iyon ay nasa orihinal na set. Paghahambing ito ng set at hindi pagbilang, kaya ang pagpapalit ng sesyon ay maaaring kasing dahas ng pagkawala ng isa.

Ilista kung ano ang nakita ng client bago ka magbago ng anuman:

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

Ang bawat linya mula sa who ay entry ng proseso ng user sa utmp. Kung dalawang beses lumabas ang sesyon mo, isa para sa graphical na pag-login at isa para sa terminal, parehong entry ay umiral noong kumonekta at parehong kandidato.

Alisin lamang ang sarili mong entry mula sa utmp

Ginagawa ng publikadong solusyon na di-makita sa utmp ang sesyong gagamitin mo bago magsimula ang client. May maliit na programang C na dumadaan sa getutent(), hinahanap ang rekord na ang ut_line ay katumbas ng TTY ng standard input, at isinusulat muli ang rekord na iyon. Ang pagkakasunod-sunod ay sinadya: setutent(), basahin ang entry, kopyahin ang ut_id nito, itakda ang ut_type sa DEAD_PROCESS, burahin ang user at line field, isulat muli gamit ang pututline(), pagkatapos ang endutent().

Kompilahin ito, pagkatapos patakbuhin bilang root mula sa shell na magsisimula ng client:

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

Dalawang mode ng pagpalya ang nagpapaliwanag sa karamihan ng ulat na walang ginagawa ang tool. Gumagana ito sa TTY na nakakabit sa standard input, kaya ang pagpapatakbo mula sa script o cron job na walang terminal ay walang naiiwang itutugma. At ang /run/utmp ay hindi maisusulat ng ordinaryong user, kaya tahimik na nabigo ang pagpapatakbo na walang root maliban kung suriin mo ang exit status.

Kumpirmahin na nakakaligtas ang tunnel sa pagsara

Subukan ang mekanismo sa halip na ipagpalagay ito. Kumonekta mula sa sesyong balak mong itago, magbukas ng pangalawang terminal, isara ang pangalawa, pagkatapos kumpirmahin gamit ang vpn state at pagtingin sa listahan ng interface na nakaupo pa ang tunnel. Kung nakaligtas ang tunnel, ang trigger ay isang partikular na uri ng sesyon at hindi lahat, at nahanap mo na ang sesyong dapat manatiling bukas.

Kung bumabagsak pa rin, ang binabantayang sesyon ay nasa ibang lugar, kadalasan ang graphical na pag-login na gumawa ng terminal mo, at walang maitutulong ang pag-alis ng isang TTY entry. Ulitin ang obserbasyon gamit ang buong listahan mula sa unang hakbang sa halip na magdagdag pa ng operasyon.

Kapag mali ang muling pagsulat ng utmp

Ang utmp ay pinagsasaluhang accounting, hindi pribadong talahanayan. Ang muling pagsulat ng entry ng sesyong buhay pa ay nagiging dahilan para kulang ang iulat ng who, w at ilang tool sa audit, at ang programang magsasara sa parehong entry mamaya ay maaaring tuluyang mabigo. Ilimitahan ang tool sa sarili mong sesyon, magtabi ng kopya ng orihinal na file, at huwag itong gawing serbisyo sa boot na nag-aalis ng bawat rekord.

Kung nangongolekta ang site mo ng accounting ng sesyon para sa pagsunod, sumasalungat ang solusyong ito sa pangangailangang iyon at ang sinusuportahang sagot ay isang bersyon ng client o ibang paraan ng access, hindi isang naka-patch na utmp. Para sa karamihan, ang pinakamaliit na panghihimasok ay ang simulan ang client mula sa sesyong mananatiling bukas buong araw at hayaang payapa ang window na iyon.

Bago isara ang ticket, itala kung aling sesyon ang binabantayan ng client noong umakyat ang tunnel. Ang nag-iisang linyang iyon ang gumagawa sa mahiwagang pagkakadiskonekta na maging kondisyong maaaring ulitin para sa susunod na tao sa makina.