OpenVPN push-peer-info: merk klientar utan å gi tilgang

Utrullingsmerke er den vanlege grunnen til at folk grip etter denne funksjonen: kvar tilkobling skal bera noko som ein stad eller ei rolle, og tenaren skal lesa det utan å finna opp eit nytt legitimasjonsformat. Felles-OpenVPN har alt mekanismen, og han er liten. Den delen som gjer vondt, er forventningane. Å setja ein vanleg variabel i klientprofilen gjer ingenting på tenaren, og ein verdi som faktisk kjem fram, beviser berre at klienten sende han.

Dette er ei køyrebok for den fungerande vegen, verifiseringstrinnet som viser kva som faktisk kom fram, og tilbakerullinga som ikkje lét etter seg ein halvkonfigurert krok. Ingenting her treng eit nytt sertifikat, ein ny plugin eller ei protokollutviding.

Set variabelen og aktiver vegen

To linjer gjer arbeidet i klientprofilen, og begge er nødvendige. Utan den første er det ingenting å senda; utan den andre tilbyr klienten ikkje jamaldarinformasjon i det heile. Rekkjefølgja spelar inga rolle, og det er greitt å vita fordi dei to linjene ofte hamnar i ulike delar av ein generert profil. Det viktige er at begge overlever alt som skriv om profilen før klienten les han.

setenv UV_DEPLOY field-support
push-peer-info

Prefikset UV_ er ikkje pynt. Ein vanleg DEPLOY-variabel blir verande lokal i klientprosessen og blir aldri send vidare, medan forma med prefiks er namnerommet protokollen reserverer for brukardefinerte felt. Lat resten av den godkjende profilen vera intakt, og stadfest at klientbygget du rullar ut støttar begge direktiva før du rullar det ut.

Éin praktisk sjekk høyrer heime her og ikkje på slutten: sørg for at direktivet når klientbinæren og ikkje blir slukt av ein wrapper. Ein grafisk klient som genererer si eiga kommandolinje, eller eit administrasjonsgrensesnitt som lastar inn ein lagra profil på nytt, kan kasta linjer han ikkje kjenner att. Viss tenaren ikkje ser noko, er dette den første staden å sjå.

Les feltet frå ein tenarkrok

På tenarsida blir motteken jamaldarinformasjon validert og sett inn i miljøet til tilkoblingsarbeidsflyten, og det er dette som gjer han lesbar frå ein krok utan noko protokollarbeid frå di side. Tenaren treng ikkje å parse kontrollkanalen eller lagra noko for deg; verdien er rett og slett til stades medan tilkoblinga blir sett opp. Eit minimalt client-connect-skript som registrerer merket ved sida av det autentiserte namnet, 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 staden for å parse loggen, og gi han alltid ein standardverdi. ${UV_DEPLOY:-unset} held skriptet fungerande for klientar som aldri sender feltet, noko som er normaltilstanden under ein trinnvis utrulling. Ikkje tøm heile miljøet i ein logg for å finna namnet; det inneheld langt meir enn merket, inkludert verdiar du ikkje hadde til hensikt å ta vare på.

Køyr skriptet manuelt, og det vil rapportera unset for alt, fordi eit manuelt skal ikkje ber tilkoblingsmiljøet. Det er ikkje ein feil i skriptet og ikkje bevis for at feltet manglar. Test det gjennom ei faktisk tilkobling, som er den einaste konteksten der variabelen finst.

Verifiser kva som faktisk kom fram

Koblast til éin klient med merket og éin utan, og les deretter fila. Paret er testen: den eine linja skal bera verdien og den andre standardverdien, og begge skal nemna den same autentiserte identiteten du forventar.

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

Dei kommentarlinjene er forma på utdataene, ikkje ein transkripsjon frå tenaren din; les di eiga fil. Viss den andre klienten òg viser ein verdi, er variabelen sett ein annan stad i miljøet, og du les ei utdatert innstilling i staden for jamaldarfeltet.

Sjekk òg tenarloggen for tilkoblinga. Jamaldarinformasjon kan dukka opp der, noko som er praktisk for feilsøking og ein grunn til å halda verdiane kjedelege: ingen namn på personar, ingen billettnummer, ingenting du ikkje vil at ein logglesar skal sjå.

Handsam merket som ein påstand, ikkje ein identitet

Alle som kan redigera klientprofilen, kan endra merket, og det at tunnelen er autentisert gjer ikkje merket autoritativt. Transporten vernar verdien undervegs; han attesterer ikkje påstanden. Autorisasjonen høyrer framleis til den autentiserte identiteten og ein innmeldingspost som tenaren eig, med merket samanlikna med den posten når det betyr noko.

Den skilnaden avgjer kvar merket kan brukast. God bruk er å ruta ei økt til rett loggfil, velja ei visingsgruppe i eit dashbord, eller merka ei støtteøkt slik at eit menneske finn ho seinare. Dårleg bruk er å sleppa ein eining inn i eit subnett, velja ein brannmurpolicy, eller avgjera kva kundedata økta kan lesa.

Valider verdien før han når ein sti, eit spørjing eller ein skalkommando. Ei tillatingsliste med forventa strengar er nok for eit utrullingsmerke, og det kostar ingenting. Set aldri inn ein streng frå ein jamaldring i ei skalkommandolinje, og avgrens kvar lagra observasjon til økta og ikkje til ein tunneladresse som neste klient vil bruka på nytt.

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

Rull det reint tilbake

Å fjerna funksjonen er to slettingar og éin verifisering. Fjern setenv- og push-peer-info-linjene frå klientprofilen, og fjern eller deaktiver deretter kroken og loggmålet hans på tenaren.

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

Koblast til éin klient igjen etterpå og stadfest at logglinja sluttar å visast. Ein krok som held fram med å fyra etter profilendringa, er vanlegvis ein annan profil som framleis er rulla ut på ein testeing, og det er billegare å finna han no enn under ein revisjon.

Det som står att til slutt, er eit lite, avgrensa stykke øktmetadata med dokumentert opphav: klienten påstår det, tenaren registrerer det, og ingenting med tilgang heng av det. Det er den nyttige versjonen av funksjonen, og han treng ingen nye legitimasjonar for å koma dit.