Kople RADIUS til OpenVPN: plugin eller skriptkrok?

Innstikket blir framleis tilrådd i trådar som er eldre enn dei noverande bygga, og på ein tenar som vart kompilert i går, feilar det ved lasting. Dette er ikkje ein konfigurasjonsfeil du kan rette med ein sti. Innstikket og skriptkroken løyser den same problema på ulike lag, og flyttinga frå den eine til den andre endrar kva som må installerast, kva som køyrer med tenarrettar, og kva ein mislukka innlogging faktisk fortel deg.

Myten: innstikket er den støtta vegen

Eit innstikk er eit delt objekt som blir lasta inn i OpenVPN-prosessen, så det må passe til grensesnittet som prosessen tilbyr. Bygga endrar seg, pakkinga endrar seg, og eit bibliotek kompilert for eit eldre grensesnitt nektar rett og slett å lastast. Ingenting i tenarkonfigurasjonen kan byggje bru over gapet, difor endar rådet «berre installer radiusplugin» med ein tenar som ikkje startar.

Skriptkroken står i staden utanfor prosessen. OpenVPN køyrer eit program, gjev det innloggingsdetaljane og les ein dom tilbake. Den fråkoplinga gjer at han overlever oppgraderingar, og ho gjer han òg til ditt ansvar på ein måte innstikket aldri var.

Ingen av tilnærmingane er tryggare av byggjemåte. Den eine køyrer framand kode inne i daemonen; den andre køyrer koden din ved sida av med innloggingsdetaljane i handa. Det rette spørsmålet er kva av desse to risika du faktisk kan drifte.

Kva innstikket batt saman

Innstikket hadde si eiga konfigurasjonsfil med RADIUS-vert, delt løyndom, tal på forsøk og tidsgrense, og tenarkonfigurasjonen viste til henne med éi line. Handteringa av innloggingsdetaljar vart verande i tenarprosessen, noko som tydde at passordet aldri kryssa ei prosessgrense administratoren måtte sikre.

Kostnaden var kopling. Kvar OpenVPN-oppgradering risikerte eit inkompatibelt grensesnitt, og kvar distribusjon som bygde pakken på nytt risikerte å lage eit bibliotek som ikkje lenger passar. Når det skjer, er feilen høg og umiddelbar, og det er den einaste nåda i designet.

Viss eit slikt innstikk framleis blir lasta på bygget ditt, kan det vere den mindre driftsflata. Stadfest grensesnittet det vart bygd for, hald det festa til bygget du testa, og handsam kvar oppgradering som ei endring som krev ein full innloggingstest, ikkje som ei rutinemessig pakkeoppdatering.

Kva skriptkroken faktisk stolar på

Kroken blir konfigurert med auth-user-pass-verify og ein leveringsmekanisme: miljøvariablar eller ei mellombels fil. I miljøforma krev OpenVPN script-security 3, det dokumenterte nivået som tillèt passordeksponering til skript. Det nivået er ei medviten svekking av standarden, og det bør handsamast som ei løyve med grunngjeving vedlagt.

Alt skriptet rører ved arvar den tilliten. Det må eigast av root, ikkje vere skrivbart for gruppe eller andre, visast til med ein absolutt sti, og vere fritt for kvar stad der ein ikkje-klarert verdi når eit skal. Set kvar variabel i hermeteikn, avvis uventa teikn, og bygg aldri ein kommando frå brukarnamnet som er oppgjeve. Eit skript som køyrer som root ved kvar innloggingsfreistnad er verd éin gjennomgang nettopp for dei fire eigenskapane.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Fil-leveringsforma unngår problemet med miljøarv og gjev innloggingsdetaljane til skriptet gjennom ei mellombels fil med avgrensa rettar. Viss klienten din støttar det, er det vanlegvis det betre standardvalet, sjølv om det legg til eitt objekt til som må ryddast ved feil.

Utgangskodar avgjer om du feilar ope

Utgangsstatusen til skriptet er dommen: null godtek, ikkje-null avviser. Mønsteret som skapar trøbbel er eit skal-skript som berre godtek når RADIUS-svaret inneheld eit bestemt godtakingsteikn og returnerer feil for alt anna, fordi det smeltar tre ulike hendingar saman til eitt svar. Feil passord, ein utilgjengeleg tenar og eit misdanna svar blir alle den same avvisinga.

Skil dei tilfella i skriptet sjølv om kroken berre kan returnere godta eller avvis. Logg backend-resultatet separat, varsle om tidsgrenser og transportfeil, og gjer det tydeleg i overvakinga når autentiseringa feilar fordi tenesta er nede og ikkje fordi brukarane skriv feil.

To vanar held resten fornuftig. Viss RADIUS er autoriteten, bør han vere den einaste staden eit passord blir kontrollert, fordi ein skuggetabell lagar to svar på same spørsmål, og det andre er ei åtaksflate ingen overvakar. Og hugs at kroken blir kalla på nytt ved kvar freistnad, så eit tregt skript med ein utolmodig klient blir ein forsterkar for passordgjetting med mindre du legg til forseinking eller ein policy på RADIUS-sida.

Kva du gjev opp når sertifikatet forsvinn

Mange utplasseringar av denne forma slår heilt av klient-sertifikatkontrollen, og lèt eit brukarnamn og eit passord vere heile kravet til klienten. Det som forsvinn med den innstillinga, er sertifikatbasert identitet. Kanalen blir verande kryptert, men det einaste som namngjev klienten, er RADIUS-dommen. Alt nedstraums som før bygde på eit sertifikatsubjekt, må no byggje på brukarnamnet.

Hald vernet av kontrollkanalen på plass slik at ein uautentisert motpart ikkje kan granske eller overfløyme handtrykket, og bruk username-as-common-name når konfigurasjonen per brukar avheng av det felles namnet. Styrte portar løyser dette ofte annleis, ved å avslutte sertifikatautentiseringa ved ein port som snakkar EAP-TLS med RADIUS, og i så fall gjeld ingen av desse tenardirektiva. Kopier modellen din eigen plattform dokumenterer, ikkje den frå eit nærliggjande produkt. Direktiva som betyr noko er ulike nok til at blanding av dei gjev ein konfigurasjon som blir parsa og deretter ikkje autentiserer nokon.