Så kör du OpenConnect i bakgrunden efter interaktiv inloggning

Du slutför MFA-frågan, tunneln kommer upp och stängningen av terminalen tar anslutningen med sig. Det är ett övervakningsproblem, inte ett autentiseringsproblem, och OpenConnect har redan brytaren som löser det. Lösningen är att låta klienten förgrena sig till bakgrunden när starten är klar, när den interaktiva delen verkligen är över. Här följer en rad kontroller: gå igenom dem i ordning och stanna vid den första som inte gäller för din gateway.

Bekräfta vad gatewayen kräver vid inloggning

Innan du skriver ett kommando, notera den autentiseringsväg som driftsättningen tvingar fram. Bara certifikat, lösenord plus token och en webbläsarrunda via en SAML-leverantör beter sig olika, och bakgrundsläget kan inte hoppa över någon av dem. Alternativet ändrar vad som händer efter starten, aldrig vad som händer under den.

Den frestande genvägen är att automatisera frågan. En wrapper som skriver ett fast svar när den känner igen en lösenordsfråga går sönder i samma stund som gatewayen begär en engångskod, och lämnar en autentiseringsuppgift i en fil som andra konton kan läsa. Om en person måste godkänna sessionen, håll personen i loopen.

Kör den första sessionen i förgrunden och läs utdata

Anslut normalt en gång och låt hela handskakningen skrivas ut. Notera protokollet som används, sökvägen till certifikatet eller token, tunneladressen som servern tilldelar och varje varning innan anslutningen accepteras. Den utskriften är din baslinje och det enda billiga sättet att senare skilja ett klientproblem från en gatewayändring. Spara den utanför terminalbufferten.

Upprepa sedan samma anrop med bakgrundsläge och en tillagd PID-fil, till exempel openconnect --background --pid-file /run/openconnect.pid vpn.example.net, och håll protokoll- och autentiseringsalternativen som gatewayen kräver på samma rad. OpenConnect-handboken beskriver alternativet som att fortsätta i bakgrunden efter att starten slutförts, och just därför måste den interaktiva fasen vara klar först.

Gör den körande processen hittbar och stoppbar

En PID-fil är bara bevis så länge den matchar en levande process. Lägg den i en mapp som tjänstekontot äger och jämför det registrerade numret med processtabellen innan du signalerar något. Omstarter och krascher lämnar filen kvar, och en inaktuell fil är det vanliga skälet till att ett stoppskript rapporterar framgång medan tunneln fortfarande är uppe. Behandla kontrollen som en del av stopprutinen, inte som ett valfritt steg.

Signalera den verifierade PID:en och bekräfta sedan att tunnelgränssnittet faktiskt är borta i stället för att lita på exitstatusen. Om klienten behöver förhöjda rättigheter för att konfigurera gränssnittet måste signalen komma från ett konto som får skicka den.

Stapla inte bakgrundsläget under en supervisor

systemd och liknande supervisrar förväntar sig att äga processen de startade, och därför förvirrar en klient som förgrenar sig bort dem. Supervisorn ser en startare avslutas medan den riktiga anslutningen lever vidare, så omstartslogik, statusrapportering och stopptidsgränser beskriver något som inte längre är sant. Skriv enheten i den stödda förgrundsuppsättningen och låt supervisorn göra daemonjobbet.

Håll --background för sessioner som en person startar och sedan går ifrån. Om kravet är en tunnel som finns innan någon loggar in saknas en godkänd icke-interaktiv identitet plus en plan för att förnya den, och ingen kommandoradsflagga ger någon av delarna. Att lägga flaggan till ett startskript ger en tunnel som misslyckas tyst vid den första utgångna autentiseringsuppgiften.

Behandla sessionscookien som en autentiseringsuppgift

OpenConnect dokumenterar en separat autentiseringsfas via --authenticate, och materialet kan lämnas tillbaka med --cookie-on-stdin. Det paret finns för integrationsarbete, och det det producerar är lika känsligt som lösenordet som skapade det.

Håll värdet utanför shellhistoriken, utanför loggar och utanför varje ärende du öppnar. Ett överlämningsskript måste också bevara den verifierade slutpunktsinformationen som klienten fick tillsammans med cookien; tappar du den kan en senare körning ansluta till en värd du aldrig autentiserade, vilket är värre än en anslutning som bara misslyckas.

Gå igenom listan innan du stänger terminalen

Fyra saker bör vara sanna: den interaktiva inloggningen slutfördes i förgrunden, PID-filen pekar på en process du verifierat, supervisorfrågan är avgjord åt ena eller andra hållet och cookien har en lagringsplan som inte är en vanlig textfil. När alla fyra håller är det säkert att lämna terminalen, och tunneln fortsätter att köra.

Om en av dem misslyckas, åtgärda den punkten innan du rör de andra, eftersom de återstående kontrollerna inte kan kompensera för det. Spara också förgrundsutskriften från första körningen: nästa gång tunneln faller utan varning är det den baslinjen som skiljer en ändring på gateway-sidan från en på klientsidan.