AnyConnect katkeaa, kun pääte suljetaan: istuntotarkistukset

Tunneli on päällä, suljet ylimääräisen päätteen, ja VPN putoaa ilman yhtäkään näppäimenpainallusta asiakasohjelmassa. Linuxin AnyConnect-asiakasohjelmassa ilmoitettu syy on istuntojen kirjanpito eikä reititys: asiakasohjelma tallentaa, mitkä kirjautumisistunnot olivat olemassa tunnelia nostettaessa, ja pitää minkä tahansa niistä päättymistä syynä purkaa se. Alla olevat tarkistukset ajetaan järjestyksessä, ja ensimmäinen epäonnistuva kertoo, oletko ylipäätään tämän käyttäytymisen äärellä. Mikään asiakasohjelman tavallisessa tulosteessa ei mainitse päätettä, minkä vuoksi ensimmäinen vaisto, konsentraattorin syyttäminen, on yleensä hukattua vaivaa.

Älä aloita järjestelmätiedostojen muokkaamisesta. Jokainen vaihe joko selittää putoamisen tai poistaa ehdokkaan, ja halvat vaiheet tulevat ensin.

Erota istunnon putoaminen alla olevan verkon putoamisesta

Yhdistä uudelleen heti katkeamisen jälkeen. Tunneli, joka palaa sekunneissa, samassa verkossa, ilman uusia tunnistetietoja, viittaa paikalliseen laukaisimeen, kuten suljettuun istuntoon, eikä kuolleeseen ylälinkkiin, Wi-Fi-verkkovierailuun tai joutokäynnin aikakatkaisuun konsentraattorissa. Tunneli, joka jää jumiin kohtaan Connecting tai epäonnistuu, kunnes vaihdat verkkoa, on toinen artikkeli.

Kirjoita muistiin, mitä oli auki tunnelia nostettaessa: pääte, josta käynnistit asiakasohjelman, mahdollinen toinen komentotulkki, graafinen kirjautuminen ja mikä tahansa SSH-istunto toisesta koneesta. Tarvitset sitä listaa hetken kuluttua, ja sen muistista rekonstruointi seuraavan putoamisen jälkeen ei ole luotettavaa.

Tarkista, mitä asiakasohjelma tallensi yhdistämishetkellä

Asiakasohjelma ei tutki prosessien vanhempia tai päätteen omistajuutta. Se ottaa tilannekuvan yhdistämishetkellä olevista kirjautumisistunnoista ja vertaa tätä joukkoa myöhemmin; kun jäsen katoaa, vertailu epäonnistuu ja tunneli lähtee sen mukana. Siksi ikkunan sulkeminen, josta yhdistit, voi olla vaaratonta, kun taas asiaankuulumattoman ylimääräisen päätteen sulkeminen tappaa yhteyden: ratkaisee, oliko se istunto alkuperäisessä joukossa. Tarkistus on joukkojen vertailu eikä laskeminen, minkä vuoksi istunnon korvaaminen voi olla yhtä kohtalokasta kuin sen menettäminen.

Luettele, mitä asiakasohjelma saattoi nähdä ennen kuin muutat mitään:

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

Jokainen who-komennon rivi on käyttäjäprosessin merkintä tiedostossa utmp. Jos istuntosi näkyy kahdesti, kerran graafista kirjautumista ja kerran päätettä varten, molemmat merkinnät olivat olemassa yhdistämishetkellä ja molemmat ovat ehdokkaita.

Poista utmp-tiedostosta vain oma merkintäsi

Julkaistu kiertotapa tekee käyttämäsi istunnon näkymättömäksi tiedostossa utmp ennen asiakasohjelman käynnistymistä. Pieni C-ohjelma käy läpi getutent(), löytää tietueen, jonka ut_line vastaa vakiosyötteen TTY:tä, ja kirjoittaa tämän tietueen uudelleen. Järjestys on tarkoituksellinen: setutent(), lue merkintä, kopioi sen ut_id, aseta ut_type arvoon DEAD_PROCESS, tyhjennä käyttäjä- ja rivikentät, kirjoita se takaisin komennolla pututline() ja sitten endutent().

Käännä se ja aja sitten rootina komentotulkista, joka käynnistää asiakasohjelman:

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

Kaksi epäonnistumistapaa selittää suurimman osan raporteista, joiden mukaan työkalu ei tee mitään. Se vaikuttaa vakiosyötteeseen liitettyyn TTY:hen, joten ajaminen skriptistä tai cron-työstä ilman päätettä ei jätä sille mitään sovitettavaa. Ja /run/utmp ei ole tavallisten käyttäjien kirjoitettavissa, joten ilman rootia ajaminen epäonnistuu hiljaisesti, ellet tarkista poistumistilaa.

Varmista, että tunneli selviää sulkemisesta

Testaa mekanismia sen sijaan että olettaisit sen. Yhdistä istunnosta, jonka aiot pitää, avaa toinen pääte, sulje toinen ja varmista sitten vpn state-komennolla ja vilkaisemalla liitäntäluetteloa, että tunneli on edelleen päällä. Jos tunneli selviää, laukaisin oli tietty istuntotyyppi eikä jokainen istunto, ja olet löytänyt istunnon, jonka täytyy pysyä auki.

Jos se putoaa edelleen, tarkkailtu istunto oli muualla, useimmiten graafinen kirjautuminen, joka synnytti päätteesi, eikä yhden TTY-merkinnän poistaminen auta. Toista havainto ensimmäisen vaiheen täydellä listalla sen sijaan että lisäisit lisää kirurgiaa.

Milloin utmp-tiedoston uudelleenkirjoitus on väärä vastaus

utmp on jaettua kirjanpitoa, ei yksityinen taulu. Elossa olevan istunnon merkinnän uudelleenkirjoitus saa who, w ja eräät auditointityökalut raportoimaan sen todellista pienempänä, ja ohjelma, joka myöhemmin sulkee saman merkinnän, voi epäonnistua täysin. Pidä työkalu rajattuna omaan istuntoosi, säilytä kopio alkuperäisestä tiedostosta äläkä tee siitä käynnistyspalvelua, joka poistaa jokaisen tietueen.

Jos organisaatiosi kerää istuntokirjanpitoa vaatimustenmukaisuutta varten, kiertotapa on ristiriidassa tämän vaatimuksen kanssa ja tuettu vastaus on toinen asiakasohjelmaversio tai muu käyttötapa, ei paikattu utmp. Useimmille ihmisille vähiten tunkeileva korjaus on yksinkertaisesti käynnistää asiakasohjelma istunnosta, joka pysyy auki koko päivän, ja jättää se ikkuna rauhaan.

Ennen kuin suljet tiketin, kirjaa, mitä istuntoa asiakasohjelma tarkkaili tunnelia nostettaessa. Juuri tuo yksi rivi muuttaa mystisen katkeamisen toistettavaksi ehdoksi seuraavalle koneella olevalle henkilölle.