OpenVPN push-peer-info: Clients kennzeichnen, ohne Zugriff zu gewähren

Deployment-Tags sind der übliche Grund, warum Leute zu dieser Funktion greifen: Jede Verbindung soll etwas wie einen Standort oder eine Rolle tragen, und der Server soll es lesen, ohne ein zweites Credential-Format zu erfinden. Community-OpenVPN hat den Mechanismus bereits, und er ist klein. Der schmerzhafte Teil sind die Erwartungen. Eine gewöhnliche Variable im Clientprofil zu setzen, bewirkt auf dem Server nichts, und ein Wert, der tatsächlich ankommt, beweist nur, dass der Client ihn gesendet hat.

Dies ist ein Runbook für den funktionierenden Weg, den Verifikationsschritt, der zeigt, was wirklich ankam, und das Zurückrollen, das keinen halb konfigurierten Hook hinterlässt. Nichts hier braucht ein neues Zertifikat, ein neues Plugin oder eine Protokollerweiterung.

Variable setzen und den Weg aktivieren

Zwei Zeilen erledigen die Arbeit im Clientprofil, und beide sind erforderlich. Ohne die erste gibt es nichts zu senden; ohne die zweite bietet der Client gar keine Peer-Informationen an. Die Reihenfolge ist egal, was gut zu wissen ist, weil die beiden Zeilen oft an verschiedenen Stellen eines generierten Profils landen. Wichtig ist, dass beide überleben, was auch immer das Profil umschreibt, bevor der Client es liest.

setenv UV_DEPLOY field-support
push-peer-info

Das Präfix UV_ ist kein Schmuck. Eine einfache Variable DEPLOY bleibt lokal im Clientprozess und wird nie weitergeleitet, während die Form mit Präfix der Namensraum ist, den das Protokoll für benutzerdefinierte Felder reserviert. Lassen Sie den Rest des genehmigten Profils unangetastet und stellen Sie vor dem Ausrollen sicher, dass der Client-Build, den Sie einsetzen, beide Direktiven unterstützt.

Eine praktische Prüfung gehört hierher und nicht ans Ende: Stellen Sie sicher, dass die Direktive die Client-Binärdatei erreicht und nicht von einem Wrapper verschluckt wird. Ein grafischer Client, der seine eigene Kommandozeile erzeugt, oder eine Verwaltungsschnittstelle, die ein gespeichertes Profil neu lädt, kann Zeilen verwerfen, die sie nicht erkennt. Wenn der Server nichts sieht, ist dies die erste Stelle zum Nachsehen.

Das Feld aus einem Server-Hook lesen

Auf der Serverseite werden empfangene Peer-Informationen validiert und in die Umgebung des Verbindungs-Workflows eingefügt, und das macht sie ohne eigene Protokollarbeit aus einem Hook lesbar. Der Server muss den Steuerkanal nicht parsen oder etwas für Sie speichern; der Wert ist einfach während des Verbindungsaufbaus vorhanden. Ein minimales client-connect-Skript, das das Label neben dem authentifizierten Namen protokolliert, sieht so aus.

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

Lesen Sie die Variable über die Umgebung statt durch Parsen des Logs und geben Sie ihr immer einen Standardwert. ${UV_DEPLOY:-unset} hält das Skript für Clients funktionsfähig, die das Feld nie senden, was beim schrittweisen Rollout der Normalfall ist. Schütten Sie nicht die gesamte Umgebung in ein Log, um den Namen zu finden; sie enthält weit mehr als das Label, einschließlich Werten, die Sie nicht dauerhaft speichern wollten.

Führen Sie das Skript von Hand aus, meldet es unset für alles, weil eine manuelle Shell die Verbindungsumgebung nicht mitbringt. Das ist kein Fehler im Skript und kein Beweis, dass das Feld fehlt. Testen Sie es über eine tatsächliche Verbindung, den einzigen Kontext, in dem die Variable existiert.

Prüfen, was tatsächlich ankam

Verbinden Sie einen Client mit dem Label und einen ohne und lesen Sie dann die Datei. Das Paar ist der Test: Eine Zeile sollte den Wert tragen und die andere den Standardwert, und beide sollten dieselbe authentifizierte Identität nennen, die Sie erwarten.

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

Diese Kommentarzeilen sind die Form der Ausgabe, kein Transkript von Ihrem Server; lesen Sie Ihre eigene Datei. Zeigt auch der zweite Client einen Wert, ist die Variable anderswo in der Umgebung gesetzt, und Sie lesen eine veraltete Einstellung statt des Peer-Feldes.

Prüfen Sie auch das Server-Log für die Verbindung. Peer-Informationen können dort auftauchen, was beim Debuggen praktisch ist und ein Grund, die Werte langweilig zu halten: keine Namen von Personen, keine Ticketnummern, nichts, was Sie nicht in einem Log sehen möchten.

Das Label als Behauptung behandeln, nicht als Identität

Jeder, der das Clientprofil bearbeiten kann, kann das Tag ändern, und dass der Tunnel authentifiziert ist, macht das Tag nicht autoritativ. Der Transport schützt den Wert unterwegs; er beglaubigt die Behauptung nicht. Die Autorisierung gehört weiterhin zur authentifizierten Identität und zu einem Einschreibungsdatensatz, den der Server besitzt, wobei das Label bei Bedarf mit diesem Datensatz verglichen wird.

Diese Unterscheidung entscheidet, wo das Label verwendet werden darf. Gute Verwendungen sind das Leiten einer Sitzung in die richtige Logdatei, die Wahl einer Anzeigegruppe in einem Dashboard oder das Markieren einer Support-Sitzung, damit ein Mensch sie später findet. Schlechte Verwendungen sind das Zulassen eines Geräts in ein Subnetz, die Auswahl einer Firewall-Regel oder die Entscheidung, welche Kundendaten die Sitzung lesen darf.

Validieren Sie den Wert, bevor er einen Pfad, eine Abfrage oder einen Shell-Befehl erreicht. Eine Positivliste erwarteter Zeichenketten genügt für ein Deployment-Tag, und sie kostet nichts. Fügen Sie niemals eine vom Peer gelieferte Zeichenkette in eine Shell-Kommandozeile ein, und beschränken Sie jede gespeicherte Beobachtung auf die Sitzung statt auf eine Tunneladresse, die der nächste Client wiederverwendet.

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

Sauber zurückrollen

Die Funktion zu entfernen sind zwei Löschungen und eine Prüfung. Entfernen Sie die Zeilen setenv und push-peer-info aus dem Clientprofil und entfernen oder deaktivieren Sie dann den Hook und sein Logziel auf dem Server.

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

Verbinden Sie danach einen Client erneut und bestätigen Sie, dass die Logzeile nicht mehr erscheint. Ein Hook, der nach der Profiländerung weiter feuert, ist meist ein zweites Profil, das noch auf einem Testgerät ausgerollt ist, und es ist billiger, es jetzt zu finden, als während eines Audits.

Am Ende bleibt ein kleines, begrenztes Stück Sitzungsmetadaten mit dokumentierter Herkunft: Der Client behauptet es, der Server zeichnet es auf, und nichts am Zugriff hängt davon ab. Das ist die nützliche Version der Funktion, und sie braucht keine neuen Anmeldedaten, um dorthin zu kommen.