OpenVPN push-peer-info: clients labelen zonder toegang te geven

Implementatietags zijn de gebruikelijke reden waarom mensen naar deze functie grijpen: elke verbinding moet iets als een locatie of een rol dragen, en de server moet dat lezen zonder een tweede credentialformaat te verzinnen. Community-OpenVPN heeft het mechanisme al, en het is klein. Het pijnlijke deel zijn de verwachtingen. Een gewone variabele in het clientprofiel zetten doet niets op de server, en een waarde die wel aankomt bewijst alleen dat de client hem heeft verzonden.

Dit is een runbook voor het werkende pad, de verificatiestap die laat zien wat er echt aankwam, en het terugdraaien dat geen half geconfigureerde hook achterlaat. Niets hier vereist een nieuw certificaat, een nieuwe plugin of een protocoluitbreiding.

Stel de variabele in en activeer het pad

Twee regels doen het werk in het clientprofiel, en beide zijn nodig. Zonder de eerste is er niets te sturen; zonder de tweede biedt de client helemaal geen peer-informatie aan. De volgorde maakt niet uit, en dat is goed om te weten omdat de twee regels vaak in verschillende delen van een gegenereerd profiel terechtkomen. Belangrijk is dat beide overleven wat het profiel ook herschrijft voordat de client het leest.

setenv UV_DEPLOY field-support
push-peer-info

Het voorvoegsel UV_ is geen versiering. Een gewone DEPLOY-variabele blijft lokaal in het clientproces en wordt nooit doorgegeven, terwijl de vorm met voorvoegsel de naamruimte is die het protocol reserveert voor door de gebruiker gedefinieerde velden. Laat de rest van het goedgekeurde profiel intact en bevestig voordat je uitrolt dat de clientbuild die je implementeert beide richtlijnen ondersteunt.

Eén praktische controle hoort hier en niet aan het eind: zorg dat de richtlijn de clientbinary bereikt en niet door een wrapper wordt opgeslokt. Een grafische client die zijn eigen commandoregel genereert, of een beheerinterface die een opgeslagen profiel opnieuw laadt, kan regels weggooien die hij niet herkent. Als de server niets ziet, is dit de eerste plek om te kijken.

Lees het veld uit een serverhook

Aan de serverkant wordt ontvangen peer-informatie gevalideerd en in de omgeving van de verbindingsworkflow ingevoegd, en dat is wat het leesbaar maakt uit een hook zonder enig protocolwerk van jouw kant. De server hoeft het controlekanaal niet te parsen of iets voor je op te slaan; de waarde is er simpelweg terwijl de verbinding wordt opgezet. Een minimaal client-connect-script dat het label naast de geauthenticeerde naam vastlegt, ziet er zo uit.

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

Lees de variabele via de omgeving in plaats van het log te parsen, en geef hem altijd een standaardwaarde. ${UV_DEPLOY:-unset} houdt het script werkend voor clients die het veld nooit sturen, wat de normale toestand is tijdens een gefaseerde uitrol. Gooi niet de hele omgeving in een log om de naam te vinden; er staat veel meer in dan het label, inclusief waarden die je niet wilde bewaren.

Voer het script met de hand uit en het meldt unset voor alles, omdat een handmatige shell de verbindingsomgeving niet meedraagt. Dat is geen bug in het script en geen bewijs dat het veld ontbreekt. Test het via een echte verbinding, de enige context waarin de variabele bestaat.

Verifieer wat er echt aankwam

Verbind één client met het label en één zonder, en lees dan het bestand. Het paar is de test: de ene regel moet de waarde dragen en de andere de standaardwaarde, en beide moeten dezelfde geauthenticeerde identiteit noemen die je verwacht.

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

Die commentaarregels zijn de vorm van de uitvoer, geen transcript van je server; lees je eigen bestand. Als de tweede client ook een waarde toont, is de variabele elders in de omgeving gezet, en lees je een verouderde instelling in plaats van het peer-veld.

Controleer ook het serverlog voor de verbinding. Peer-informatie kan daar verschijnen, wat handig is voor debuggen en een reden om de waarden saai te houden: geen namen van mensen, geen ticketnummers, niets waarvan je niet wilt dat een loglezer het ziet.

Behandel het label als een bewering, niet als een identiteit

Iedereen die het clientprofiel kan bewerken, kan de tag wijzigen, en dat de tunnel geauthenticeerd is, maakt de tag niet gezaghebbend. Het transport beschermt de waarde onderweg; het certificeert de bewering niet. Autorisatie blijft toebehoren aan de geauthenticeerde identiteit en aan een inschrijvingsrecord dat de server bezit, waarbij het label met dat record wordt vergeleken wanneer het ertoe doet.

Dat onderscheid bepaalt waar het label mag worden gebruikt. Goede toepassingen zijn een sessie naar het juiste logbestand routeren, een weergavegroep in een dashboard kiezen, of een supportsessie taggen zodat een mens die later kan vinden. Slechte toepassingen zijn een apparaat tot een subnet toelaten, een firewallbeleid kiezen, of beslissen welke klantgegevens de sessie mag lezen.

Valideer de waarde voordat hij een pad, een query of een shellcommando bereikt. Een lijst met toegestane verwachte strings is genoeg voor een implementatietag, en het kost niets. Voeg nooit een door de peer geleverde string in een shellcommandoregel in, en beperk elke opgeslagen observatie tot de sessie en niet tot een tunneladres dat de volgende client opnieuw gebruikt.

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

Draai het schoon terug

De functie verwijderen is twee verwijderingen en één verificatie. Haal de regels setenv en push-peer-info uit het clientprofiel en verwijder of schakel daarna de hook en zijn logdoel op de server uit.

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

Verbind daarna weer één client en bevestig dat de logregel niet meer verschijnt. Een hook die na de profielwijziging blijft vuren, is meestal een tweede profiel dat nog op een testapparaat is uitgerold, en die nu vinden is goedkoper dan tijdens een audit.

Wat aan het eind overblijft, is een klein, begrensd stuk sessiemetadata met gedocumenteerde herkomst: de client beweert het, de server registreert het, en niets aan toegang hangt ervan af. Dat is de nuttige versie van de functie, en er is geen nieuwe credential nodig om daar te komen.