Kiom longe OpenConnect devas daŭre reprovi rompitan VPN-on?

--reconnect-timeout respondas unu mallarĝan demandon: post kiam la tunelo falas, kiom longe ĉi tiu klienta procezo daŭre provas antaŭ ol ĝi rezignas kaj eliras. La manlibra paĝo de OpenConnect registras tiun opcion kun dokumentita defaŭlto de 300 sekundoj por reprovoj kiuj sekvas perditan ligilon aŭ samtavolon kiu ĉesis respondi, kaj la nombro estas limdato por unu kuranta kliento, ne pruvo ke la VPN restas atingebla. Ĝi ankaŭ ne estas politiko por teni la procezon viva, kaj tie komenciĝas la plej granda parto de la konfuzo.

La konfuzo pliiĝas kiam dua mekanismo sidas supre. Prizorganto kiu restartigas la klienton, esplorilo kiu pings la enirejon, kaj la enkonstruita reprova fenestro ĉiuj povas reagi al unu fiasko, kaj la incidento tiam produktas tri templiniojn kiujn neniu povas akordigi.

Kion la rekonekta fenestro efektive limigas

Imagu ke la alira reto malaperas dum kelkaj sekundoj. La kliento vidas la ligilon fali, aŭ ĉesas aŭdi respondojn de la morta samtavolo, kaj komencas reestabli la sesion tenante tiom da stato kiom ĝi povas. La reprovoj daŭras ĝis la enirejo denove akceptas aŭ ĝis la fenestro elĉerpiĝas, kaj elĉerpita fenestro finiĝas per eliro kun ne-nula kodo. Tiu eliro, ne la tempolima valoro, estas kie la posedo de la vivociklo transiras al tiu, kiu prizorgas la procezon.

La fenestro diras nenion pri tio kiom ofte esploro kuras, kaj ĝi ne povas etendi aŭtentikigon. Se la enirejo nuligis la sesion, aŭ la konto nun postulas freŝan duan faktoron, pli da atendo ne igos la malnovan sesion denove valida. Reprovo sukcesas nur kiam la vojo revenas, la enirejo ankoraŭ rekonas la sesion, kaj la petataj akreditaĵoj restas uzeblaj, do legu la nombron kiel limdaton anstataŭ kiel vivecintervalecon.

La fenestro ankaŭ ne regas kion aplikaĵoj faras dum ĝi kuras. Depende de la platformo kaj de kiom malproksimen la fiasko iris, la kliento povas rekonektiĝi kun la itineroj ankoraŭ instalitaj, aŭ post ilia forigo. Tial peto elsendita meze de interrompo emas pendi ĝis ĝi tempolimas anstataŭ malsukcesi rapide.

Prizorgantaj restartoj kaj klientaj reprovoj estas du tavoloj

Lasu la kurantan klienton elspezi sian propran fenestron, kaj lasu la servomanaĝeron reagi al la eliro. Kliento en la malfono sub systemd kun restartpolitiko donas ĝuste tiun dividon: reprovoj dum limigita periodo, poste unu restarta decido. La rezulto estas unu templinio, kiun vi ankoraŭ povas rekonstrui poste.

Kliento en la fono plus sendependa enketilo kiu lanĉas alian kopion kiam ĝi ne vidas interfacon estas la ŝablono kiu misfunkcias. Tiam ambaŭ procezoj konkuris pri la sama aparata nodo, itineroj kaj solvila agordoj. Se vi vere volas demonon, metu la opcion sur la komandlinion per kiu la kliento efektive startas:

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

Du detaloj en tiu linio gravas. --background malligas la procezon, do la pid-dosiero fariĝas la sola fidinda tenilo sur ĝi, kaj la tempolimo elspeziĝas nur dum tiu sama procezo vivas; prizorganto kiu mortigas ĝin ne lasas buĝeton por daŭrigi.

Intencaj malkonektoj bezonas sian propran signalon. Planita paŭzo kaj reala interrompo aspektas identaj al naiva observanto, ambaŭ legiĝas kiel „ne konektita”. Direktu la paŭzon per la halta operacio de la prizorganto, aŭ per markilo kiun la envolvilo komprenas, por ke intenca halto ne ekigu restartigon kiun neniu petis.

Kiel malhelpi ke la transdono antaŭu la reprovan buklon

Senprizorga resaniĝo dependas de akreditaĵoj kiuj renoviĝas sen ĉeesta persono. Ŝlosilaro kiu malŝlosiĝas nur en interaga labortabla sesio, aŭ ĵetono kiu ĉiam postulas entajpitan kodon, lasos la klienton blokita ĉe la aŭtentikiga stadio unufoje kiam la vojo revenas. Solvu tiun laborfluon antaŭ ol longigi la fenestron, ĉar pli longa fenestro nur donas al la sama blokita invito pli da tempo por fiaski.

Servila kontrolo ne devus malstreĉiĝi por redukti invitojn. Ĝuste la pinglo aŭ la fida ankro kiu validigas la enirejon igas aŭtomatan rekonekton sekura, kaj malŝalti ĝin por eviti demandon pri atestilo interŝanĝas videblan interrompon kontraŭ nevidebla. Konservu la kontrolitan identecon kaj anstataŭe ripari la inviton; kliento preta konektiĝi al ajna enirejo estas pli malbona ol tiu, kiu haltas kaj atendas.

Ankaŭ la ĉeesto de interfaco ne estas saniga signalo. Tunela aparato povas ekzisti kun morta sesio malantaŭ ĝi, kaj lanĉa procezo povas ekzisti sen ia tunelo. Neniu el tiuj observoj rezistas realan peton. Sano devas veni de tio, kion la uzanto bezonas, ekzemple peto kiu trapasas la tunelon al konata interna servo.

Kion kontroli dum kaj post interrompo

Rulu kvar eventojn kiel apartajn testojn: interrompon pli mallongan ol la fenestro, interrompon pli longan ol ĝi, aŭtentikigan fiaskon kaj intencan halton. Ĉiu devus finiĝi en malsama, antaŭvidebla stato, kaj la limo inter la du unuaj estas la tuta kialo elekti valoron.

Tenu la kontrolojn direktitajn eksteren, ĉar la proceza tabelo mem pruvas tre malmulte. Observu ĉu la pid restas stabila tra la mallonga interrompo, poste konfirmu ke ĝi malaperis kaj anstataŭiĝis unufoje post la longa:

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)"

Dum la mallonga interrompo, konfirmu ke la kliento vere reprovis anstataŭ frue eliri, kaj ke itineroj kaj solvilaj rikordoj revenis sen duplikatoj. Por la pli longa interrompo, konfirmu puran eliron kaj ĝuste unu restartigon post ĝi. Por la aŭtentikiga fiasko, konfirmu ke la kliento ne turniĝas kontraŭ enirejo kiu daŭre rifuzos ĝin. Aldonu kontrolon ke la pid revenas al unu valoro anstataŭ amasiĝi.

Por la intenca halto, la saniga URL devus resti neatingebla kaj la procezo devus resti malsupre. Poste fermu la buklon de la aplikaĵa flanko: la sama peto devas fiaski dum la tunelo forestas kaj devas sukcesi post ĝia reveno, de la fontadreso kiun via politiko atendas. Verda tunela ikono ne estas pruvo, sed plenumita peto estas.