Kuinka kauan OpenConnectin pitäisi yrittää katkennutta VPN:ää uudelleen?

--reconnect-timeout vastaa yhteen kapeaan kysymykseen: kun tunneli kaatuu, kuinka kauan tämä asiakasprosessi vielä yrittää ennen kuin se luovuttaa ja poistuu. OpenConnectin käsikirjasivu kirjaa tämän valinnan dokumentoidulla 300 sekunnin oletusarvolla uudelleenyrityksille, jotka seuraavat kadonnutta linkkiä tai vastaamisen lopettanutta vertaista, ja luku on määräaika yhdelle käynnissä olevalle asiakkaalle, ei todiste siitä, että VPN pysyy tavoitettavissa. Se ei ole myöskään käytäntö prosessin pitämiseksi elossa, ja juuri siitä suurin osa sekaannuksesta alkaa.

Sekaannus kasvaa, kun päällä istuu toinen mekanismi. Asiakkaan uudelleenkäynnistävä valvoja, yhdyskäytävää pingaava testaaja ja sisäänrakennettu uudelleenyritysikkuna voivat kaikki reagoida yhteen vikaan, ja tapaus tuottaa silloin kolme aikajanaa, joita kukaan ei pysty sovittamaan.

Mitä uudelleenyhdistämisikkuna itse asiassa rajaa

Kuvittele, että liityntäverkko katoaa muutamaksi sekunniksi. Asiakas näkee linkin katkeavan tai lakkaa kuulemasta kuolleen vertaisen vastauksia ja alkaa palauttaa istuntoa pitäen yllä sen tilan, minkä pystyy. Yritykset jatkuvat, kunnes yhdyskäytävä hyväksyy jälleen tai ikkuna päättyy, ja päättynyt ikkuna päättyy nollasta poikkeavaan poistumiseen. Juuri tuo poistuminen, ei aikakatkaisun arvo, on kohta, jossa elinkaaren omistajuus siirtyy sille, joka valvoo prosessia.

Ikkuna ei kerro mitään siitä, kuinka usein testaaja ajetaan, eikä se voi jatkaa todennusta. Jos yhdyskäytävä on peruuttanut istunnon tai tili vaatii nyt uuden toisen tekijän, pidempi odottaminen ei tee vanhasta istunnosta jälleen kelvollista. Uudelleenyritys onnistuu vain, kun polku palaa, yhdyskäytävä tunnistaa istunnon edelleen ja pyydetyt kirjautumistiedot pysyvät käyttökelpoisina, joten lue luku määräaikana äläkä elossaolon aikavälinä.

Ikkuna ei myöskään säätele sitä, mitä sovellukset tekevät sen aikana. Alustasta ja vian etenemisestä riippuen asiakas voi yhdistää uudelleen, kun reitit ovat vielä asennettuina, tai sen jälkeen kun ne on poistettu. Siksi kesken katkoksen lähetetty pyyntö yleensä roikkuu aikakatkaisuun asti sen sijaan, että se epäonnistuisi nopeasti.

Valvojan uudelleenkäynnistykset ja asiakkaan uudelleenyritykset ovat kaksi kerrosta

Anna käynnissä olevan asiakkaan kuluttaa oma ikkunansa ja palvelunhallinnan reagoida poistumiseen. Etualalla systemd:n alla uudelleenkäynnistyskäytännöllä toimiva asiakas antaa juuri tuon jaon: yrityksiä rajatun ajan, sitten yksi uudelleenkäynnistyspäätös. Tuloksena on yksi aikajana, jonka voit vielä jälkikäteen rakentaa uudelleen.

Taustalla toimiva asiakas ja riippumaton kyselijä, joka käynnistää toisen kopion, kun se ei näe rajapintaa, on se malli, joka menee pieleen. Silloin molemmat prosessit kilpailevat samasta laitesolmusta, reiteistä ja resolverin asetuksista. Jos todella haluat taustapalvelun, laita valinta komentoriville, jolla asiakas todella käynnistyy:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Kahdella yksityiskohdalla tuossa rivissä on painoa. --background irrottaa prosessin, joten pid-tiedostosta tulee ainoa luotettava kahva siihen, ja aikakatkaisu kuluu vain niin kauan kuin sama prosessi elää; valvoja, joka tappaa sen, ei jätä budjettia jatkamiseen.

Tahallisesti katkaistut yhteydet tarvitsevat oman signaalinsa. Suunniteltu tauko ja todellinen katkos näyttävät naiiville tarkkailijalle samoilta, molemmat luetaan muotoon ”ei yhdistetty”. Ohjaa tauko valvojan pysäytystoiminnon tai kääreen ymmärtämän merkin kautta, jotta tahallinen pysäytys ei laukaise uudelleenkäynnistystä, jota kukaan ei pyytänyt.

Miten estetään luovutuksen kilpajuoksu uudelleenyrityssilmukan kanssa

Valvomaton palautuminen riippuu kirjautumistiedoista, jotka uusiutuvat ilman paikalla olevaa henkilöä. Avainnippu, joka avautuu vain vuorovaikutteisessa työpöytäistunnossa, tai token, joka vaatii aina kirjoitetun koodin, jättää asiakkaan jumiin todennusvaiheeseen, kun polku palaa. Selvitä tämä työnkulku ennen ikkunan pidentämistä, koska pidempi ikkuna antaa vain samalle estetylle kehotteelle enemmän aikaa epäonnistua.

Palvelimen vahvistusta ei pitäisi löysätä kehotteiden vähentämiseksi. Juuri yhdyskäytävän validoiva pin tai luottamuksen ankkuri tekee automaattisesta uudelleenyhdistämisestä turvallista, ja sen poistaminen käytöstä sertifikaattikysymyksen välttämiseksi vaihtaa näkyvän keskeytyksen näkymättömään. Pidä vahvistettu identiteetti ja korjaa sen sijaan kehote; asiakas, joka on valmis yhdistämään mihin tahansa yhdyskäytävään, on huonompi kuin se, joka pysähtyy ja odottaa.

Rajapinnan olemassaolo ei sekään ole terveyden merkki. Tunnelilaite voi olla olemassa, vaikka sen takana on kuollut istunto, ja käynnistysprosessi voi olla olemassa ilman tunnelia lainkaan. Mikään noista havainnoista ei kestä todellista pyyntöä. Terveyden on tultava siitä, mitä käyttäjä tarvitsee, kuten pyynnöstä, joka kulkee tunnelin läpi tunnettuun sisäiseen palveluun.

Mikä katkoksen aikana ja sen jälkeen vahvistetaan

Aja neljä tapahtumaa erillisinä testeinä: ikkunaa lyhyempi keskeytys, sitä pidempi katkos, todennusvirhe ja tahallinen pysäytys. Kunkin pitäisi päättyä erilaiseen, ennustettavaan tilaan, ja kahden ensimmäisen välinen raja on koko syy arvon valitsemiseen.

Pidä tarkistukset ulospäin suunnattuina, koska prosessitaulu todistaa yksinään hyvin vähän. Katso, että pid pysyy vakaana lyhyen katkoksen ajan, ja vahvista sitten, että se on poissa ja korvattu kerran pitkän jälkeen:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Vahvista lyhyen keskeytyksen aikana, että asiakas todella yritti uudelleen eikä poistunut aikaisin, ja että reitit ja resolverin merkinnät palasivat ilman kaksoiskappaleita. Pidemmän katkoksen osalta vahvista puhdas poistuminen ja täsmälleen yksi uudelleenkäynnistys sen jälkeen. Todennusvirheen osalta vahvista, että asiakas ei pyöri yhdyskäytävää vasten, joka jatkaa sen hylkäämistä. Lisää tarkistus, että pid palaa yhteen arvoon sen sijaan että kerääntyisi.

Tahallisen pysäytyksen osalta terveys-URL:n pitäisi pysyä tavoittamattomana ja prosessin alhaalla. Sulje sitten silmukka sovelluksen puolelta: saman pyynnön on epäonnistuttava, kun tunneli puuttuu, ja onnistuttava sen palattua, siltä lähdeosoitteelta, jota käytäntösi odottaa. Vihreä tunnelikuvake ei ole todiste, mutta suoritettu pyyntö on.