OpenVPN push-peer-info: etichetarea clienților fără a acorda acces

Etichetele de implementare sunt motivul obișnuit pentru care oamenii apelează la această funcție: fiecare conexiune ar trebui să poarte ceva ca un site sau un rol, iar serverul ar trebui să citească asta fără să inventeze un al doilea format de acreditări. OpenVPN comunitar are deja mecanismul, și este mic. Partea care doare sunt așteptările. Setarea unei variabile obișnuite în profilul clientului nu face nimic pe server, iar o valoare care totuși ajunge dovedește doar că clientul a trimis-o.

Acesta este un ghid pentru calea care funcționează, pasul de verificare care arată ce a ajuns cu adevărat și revenirea care nu lasă în urmă niciun hook pe jumătate configurat. Nimic de aici nu are nevoie de un certificat nou, un plugin nou sau o extensie de protocol.

Setați variabila și activați calea

Două linii fac treaba în profilul clientului, și ambele sunt necesare. Fără prima nu există nimic de trimis; fără a doua clientul nu oferă deloc informații despre peer. Ordinea nu contează, și merită să știți asta pentru că cele două linii ajung adesea în părți diferite ale unui profil generat. Important este ca ambele să supraviețuiască oricărei rescrieri a profilului înainte ca clientul să îl citească.

setenv UV_DEPLOY field-support
push-peer-info

Prefixul UV_ nu este decor. O variabilă DEPLOY obișnuită rămâne locală în procesul clientului și nu este niciodată transmisă mai departe, în timp ce forma cu prefix este spațiul de nume pe care protocolul îl rezervă pentru câmpurile definite de utilizator. Păstrați restul profilului aprobat intact și confirmați, înainte de implementare, că build-ul clientului pe care îl folosiți acceptă ambele directive.

O verificare practică își are locul aici, nu la final: asigurați-vă că directiva ajunge la binarul clientului și nu este înghițită de un wrapper. Un client grafic care își generează propria linie de comandă, sau o interfață de administrare care reîncarcă un profil salvat, poate arunca linii pe care nu le recunoaște. Dacă serverul nu vede nimic, acesta este primul loc unde trebuie privit.

Citiți câmpul dintr-un hook al serverului

Pe partea serverului, informațiile despre peer primite sunt validate și inserate în mediul fluxului de lucru al conexiunii, și exact asta le face lizibile dintr-un hook fără nicio muncă de protocol din partea dumneavoastră. Serverul nu trebuie să analizeze canalul de control sau să stocheze ceva pentru dumneavoastră; valoarea este pur și simplu prezentă în timp ce conexiunea este stabilită. Un script client-connect minim care înregistrează eticheta lângă numele autentificat arată astfel.

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

Citiți variabila prin mediu în loc să analizați jurnalul, și dați-i întotdeauna o valoare implicită. ${UV_DEPLOY:-unset} menține scriptul funcțional pentru clienții care nu trimit niciodată câmpul, ceea ce este starea normală în timpul unei implementări etapizate. Nu vărsați întregul mediu într-un jurnal pentru a găsi numele; conține mult mai mult decât eticheta, inclusiv valori pe care nu intenționați să le păstrați.

Rulați scriptul manual și va raporta unset pentru tot, pentru că un shell manual nu poartă mediul conexiunii. Nu este o eroare a scriptului și nu este dovada că lipsește câmpul. Testați-l printr-o conexiune reală, singurul context în care variabila există.

Verificați ce a ajuns cu adevărat

Conectați un client cu eticheta și unul fără, apoi citiți fișierul. Perechea este testul: o linie ar trebui să poarte valoarea și cealaltă valoarea implicită, iar ambele ar trebui să numească aceeași identitate autentificată pe care o așteptați.

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

Acele linii de comentariu sunt forma ieșirii, nu o transcriere de la serverul dumneavoastră; citiți propriul fișier. Dacă și al doilea client arată o valoare, variabila este setată în altă parte a mediului, iar dumneavoastră citiți o setare veche în locul câmpului de peer.

Verificați și jurnalul serverului pentru conexiune. Informațiile despre peer pot apărea acolo, ceea ce este comod pentru depanare și un motiv să păstrați valorile plictisitoare: fără nume de persoane, fără numere de tichet, nimic pe care nu ați vrea să îl vadă un cititor al jurnalului.

Tratați eticheta ca pe o afirmație, nu ca pe o identitate

Oricine poate edita profilul clientului poate schimba eticheta, iar faptul că tunelul este autentificat nu face eticheta autoritativă. Transportul protejează valoarea în tranzit; nu certifică afirmația. Autorizarea aparține în continuare identității autentificate și unei înregistrări de inscriere pe care serverul o deține, iar eticheta este comparată cu acea înregistrare atunci când contează.

Această distincție decide unde poate fi folosită eticheta. Utilizări bune sunt direcționarea unei sesiuni către fișierul de jurnal corect, alegerea unui grup de afișare într-un panou sau marcarea unei sesiuni de asistență pentru ca o persoană să o găsească mai târziu. Utilizări rele sunt admiterea unui dispozitiv într-o subrețea, selectarea unei politici de firewall sau deciderea datelor cărui client le poate citi sesiunea.

Validați valoarea înainte ca ea să ajungă la o cale, o interogare sau o comandă shell. O listă de permisiuni cu șiruri așteptate este suficientă pentru o etichetă de implementare și nu costă nimic. Nu interpolați niciodată un șir furnizat de peer într-o linie de comandă shell și limitați orice observație stocată la sesiune, nu la o adresă de tunel pe care următorul client o va reutiliza.

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

Reveniți curat

Eliminarea funcției înseamnă două ștergeri și o verificare. Eliminați liniile setenv și push-peer-info din profilul clientului, apoi eliminați sau dezactivați hook-ul și destinația lui de jurnal pe server.

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

Reconectați apoi un client și confirmați că linia din jurnal nu mai apare. Un hook care continuă să se declanșeze după schimbarea profilului este de obicei un al doilea profil încă implementat pe un dispozitiv de test, iar să îl găsiți acum costă mai puțin decât să îl găsiți în timpul unui audit.

Ce rămâne la final este o bucată mică și delimitată de metadate de sesiune cu origine documentată: clientul o afirmă, serverul o înregistrează, și nimic din acces nu depinde de ea. Aceasta este versiunea utilă a funcției și nu are nevoie de acreditări noi ca să ajungă acolo.