OpenVPN push-peer-info: märk klienter utan att ge åtkomst

Utplaceringsetiketter är det vanliga skälet till att människor tar till den här funktionen: varje anslutning ska bära något som en plats eller en roll, och servern ska läsa det utan att hitta på ett andra autentiseringsformat. Community-OpenVPN har redan mekanismen, och den är liten. Den jobbiga delen är förväntningarna. Att sätta en vanlig variabel i klientprofilen gör ingenting på servern, och ett värde som faktiskt kommer fram bevisar bara att klienten skickade det.

Det här är en runbook för den fungerande vägen, verifieringssteget som visar vad som faktiskt kom fram och återställningen som inte lämnar någon halvkonfigurerad hook efter sig. Inget här kräver ett nytt certifikat, en ny plugin eller en protokollutökning.

Sätt variabeln och aktivera vägen

Två rader gör jobbet i klientprofilen, och båda behövs. Utan den första finns inget att skicka; utan den andra erbjuder klienten ingen peer-information alls. Ordningen spelar ingen roll, och det är värt att veta eftersom de två raderna ofta hamnar i olika delar av en genererad profil. Det viktiga är att båda överlever allt som skriver om profilen innan klienten läser den.

setenv UV_DEPLOY field-support
push-peer-info

Prefixet UV_ är inte dekoration. En vanlig DEPLOY-variabel förblir lokal i klientprocessen och vidarebefordras aldrig, medan formen med prefix är det namnutrymme som protokollet reserverar för användardefinierade fält. Låt resten av den godkända profilen vara intakt och bekräfta före utrullningen att klientbygget du distribuerar stöder båda direktiven.

En praktisk kontroll hör hemma här och inte i slutet: se till att direktivet når klientbinären och inte slukas av ett omslag. En grafisk klient som genererar sin egen kommandorad, eller ett administrationsgränssnitt som laddar om en sparad profil, kan kasta rader som den inte känner igen. Om servern inte ser något är detta det första stället att titta på.

Läs fältet från en serverhook

På serversidan valideras mottagen peer-information och infogas i miljön för anslutningsarbetsflödet, och det är detta som gör den läsbar från en hook utan något protokollarbete från din sida. Servern behöver inte tolka kontrollkanalen eller lagra något åt dig; värdet finns helt enkelt där medan anslutningen upprättas. Ett minimalt client-connect-skript som registrerar etiketten bredvid det autentiserade namnet ser ut så här.

#!/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 variabeln via miljön i stället för att tolka loggen, och ge den alltid ett standardvärde. ${UV_DEPLOY:-unset} håller skriptet fungerande för klienter som aldrig skickar fältet, vilket är normaltillståndet under en gradvis utrullning. Häll inte hela miljön i en logg för att hitta namnet; den innehåller långt mer än etiketten, inklusive värden du inte tänkt bevara.

Kör skriptet för hand och det rapporterar unset för allt, eftersom ett manuellt skal inte bär anslutningsmiljön. Det är ingen bugg i skriptet och inget bevis för att fältet saknas. Testa det genom en faktisk anslutning, den enda kontext där variabeln finns.

Verifiera vad som faktiskt kom fram

Anslut en klient med etiketten och en utan, läs sedan filen. Paret är testet: den ena raden ska bära värdet och den andra standardvärdet, och båda ska namnge samma autentiserade identitet som du förväntar dig.

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

De kommentarsraderna är formen på utdata, inte en avskrift från din server; läs din egen fil. Om den andra klienten också visar ett värde är variabeln satt någon annanstans i miljön, och du läser en inaktuell inställning i stället för peer-fältet.

Kontrollera även serverloggen för anslutningen. Peer-information kan dyka upp där, vilket är praktiskt vid felsökning och ett skäl att hålla värdena tråkiga: inga namn på personer, inga biljettnummer, inget du inte vill att en loggläsare ska se.

Behandla etiketten som ett påstående, inte en identitet

Alla som kan redigera klientprofilen kan ändra etiketten, och att tunneln är autentiserad gör inte etiketten auktoritativ. Transporten skyddar värdet under vägen; den bestyrker inte påståendet. Auktoriseringen tillhör fortfarande den autentiserade identiteten och en inskrivningspost som servern äger, med etiketten jämförd mot den posten när det spelar roll.

Den skillnaden avgör var etiketten får användas. Bra användningar är att dirigera en session till rätt loggfil, välja en visningsgrupp i en instrumentpanel eller tagga en supportsession så att en människa hittar den senare. Dåliga användningar är att släppa in en enhet i ett subnät, välja en brandväggsprincip eller avgöra vilken kunds data sessionen får läsa.

Validera värdet innan det når en sökväg, en fråga eller ett skalkommando. En tillåtelselista med förväntade strängar räcker för en utplaceringsetikett, och den kostar ingenting. Sätt aldrig in en sträng från en peer i en skalkommandorad, och begränsa varje lagrad observation till sessionen och inte till en tunneladress som nästa klient återanvänder.

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

Rulla tillbaka det rent

Att ta bort funktionen är två borttagningar och en verifiering. Ta bort raderna setenv och push-peer-info från klientprofilen och ta sedan bort eller inaktivera hooken och dess loggmål på servern.

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

Anslut en klient igen efteråt och bekräfta att loggraden slutar visas. En hook som fortsätter att trigga efter profiländringen är oftast en andra profil som fortfarande är utplacerad på en testenhet, och det är billigare att hitta den nu än under en revision.

Det som återstår i slutet är en liten, avgränsad bit sessionsmetadata med dokumenterat ursprung: klienten påstår det, servern registrerar det, och ingenting i åtkomsten beror på det. Det är den användbara versionen av funktionen, och den behöver inga nya autentiseringsuppgifter för att komma dit.