OpenVPN push-peer-info: merk klienter uten å gi tilgang

Distribusjonstagger er den vanlige grunnen til at folk griper etter denne funksjonen: hver tilkobling skal bære noe som et sted eller en rolle, og serveren skal lese det uten å finne opp et nytt legitimasjonsformat. Felleskaps-OpenVPN har allerede mekanismen, og den er liten. Den delen som gjør vondt, er forventningene. Å sette en vanlig variabel i klientprofilen gjør ingenting på serveren, og en verdi som faktisk kommer frem, beviser bare at klienten sendte den.

Dette er en kjørebok for den fungerende veien, verifiseringstrinnet som viser hva som faktisk kom frem, og tilbakerullingen som ikke etterlater en halvkonfigurert krok. Ingenting her trenger et nytt sertifikat, en ny plugin eller en protokollutvidelse.

Sett variabelen og aktiver veien

To linjer gjør arbeidet i klientprofilen, og begge er nødvendige. Uten den første er det ingenting å sende; uten den andre tilbyr klienten ikke peer-informasjon i det hele tatt. Rekkefølgen spiller ingen rolle, og det er greit å vite fordi de to linjene ofte havner i forskjellige deler av en generert profil. Det viktige er at begge overlever alt som skriver om profilen før klienten leser den.

setenv UV_DEPLOY field-support
push-peer-info

Prefikset UV_ er ikke pynt. En vanlig DEPLOY-variabel forblir lokal i klientprosessen og videresendes aldri, mens formen med prefiks er navnerommet protokollen reserverer for brukerdefinerte felt. La resten av den godkjente profilen være intakt, og bekreft at klientbyggingen du ruller ut støtter begge direktivene før du ruller den ut.

Én praktisk sjekk hører hjemme her og ikke på slutten: sørg for at direktivet når klientbinæren og ikke slukes av en wrapper. En grafisk klient som genererer sin egen kommandolinje, eller et administrasjonsgrensesnitt som laster inn en lagret profil på nytt, kan forkaste linjer den ikke kjenner igjen. Hvis serveren ikke ser noe, er dette det første stedet å se.

Les feltet fra en serverkrok

På serversiden valideres mottatt peer-informasjon og settes inn i miljøet til tilkoblingsarbeidsflyten, og det er dette som gjør den lesbar fra en krok uten noe protokollarbeid fra din side. Serveren trenger ikke å parse kontrollkanalen eller lagre noe for deg; verdien er rett og slett til stede mens tilkoblingen settes opp. Et minimalt client-connect-skript som registrerer taggen ved siden av det autentiserte navnet, ser slik ut.

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

Les variabelen gjennom miljøet i stedet for å parse loggen, og gi den alltid en standardverdi. ${UV_DEPLOY:-unset} holder skriptet fungerende for klienter som aldri sender feltet, noe som er normaltilstanden under en trinnvis utrulling. Ikke tøm hele miljøet i en logg for å finne navnet; det inneholder langt mer enn taggen, inkludert verdier du ikke hadde til hensikt å bevare.

Kjør skriptet manuelt, og det vil rapportere unset for alt, fordi et manuelt skall ikke bærer tilkoblingsmiljøet. Det er ikke en feil i skriptet og ikke bevis for at feltet mangler. Test det gjennom en faktisk tilkobling, som er den eneste konteksten der variabelen finnes.

Verifiser hva som faktisk kom frem

Koble til én klient med taggen og én uten, og les deretter filen. Paret er testen: den ene linjen skal bære verdien og den andre standardverdien, og begge skal navngi den samme autentiserte identiteten du forventer.

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

De kommentarlinjene er formen på utdataene, ikke en transkripsjon fra serveren din; les din egen fil. Hvis den andre klienten også viser en verdi, er variabelen satt et annet sted i miljøet, og du leser en utdatert innstilling i stedet for peer-feltet.

Sjekk også serverloggen for tilkoblingen. Peer-informasjon kan dukke opp der, noe som er praktisk for feilsøking og en grunn til å holde verdiene kjedelige: ingen navn på personer, ingen billetnumre, ingenting du ikke vil at en loggleser skal se.

Behandle taggen som en påstand, ikke en identitet

Alle som kan redigere klientprofilen, kan endre taggen, og det at tunnelen er autentisert gjør ikke taggen autoritativ. Transporten beskytter verdien underveis; den attesterer ikke påstanden. Autorisasjonen tilhører fortsatt den autentiserte identiteten og en innmeldingspost som serveren eier, med taggen sammenlignet med den posten når det betyr noe.

Den forskjellen avgjør hvor taggen kan brukes. Gode bruk er å rute en økt til riktig loggfil, velge en visningsgruppe i et dashbord, eller tagge en støtteøkt slik at et menneske finner den senere. Dårlig bruk er å slippe en enhet inn i et subnett, velge en brannmurpolicy, eller avgjøre hvilke kundedata økten kan lese.

Valider verdien før den når en sti, et spørring eller en skallkommando. En tillatelsesliste med forventede strenger er nok for en distribusjonstagg, og det koster ingenting. Sett aldri inn en streng fra en peer i en skallkommandolinje, og begrens enhver lagret observasjon til økten og ikke til en tunneladresse som neste klient vil gjenbruke.

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

Rull det rent tilbake

Å fjerne funksjonen er to slettinger og én verifisering. Fjern setenv- og push-peer-info-linjene fra klientprofilen, og fjern eller deaktiver deretter kroken og loggmålet dens på serveren.

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

Koble til én klient igjen etterpå og bekreft at logglinjen slutter å vises. En krok som fortsetter å fyre etter profilendringen, er vanligvis en annen profil som fortsatt er rullet ut på en testenhet, og det er billigere å finne den nå enn under en revisjon.

Det som gjenstår til slutt, er et lite, avgrenset stykke øktmetadata med dokumentert opprinnelse: klienten påstår det, serveren registrerer det, og ingenting med tilgang avhenger av det. Det er den nyttige versjonen av funksjonen, og den trenger ingen nye legitimasjoner for å komme dit.