OpenVPN push-peer-info: merk kliënte sonder om toegang te gee

Ontplooiingetikette is die gewone rede waarom mense na hierdie funksie gryp: elke verbinding moet iets soos 'n werf of 'n rol dra, en die bediener moet dit lees sonder om 'n tweede geloofsbriefformaat te bedink. Gemeenskaps-OpenVPN het reeds die meganisme, en dit is klein. Die deel wat byt, is verwagtinge. Om 'n gewone veranderlike in die kliëntprofiel te stel, doen niks op die bediener nie, en 'n waarde wat wel aankom, bewys net dat die kliënt dit gestuur het.

Dit is 'n werkboek vir die werkende pad, die verifikasiestap wat wys wat werklik aangekom het, en die terugrol wat geen halfopgestelde haak agterlaat nie. Niks hier vereis 'n nuwe sertifikaat, 'n nuwe inprop of 'n protokoluitbreiding nie.

Stel die veranderlike en aktiveer die pad

Twee reëls doen die werk in die kliëntprofiel, en albei is nodig. Sonder die eerste is daar niks om te stuur nie; sonder die tweede bied die kliënt glad nie portuurinligting aan nie. Volgorde maak nie saak nie, wat werd is om te weet, want die twee reëls beland dikwels in verskillende dele van 'n gegenereerde profiel. Wat saak maak, is dat albei oorleef wat die profiel ook al herskryf voordat die kliënt dit lees.

setenv UV_DEPLOY field-support
push-peer-info

Die UV_-voorvoegsel is nie versiering nie. 'n Gewone DEPLOY-veranderlike bly plaaslik in die kliëntproses en word nooit aangestuur nie, terwyl die vorm met voorvoegsel die naamruimte is wat die protokol vir gebruikerbepaalde velde reserveer. Hou die res van die goedgekeurde profiel ongeskonde en bevestig dat die kliëntbou wat jy ontplooi albei opdragte ondersteun voordat jy dit uitrol.

Een praktiese kontrole hoort hier eerder as aan die einde: maak seker die opdrag bereik die kliëntprogram en word nie deur 'n wikkel ingesluk nie. 'n Grafiese kliënt wat sy eie opdraglyn genereer, of 'n bestuurskoppelvlak wat 'n gestoorde profiel herlaai, kan reëls laat val wat dit nie herken nie. As die bediener niks sien nie, is dit die eerste plek om te kyk.

Lees die veld uit 'n bedienerhaak

Aan die bedienerkant word ontvangde portuurinligting gevalideer en in die omgewing van die verbindingswerkvloei ingevoeg, en dit is wat dit leesbaar maak uit 'n haak sonder enige protokolwerk van jou kant. Die bediener hoef nie die beheerkanaal te ontleed of enigiets vir jou te stoor nie; die waarde is bloot teenwoordig terwyl die verbinding opgestel word. 'n Minimale client-connect-skrip wat die etiket langs die geauthentiseerde naam aanteken, lyk so.

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

Lees die veranderlike deur die omgewing eerder as om die log te ontleed, en gee dit altyd 'n verstekwaarde. ${UV_DEPLOY:-unset} hou die skrip werkend vir kliënte wat die veld nooit stuur nie, wat die normale toestand tydens 'n gefaseerde uitrol is. Moenie die hele omgewing in 'n log stort om die naam te vind nie; dit bevat veel meer as die etiket, insluitend waardes wat jy nie bedoel het om te bewaar nie.

Voer die skrip met die hand uit en dit sal unset vir alles rapporteer, want 'n handmatige skulp dra nie die verbindingsomgewing nie. Dit is nie 'n fout in die skrip nie en dit is nie bewys dat die veld ontbreek nie. Toets dit deur 'n werklike verbinding, wat die enigste konteks is waarin die veranderlike bestaan.

Verifieer wat werklik aangekom het

Verbind een kliënt met die etiket en een sonder, en lees dan die lêer. Die paar is die toets: een reël moet die waarde dra en die ander die verstek, en albei moet dieselfde geauthentiseerde identiteit noem wat jy verwag.

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

Daardie kommentaarreëls is die vorm van die uitset, nie 'n transkripsie van jou bediener nie; lees jou eie lêer. As die tweede kliënt ook 'n waarde wys, is die veranderlike elders in die omgewing gestel, en jy lees 'n verouderde instelling eerder as die portuurveld.

Kontroleer ook die bedienerlog vir die verbinding. Portuurinligting kan daar verskyn, wat gerieflik is vir ontfouting en 'n rede om die waardes vervelig te hou: geen name van mense nie, geen kaartjienommers nie, niks wat jy sou omgee as 'n logleser dit sien nie.

Behandel die etiket as 'n bewering, nie 'n identiteit nie

Enigeen wat die kliëntprofiel kan wysig, kan die etiket verander, en die feit dat die tonnel geauthentiseer is, maak nie die etiket gesaghebbend nie. Die vervoer beskerm die waarde onderweg; dit sertifiseer nie die bewering nie. Magtiging behoort steeds aan die geauthentiseerde identiteit en aan 'n inskrywingsrekord wat die bediener besit, met die etiket wat teen daardie rekord vergelyk word wanneer dit saak maak.

Daardie onderskeid bepaal waar die etiket gebruik mag word. Goeie gebruike is om 'n sessie na die regte loglêer te lei, om 'n vertoongroep in 'n paneelbord te kies, of om 'n ondersteuningsessie te merk sodat 'n mens dit later kan vind. Slegte gebruike is om 'n toestel tot 'n subnet toe te laat, om 'n vuurmuurbeleid te kies, of om te besluit watter kliënt se data die sessie mag lees.

Valideer die waarde voordat dit 'n pad, 'n navraag of 'n skulpbevel bereik. 'n Toelaatlys van verwagte stringe is genoeg vir 'n ontplooiingetiket, en dit kos niks. Moet nooit 'n string van 'n portuur in 'n skulpbevellyn invoeg nie, en beperk enige gestoorde waarneming tot die sessie eerder as tot 'n tonneladres wat die volgende kliënt sal hergebruik.

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

Rol dit skoon terug

Om die funksie te verwyder is twee skrappings en een verifikasie. Verwyder die setenv- en push-peer-info-reëls uit die kliëntprofiel, en verwyder of deaktiveer dan die haak en sy logteiken op die bediener.

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

Verbind daarna weer een kliënt en bevestig dat die logreël ophou verskyn. 'n Haak wat bly werk ná die profielverandering is gewoonlik 'n tweede profiel wat nog op 'n toestel ontplooi is, en om dit nou te vind is goedkoper as om dit tydens 'n oudit te vind.

Wat aan die einde oorbly, is 'n klein, begrensde stuk sessiemetadata waarvan die oorsprong gedokumenteer is: die kliënt beweer dit, die bediener teken dit aan, en niks oor toegang hang daarvan af nie. Dit is die nuttige weergawe van die funksie, en dit het geen nuwe geloofsbrief nodig om daar te kom nie.