Korleis gjer OpenConnect ein informasjonskapsel om til ein tunnel?

OpenConnect bind to separate utvekslingar saman med éin kortlevd verdi: nettpålogginga og VPN-tunnelen. Den første utvekslinga er vanleg HTTPS: legitimasjon, ein SAML-rundtur eller eit token går til gatewayen, og svaret ber ein autentiseringskapsel. Den andre utvekslinga legg fram den kapselen for same gateway som prov på at nettfasa allereie har skjedd, og først då reiser tunnelen seg.

Under pålogginga vert ingenting forhandla om tunnelen. Det er den delen som er verdt å forstå, fordi dei fleste skriptfeil føreset at kapselen er eit passord som skal lagrast, eller ein nøkkel som vernar trafikken, medan han eigenleg er ein berarbillett for ei bestemd gatewayøkt.

Kva klienten og gatewayen utvekslar, i rekkjefølgje

Autentiseringsfasen ser ut som eit vanleg verna nettstad. OpenConnect sender legitimasjonen til brukaren, eller følgjer omdirigeringa til gatewayen til ein identitetsleverandør, og gatewayen svarar med eit dokument som byggjer inn autentiseringskapselen. I AnyConnect-protokollen reiser denne verdien i ein kapselheader på dei neste førespurnadene, vanlegvis under eit namn som webvpn, og handboka handsamar han som legitimasjonen som ber økta vidare.

Den andre fasen er ein CONNECT-førespurnad til VPN-endepunktet til gatewayen med kapselen vedlagd. Gatewayen kontrollerer han, tildeler ei adresse, og klienten startar CSTP over TLS, med DTLS som ein valfri raskare datastad når økta finst. Først på dette tidspunktet vert tunnelparameter, ruter, DNS-innstillingar og trafikknøklane til økta fastsette. Kapselen slapp klienten gjennom døra; han krypterte ingenting.

Denne rekkjefølgja forklarer kvifor openconnect --authenticate finst. Køyr han, og han utfører nettfasa, skriv ut ei lita blokk med skallvariablar som COOKIE, HOST, CONNECT_URL og FINGERPRINT, og avsluttar før nokon tunnel vert bygd. Eit innpakningsskript kan då starte den verkelege sambandet med desse verdiane, og det er nettopp oppdelinga ei hovudlaus eller tobehaldar-utrulling treng.

Kapselen er ein øktberar, ikkje ein nøkkel

Handsam verdien slik du ville handsama ein økt-ID i ein nettapplikasjon. Den som held han i levetida, kan be gatewayen om tunnelen som økta har rett til, så hemmeleghaldet er viktig. Men å kopiere han avdekkjer ikkje trafikk, fordi konfidensialiteten til tunnelen kjem frå TLS-handtrykket og dei avleidde nøklane, ikkje frå kapselstrengen.

Han er heller ikkje ei permanent løyve. Gatewayen og identitetsleverandøren avgjer kor lenge økta lever, og ein nettlesar som framleis viser ei pålogga side, seier ingenting om tunneløkta framleis er gyldig. Å kople til på nytt etter utløp tyder å gjenta nettfasa og lage ein fersk kapsel, og det er nettopp poenget med reautentisering, ikkje ein plage som skal konstruerast bort.

Ikkje handsam ein kapsel som ein universell erstatning for annan legitimasjon. Eit SAML-påstand, eit nettlesarpassord og ein kapsel gjeven ut av ein annan teneste er ulike objekt med ulike målgrupper, og å lime den eine inn i feltet til den andre mislukkast vanlegvis ved gatewayen eller, verre, lukkast mot feil tillitsgrense.

Å levere kapselen utan å etterlate kopiar

Den tryggaste mekaniske overleveringa på Linux er standardinndata. --cookie-on-stdin les verdien frå stdin, så kapselen vert aldri synleg i argumentlista til prosessen, der kvar lokal brukar kan lese han med ps. Ein pipeline som autentiserer i éin prosess og matar tunnelen i ein annan, held verdien i eit røyr i staden for i ei fil eller ein miljøvariabel.

Argument og miljøvariablar er svakare av ulike grunnar. Eit argument er synleg i prosesstabellen gjennom heile levetida til klienten og hamnar ofte i skallhistoria. Ein miljøvariabel vert arva av barneprosessar, og ei systemd-eining som set han i einingafila, lagrar hemmelegheita i ein lesbar konfigurasjon. Viss ei fil er naudsynt, avgrens ho til tenestekontoen og fjern ho når økta sluttar.

Hald òg privilegiegrensa medviten. Prosessen som snakkar med identitetsleverandøren og kanskje opnar ein nettlesar, bør køyre som brukaren som eig den pålogginga. Prosessen som konfigurerer ruter, DNS og tunneleininga, kan trenge meir privilegium. Å køyre heile nettlesaren som root for at kapselen skal vere tilgjengeleg for ein tunnel som root eig, er den gale bytehandelen, og moderne OpenConnect-oppsett kan overlevere verdien over den grensa eksplisitt.

Logging fortener same mistanke. Detaljert klientutdata, hjelpeskript og gatewaydiagnostikk kan alle gjenta førespurnadsmateriale, og ikkje alle loggnivå maskerer kapselen. Fang den minste feilposten du treng, hald han utanfor delte kanalar, og sjekk eit maskert døme før du legg han ved ei sak.

Stadfesting og utløp i den andre fasen

Den andre fasen må framleis stadfeste tenaren. Den FINGERPRINT som --authenticate skriv ut, er ein sertifikatpinne i forma pin-sha256:, og å gje han til tunnelkallet med --servercert held kontrollen forankra i gatewayen du autentiserte deg mot. Å slå av sertifikatkontrollen for å gjere eit skript enklare fjernar det einaste provet på at kapselen vert levert til den tiltenkte verten.

Når gatewayen avviser kapselen, er løysinga ein ny autentiseringsrunde, ikkje ein lengre hurtigbuffer. Lagre kapselen berre så lenge sambandet varer, slett mellombelse filer ved avslutting, og bruk prosessen til identitetsleverandøren eller gatewayen for fjerning av økt når ei økt vert avdekt eller eining mistast. Ein bufra kapsel er ikkje fritaking frå MFA.

Før du automatiserer dette, stadfest fire ting: tunnelen køyrer under rett konto, kapselen kjem inn via stdin, fingeravtrykket til sertifikatet er pinna, og økta vert forkasta når tunnelen vert stengd. Viss noko av dette manglar, har automatiseringa utvida tillita til kapselen i staden for å gjenskape den manuelle flyten.