Slik kjører du OpenConnect i bakgrunnen etter interaktiv innlogging

Du fullfører MFA-forespørselen, tunnelen kommer opp, og lukking av terminalen tar forbindelsen med seg. Dette er et overvåkingsproblem, ikke et autentiseringsproblem, og OpenConnect har allerede bryteren som løser det. Løsningen er å la klienten forgrene seg til bakgrunnen når oppstarten er ferdig, når den interaktive delen virkelig er over. Her følger en rekke kontroller: gå gjennom dem i rekkefølge og stopp ved den første som ikke gjelder for gatewayen din.

Bekreft hva gatewayen krever ved innlogging

Før du skriver en kommando, noter legitimasjonsveien utrullingen håndhever. Bare sertifikat, passord pluss token og en nettleserrunde via en SAML-leverandør oppfører seg ulikt, og bakgrunnsmodus kan ikke hoppe over noen av dem. Valget endrer hva som skjer etter oppstarten, aldri hva som skjer under den.

Den fristende snarveien er å automatisere forespørselen. En wrapper som skriver et fast svar når den kjenner igjen en passordforespørsel, bryter sammen i det øyeblikket gatewayen ber om en engangskode, og etterlater en legitimasjon i en fil andre kontoer kan lese. Hvis en person må godkjenne økten, hold personen i løkken.

Kjør den første økten i forgrunnen og les utdataene

Koble til normalt én gang og la hele håndtrykket skrives ut. Noter protokollen som brukes, sertifikat- eller tokenstien, tunneladressen serveren tildeler, og hver advarsel før tilkoblingen godtas. Den utskriften er utgangspunktet ditt og den eneste billige måten å skille et klientproblem fra en gatewayendring senere. Lagre den utenfor terminalbufferen.

Gjenta deretter samme kall med bakgrunnsmodus og en PID-fil lagt til, for eksempel openconnect --background --pid-file /run/openconnect.pid vpn.example.net, og hold protokoll- og autentiseringsvalgene gatewayen krever på samme linje. OpenConnect-håndboken beskriver valget som å fortsette i bakgrunnen etter at oppstarten er fullført, og nettopp derfor må den interaktive fasen være ferdig først.

Gjør den kjørende prosessen søkbar og stoppbar

En PID-fil er bare bevis så lenge den samsvarer med en levende prosess. Legg den i en mappe tjenestekontoen eier, og sammenlign det registrerte nummeret med prosesslisten før du signaliserer noe. Omstarter og krasj etterlater filen, og en utdatert fil er den vanlige grunnen til at et stoppskript rapporterer suksess mens tunnelen fortsatt er oppe. Behandle kontrollen som en del av stopprosedyren, ikke et valgfritt trinn.

Signaliser den verifiserte PID-en, og bekreft deretter at tunnelgrensesnittet faktisk er borte i stedet for å stole på exit-statusen. Hvis klienten trenger forhøyede rettigheter for å konfigurere grensesnittet, må signalet komme fra en konto som har lov til å sende det.

Ikke stable bakgrunnsmodus under en supervisor

systemd og lignende supervisere forventer å eie prosessen de startet, og derfor forvirrer en klient som forgrener seg bort dem. Supervisoren ser en starter avslutte mens den virkelige forbindelsen lever videre, så omstartlogikk, statusrapportering og stopptidsavbrudd beskriver noe som ikke lenger er sant. Skriv enheten i den støttede forgrunnsoppsettet og la supervisoren gjøre daemonjobben.

Hold --background tilbake for økter en person starter og deretter går fra. Hvis kravet er en tunnel som finnes før noen logger inn, mangler en godkjent ikke-interaktiv identitet pluss en plan for å fornye den, og ingen kommandolinjebryter gir noen av delene. Å legge bryteren til et oppstartsskript gir en tunnel som feiler stille ved den første utløpte legitimasjonen.

Behandle øktcookien som en legitimasjon

OpenConnect dokumenterer en egen autentiseringsfase via --authenticate, og materialet kan leveres tilbake med --cookie-on-stdin. Det paret finnes for integrasjonsarbeid, og det det produserer er like følsomt som passordet som laget det.

Hold verdien utenfor shell-historikken, utenfor logger og utenfor hver sak du åpner. Et overleveringsskript må også bevare den verifiserte endepunktinformasjonen klienten fikk sammen med cookien; mister du den, kan en senere kjøring koble til en vert du aldri autentiserte, noe som er verre enn en tilkobling som bare feiler.

Gå gjennom listen før du lukker terminalen

Fire ting bør være sanne: den interaktive innloggingen ble fullført i forgrunnen, PID-filen peker på en prosess du har verifisert, supervisorspørsmålet er avgjort den ene eller andre veien, og cookien har en lagringsplan som ikke er en vanlig tekstfil. Når alle fire holder, er det trygt å gå fra terminalen, og tunnelen fortsetter å kjøre.

Hvis en av dem feiler, fiks det punktet før du rører de andre, fordi de resterende kontrollene ikke kan kompensere for det. Ta også vare på forgrunnsutskriften fra første kjøring: neste gang tunnelen faller uten varsel, er den baselinen det som skiller en endring på gateway-siden fra en på klientsiden.