Jūs pabeidzat MFA pieprasījumu, tunelis paceļas, un termināļa aizvēršana savienojumu aizrauj līdzi. Tā ir uzraudzības, nevis autentifikācijas problēma, un OpenConnect jau ir slēdzis, kas to atrisina. Risinājums ir ļaut klientam pēc palaišanas pabeigšanas atzaroties fonā, kad interaktīvā daļa patiešām beigusies. Tālāk ir pārbaužu secība: veiciet tās pēc kārtas un apstājieties pie pirmās, kas jūsu vārtejai neder.

Apstipriniet, ko vārteja pieprasa pieteikšanās laikā

Pirms rakstāt komandu, pierakstiet akreditācijas datu ceļu, ko uzspiež izvietojums. Tikai sertifikāts, parole plus marķieris, un pārlūka ceļojums caur SAML nodrošinātāju uzvedas atšķirīgi, un fona režīms nevar izlaist nevienu. Šī opcija maina to, kas notiek pēc palaišanas, nekad to, kas notiek tās laikā.

Kārdinošais risinājums ir automatizēt pieprasījumu. Ietvars, kas, atpazīstot paroles pieprasījumu, ieraksta fiksētu atbildi, salūzt mirklī, kad vārteja pieprasa vienreizēju kodu, un atstāj akreditācijas datus failā, ko var lasīt citi konti. Ja sesiju jāapstiprina cilvēkam, saglabājiet cilvēku procesā.

Palaidiet pirmo sesiju priekšplānā un izlasiet izvadi

Vienreiz piesakieties normāli un ļaujiet izdrukāt visu rokasspiedienu. Pierakstiet izmantoto protokolu, sertifikāta vai marķiera ceļu, servera piešķirto tuneļa adresi un katru brīdinājumu pirms savienojuma pieņemšanas. Šis ieraksts ir jūsu bāzes līnija un vienīgais lētais veids, kā vēlāk atšķirt klienta problēmu no vārtejas izmaiņām. Saglabājiet to ārpus termināļa bufera.

Pēc tam atkārtojiet to pašu izsaukumu ar fona režīmu un pievienotu PID failu, piemēram, openconnect --background --pid-file /run/openconnect.pid vpn.example.net, saglabājot vārtejas prasītās protokola un autentifikācijas opcijas tajā pašā rindā. OpenConnect rokasgrāmata šo opciju apraksta kā turpinājumu fonā pēc palaišanas pabeigšanas, un tieši tāpēc interaktīvajai fāzei jābeidzas pirmajai.

Padariet darbojošos procesu atrodamu un apturamu

PID fails ir pierādījums tikai tikmēr, kamēr tas atbilst dzīvam procesam. Ievietojiet to mapē, kas pieder pakalpojuma kontam, un pirms signāla sūtīšanas salīdziniet ierakstīto numuru ar procesu tabulu. Pārstartēšana un avārijas atstāj failu, un novecojis fails ir parastais iemesls, kāpēc apturēšanas skripts ziņo par panākumiem, kamēr tunelis vēl darbojas. Uzskatiet pārbaudi par apturēšanas procedūras daļu, nevis izvēles soli.

Nosūtiet signālu pārbaudītajam PID, pēc tam apstipriniet, ka tuneļa saskarne tiešām pazuda, nevis paļaujieties uz iziešanas statusu. Ja klientam saskarnes konfigurēšanai vajadzīgas paaugstinātas tiesības, signālam jānāk no konta, kuram atļauts to sūtīt.

Nekraujiet fona režīmu zem uzrauga

systemd un līdzīgi uzraugi gaida, ka tiem piederēs palaistais process, tāpēc atzarojies klients tos mulsina. Uzraugs redz startētāju izejam, kamēr īstais savienojums turpinās, tāpēc restartēšanas loģika, statusa atskaites un apturēšanas termiņi apraksta kaut ko, kas vairs nav taisnība. Rakstiet vienību atbalstītajā priekšplāna izkārtojumā un ļaujiet uzraugam veikt dēmona darbu.

--background atstājiet sesijām, kuras cilvēks sāk un pēc tam aiziet. Ja nepieciešams tunelis, kas pastāv pirms kāds pieteicas, trūkst apstiprinātas neinteraktīvas identitātes un tās atjaunošanas plāna, un neviens komandrindas karodziņš nedod nevienu. Karodziņa pievienošana palaišanas skriptam rada tuneli, kas klusi neizdodas pie pirmajiem beigušajiem akreditācijas datiem.

Uztveriet sesijas sīkfailu kā akreditācijas datus

OpenConnect dokumentē atsevišķu autentifikācijas fāzi ar --authenticate, un iegūto materiālu var atgriezt ar --cookie-on-stdin. Šis pāris ir integrācijas darbam, un tas, ko tas rada, ir tikpat jutīgs kā to radījusī parole.

Turiet vērtību ārpus čaulas vēstures, žurnāliem un jebkura atvērtā biļetes. Nododamajam skriptam jāsaglabā arī pārbaudītā galapunkta informācija, ko klients saņēma kopā ar sīkfailu; ja to pazaudēsiet, vēlāka palaišana var izveidot savienojumu ar resursdatoru, kuru nekad neesat autentificējis, un tas ir sliktāk nekā vienkārši neizdevies savienojums.

Iziet cauri sarakstam pirms termināļa aizvēršanas

Četrām lietām jābūt patiesām: interaktīvā pieteikšanās beidzās priekšplānā, PID fails norāda uz pārbaudītu procesu, uzrauga jautājums ir atrisināts vienā vai otrā virzienā, un sīkfailam ir uzglabāšanas plāns, kas nav vienkāršs teksta fails. Kad visi četri ir spēkā, aiziešana no termināļa ir droša, un tunelis turpina darboties.

Ja kāds no tiem neizdodas, izlabojiet šo punktu pirms pārējo aizskaršanas, jo atlikušās pārbaudes to nekompensēs. Saglabājiet arī pirmās palaišanas priekšplāna ierakstu: nākamreiz, kad tunelis bez brīdinājuma nokritīs, tieši šī bāzes līnija atdalīs vārtejas puses izmaiņas no klienta puses.

Saistītie raksti