OpenVPN push-peer-info: mærk klienter uden at give adgang

Udrulningstags er den sædvanlige grund til, at folk griber efter denne funktion: hver forbindelse skal bære noget som en lokation eller en rolle, og serveren skal læse det uden at opfinde et andet legitimationsformat. Fællesskabs-OpenVPN har allerede mekanismen, og den er lille. Den del, der gør ondt, er forventningerne. At sætte en almindelig variabel i klientprofilen gør ingenting på serveren, og en værdi, der faktisk ankommer, beviser kun, at klienten sendte den.

Dette er en kørebog for den fungerende vej, verifikationstrinnet der viser, hvad der reelt ankom, og tilbagerulningen, der ikke efterlader en halvkonfigureret hook. Intet her kræver et nyt certifikat, et nyt plugin eller en protokoludvidelse.

Sæt variablen, og aktivér vejen

To linjer gør arbejdet i klientprofilen, og begge er nødvendige. Uden den første er der intet at sende; uden den anden tilbyder klienten slet ikke peer-information. Rækkefølgen er ligegyldig, og det er værd at vide, fordi de to linjer ofte ender i forskellige dele af en genereret profil. Det vigtige er, at begge overlever alt, hvad der omskriver profilen, før klienten læser den.

setenv UV_DEPLOY field-support
push-peer-info

Præfikset UV_ er ikke pynt. En almindelig DEPLOY-variabel forbliver lokal for klientprocessen og videresendes aldrig, mens formen med præfiks er det navnerum, protokollen reserverer til brugerdefinerede felter. Behold resten af den godkendte profil intakt, og bekræft, at det klientbuild, du udruller, understøtter begge direktiver, før du ruller ud.

Én praktisk kontrol hører her og ikke til sidst: sørg for, at direktivet når klientbinæren og ikke sluges af en wrapper. En grafisk klient, der genererer sin egen kommandolinje, eller en administrationsgrænseflade, der genindlæser en gemt profil, kan smide linjer væk, den ikke genkender. Hvis serveren intet ser, er det det første sted at kigge.

Læs feltet fra en server-hook

På serversiden valideres modtaget peer-information og indsættes i miljøet for forbindelsesarbejdsgangen, og det er det, der gør den læsbar fra en hook uden noget protokolarbejde fra din side. Serveren behøver ikke at parse kontrolkanalen eller gemme noget for dig; værdien er simpelthen til stede, mens forbindelsen oprettes. Et minimalt client-connect-script, der registrerer tagget ved siden af det autentificerede navn, ser sådan ud.

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

Læs variablen gennem miljøet i stedet for at parse loggen, og giv den altid en standardværdi. ${UV_DEPLOY:-unset} holder scriptet kørende for klienter, der aldrig sender feltet, hvilket er normaltilstanden under en gradvis udrulning. Dump ikke hele miljøet i en log for at finde navnet; det indeholder langt mere end tagget, inklusive værdier, du ikke havde til hensigt at bevare.

Kør scriptet manuelt, og det vil rapportere unset for alt, fordi et manuelt shell ikke bærer forbindelsens miljø. Det er ikke en fejl i scriptet og ikke bevis for, at feltet mangler. Test det gennem en faktisk forbindelse, som er den eneste kontekst, hvor variablen findes.

Verificér, hvad der faktisk ankom

Forbind én klient med tagget og én uden, og læs derefter filen. Parret er testen: den ene linje skal bære værdien, og den anden skal bære standardværdien, og begge skal navngive den samme autentificerede identitet, som du forventer.

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

De kommentarlinjer er outputtets form, ikke en transskription fra din server; læs din egen fil. Hvis den anden klient også viser en værdi, er variablen sat et andet sted i miljøet, og du læser en forældet indstilling i stedet for peer-feltet.

Tjek også serverloggen for forbindelsen. Peer-information kan optræde der, hvilket er bekvemt til fejlfinding og en grund til at holde værdierne kedelige: ingen navne på personer, ingen billetnumre, intet du ville have noget imod, at en loglæser så.

Behandl tagget som en påstand, ikke en identitet

Enhver, der kan redigere klientprofilen, kan ændre tagget, og det, at tunnelen er autentificeret, gør ikke tagget autoritativt. Transporten beskytter værdien undervejs; den certificerer ikke påstanden. Autorisation tilhører stadig den autentificerede identitet og en tilmeldingsrekord, som serveren ejer, og tagget sammenlignes med den rekord, når det betyder noget.

Den sondring afgør, hvor tagget må bruges. Gode anvendelser er at rute en session til den rigtige logfil, vælge en visningsgruppe i et dashboard eller tagge en supportsession, så et menneske kan finde den senere. Dårlige anvendelser er at lukke en enhed ind i et subnet, vælge en firewallpolitik eller afgøre, hvilken kundes data sessionen må læse.

Valider værdien, før den når en sti, en forespørgsel eller en shellkommando. En tilladelsesliste med forventede strenge er nok til et udrulningstag, og det koster intet. Indsæt aldrig en streng fra en peer i en shellkommandolinje, og begræns enhver gemt observation til sessionen i stedet for til en tunneladresse, som den næste klient vil genbruge.

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

Rul det rent tilbage

At fjerne funktionen er to sletninger og én verifikation. Fjern setenv- og push-peer-info-linjerne fra klientprofilen, og fjern eller deaktiver derefter hooken og dens logmål på serveren.

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

Genopret forbindelsen til én klient bagefter, og bekræft, at loglinjen holder op med at optræde. En hook, der bliver ved med at fyre efter profilændringen, er normalt en anden profil, der stadig er udrullet til en testenhed, og det er billigere at finde den nu end under en revision.

Tilbage er en lille, afgrænset bid sessionmetadata med dokumenteret oprindelse: klienten påstår den, serveren registrerer den, og intet om adgang afhænger af den. Det er den nyttige version af funktionen, og den kræver ingen ny legitimation for at nå dertil.