Zenbat denbora jarraitu behar du OpenConnectek VPN etena berriro saiatzen?

--reconnect-timeout galdera estu bati erantzuten dio: tunela erori ondoren, zenbat denbora jarraitzen du bezero-prozesu honek saiatzen, amore eman eta irten aurretik. OpenConneten eskuliburu-orriak aukera hori erregistratzen du 300 segundoko balio lehenetsi dokumentatuarekin, lotura galdu edo erantzuteari utzi dion pare baten ondorengo saiakera berrietarako, eta zenbakia martxan dagoen bezero bakarrerako epea da, ez VPNa irisgarri jarraitzearen froga. Ez da prozesua bizirik mantentzeko politika bat ere, eta hortxe hasten da nahastearen zatirik handiena.

Nahastea areagotu egiten da bigarren mekanismo bat gainean jartzen denean. Bezeroa berrabiarazten duen gainbegiraleak, gateway-a pingatzen duen zundatzaileak eta txertatutako saiakera-berrien leihoak huts egite berari erantzun diezaiokete, eta gertakariak hiru denbora-lerro sortzen ditu orduan, inork adosten ez dituenak.

Zeri mugatzen dion benetan berrikonexio-leihoak

Imajinatu sarbide-sarea segundo batzuetan desagertzen dela. Bezeroak lotura erortzen ikusten du, edo pare hilaren erantzunak entzuteari uzten dio, eta saioa berrezartzen hasten da ahal duen egoerari eutsiz. Saiakerak jarraitzen dute gateway-ak berriro onartu arte edo leihoa agortu arte, eta agortutako leihoa zero ez den irteera batekin amaitzen da. Irteera hori da, ez denbora-muga, bizitza-zikloaren jabetza prozesua gainbegiratzen duenari pasatzen zaion tokia.

Leihoak ez du ezer esaten zunda zenbat aldiz exekutatzen den, eta ezin du autentifikazioa luzatu. Gateway-ak saioa baliogabetu badu, edo kontuak orain bigarren faktore berri bat eskatzen badu, itxarote gehiagok ez du saio zaharra berriro baliozkoa egingo. Saiakera berri batek arrakasta du bidea itzultzen denean, gateway-ak saioa oraindik ezagutzen duenean eta eskatzen dituen kredentzialak erabilgarri jarraitzen dutenean soilik, beraz, irakurri zenbakia epe gisa, ez bizitasun-tarte gisa.

Leihoak ez du arautzen aplikazioek berau irauten duen bitartean egiten dutena ere. Plataformaren eta hutsegiteak noraino iritsi den arabera, bezeroa bideak oraindik instalatuta daudela edo kendu ondoren berrikonekta daiteke. Horregatik, etenaren erdian egindako eskaera zintzilik egoten da denbora-muga agortu arte, azkar huts egin beharrean.

Gainbegiralearen berrabiarazteak eta bezeroaren saiakera berriak bi geruza dira

Utzi martxan dagoen bezeroari bere leihoa gastatzen, eta utzi zerbitzu-kudeatzaileari irteerari erantzuten. Lehen planoan dagoen bezero batek systemd-en berrabiarazte-politika batekin ematen du zehazki banaketa hori: saiakera berriak aldi mugatu batean, gero berrabiarazte-erabaki bakarra. Emaitza geroago berreraiki dezakezun denbora-lerro bakarra da.

Atzeko planoan dagoen bezero bat gehi interfaze bat ikusten ez duenean beste kopia bat abiarazten duen zundatzaile independente bat da gaizki ateratzen den eredua. Orduan bi prozesuek gailu-nodo beragatik, bideengatik eta resolver-en ezarpenengatik lehiatzen dute. Benetan daemon bat nahi baduzu, jarri aukera bezeroak benetan abiarazten duen komando-lerroan:

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

Lerro horretako bi xehetasek pisa dute. --background prozesua bereizten du, beraz pid fitxategia haren gaineko helduleku fidagarri bakarra bihurtzen da, eta denbora-muga prozesu hori bera bizi den bitartean bakarrik gastatzen da; hura hiltzen duen gainbegiraleak ez du jarraitzeko aurrekonturik uzten.

Askaturiko deskonexioek beren seinalea behar dute. Aurreikusitako pausa batek eta benetako eten batek berdinak dirudite behatzaile inozentziarentzat, biak «konektatu gabe» gisa irakurtzen dira. Bideratu pausa gainbegiralearen geldiarazte-eragiketaren edo wrapperrak ulertzen duen markatzaile baten bidez, nahita egindako geldialdiak inork eskatu gabeko berrabiaraztea eragin ez dezan.

Eskualdaketa saiakera-berrien begiztarekin lehiatzea eragotzi

Gainbegiratu gabeko berreskurapena inor gertu egon gabe berritzen diren kredentzialen mende dago. Sarbide-giltza interaktiboa den mahaigaineko saio baten barruan soilik irekitzen duen gako-sortak, edo beti idatzitako kodea behar duen token batek, autentifikazio-etaldean harrapatuta utziko dute bezeroa bidea itzultzen denean. Konpondu lan-fluxu hori leihoa luzatu aurretik, leiho luzeago batek oztopatutako galderei huts egiteko denbora gehiago ematen baitie soilik.

Zerbitzariaren egiaztapena ez litzateke laxatu behar galdetegiak gutxitzeko. Gateway-a baliozkotzen duen pin edo konfiantza-aingura da berrikonexio automatikoa seguru egiten duena, eta ziurtagiri-galdera bat saihesteko desgaitzeak eten ikusgai bat ikusezin baterako trukatzen du. Mantendu egiaztatutako identitatea eta konpondu galdera hori; edozein gateway-rekin konektatzeko prest dagoen bezero bat gelditzen eta itxaroten duen bat baino okerragoa da.

Interfazearen presentzia ere ez da osasun-seinale bat. Tunel-gailu bat egon daiteke atzean saio hil bat duela, eta abiarazte-prozesu bat egon daiteke tunelik gabe. Behaketa horietako batek ere ez du eskaera erreal bati eusten. Osasunak erabiltzaileak behar duenetik etorri behar du, hala nola tunela zeharkatuz barneko zerbitzu ezagun batera doan eskaera batetik.

Zer egiaztatu eten batean zehar eta ondoren

Exekutatu lau gertaera proba bereizi gisa: leihotik laburragoa den eten bat, hura baino luzeagoa den eten bat, autentifikazio-hutsegite bat eta nahita egindako geldialdi bat. Bakoitzak egoera desberdin eta aurreikusteko moduko batean amaitu behar du, eta lehen bien arteko muga da balio bat aukeratzeko arrazoi osoa.

Eduki egiaztapenak kanpora begira, prozesu-taulak bere horretan oso gutxi frogatzen baitu. Begiratu pid-ak egonkor jarraitzen duen eten laburrean zehar, eta gero egiaztatu desagertu eta behin ordezkatu dela luzearen ondoren:

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

Eten laburrean, egiaztatu bezeroak benetan berriro saiatu duela goiz irten beharrean, eta bideak eta resolver-en sarrerak bikoiztasunik gabe itzuli direla. Eten luzeagoan, egiaztatu irteera garbia eta zehazki berrabiarazte bat etorri zela ondoren. Autentifikazio-hutsegitean, egiaztatu bezeroa ez dela hari ukatzen jarraituko dion gateway baten aurka biratzen. Gehitu pid-a balio bakarrera itzultzen dela egiaztatzeko proba bat, pilatu beharrean.

Nahita egindako geldialdian, osasun-URLak irisgaitz jarraitu behar du eta prozesuak behera egon behar du. Gero itxi begizta aplikazioaren aldetik: eskaera berak huts egin behar du tunela falta den bitartean eta arrakasta izan behar du itzuli ondoren, zure politikoak espero duen iturburu-helbidetik. Tunel-ikono berde bat ez da froga, baina osatutako eskaera bat bada.