OpenVPN push-peer-info: etikedi klientojn sen doni aliron

Dislokigaj etikedoj estas la kutima kialo, kial homoj sin turnas al ĉi tiu funkcio: ĉiu ligo portu ion kiel ejon aŭ rolon, kaj la servilo legu ĝin sen elpensi duan akreditilan formaton. La komunuma OpenVPN jam havas la mekanismon, kaj ĝi estas malgranda. La dolora parto estas la atendoj. Meti ordinaran variablon en la klientan profilon nenion faras ĉe la servilo, kaj valoro, kiu tamen alvenas, pruvas nur, ke la kliento sendis ĝin.

Ĉi tio estas manlibro por la funkcianta vojo, la kontrolpaŝo, kiu montras, kio vere alvenis, kaj la malfaro, kiu ne lasas duonagorditan hokon. Nenio ĉi tie bezonas novan atestilon, novan kromaĵon aŭ protokolan etendon.

Agordu la variablon kaj ebligu la vojon

Du linioj faras la laboron en la klienta profilo, kaj ambaŭ necesas. Sen la unua estas nenio sendebla; sen la dua la kliento tute ne proponas samtavolajn informojn. La ordo ne gravas, kaj tion indas scii, ĉar la du linioj ofte finiĝas en malsamaj partoj de generita profilo. Gravas, ke ambaŭ postvivu ĉion, kio reverkas la profilon antaŭ ol la kliento legas ĝin.

setenv UV_DEPLOY field-support
push-peer-info

La prefikso UV_ ne estas ornamo. Ordinara variablo DEPLOY restas loka en la klienta procezo kaj neniam estas transsendata, dum la formo kun prefikso estas la nomspaco, kiun la protokolo rezervas por uzantodifinitaj kampoj. Lasu la reston de la aprobita profilo netuŝita kaj antaŭ ol lanĉi konfirmu, ke la klienta konstruo, kiun vi dislokas, subtenas ambaŭ instrukciojn.

Unu praktika kontrolo apartenas ĉi tie, ne ĉe la fino: certiĝu, ke la instrukcio atingas la klientan binaran dosieron kaj ne estas englutata de ĉirkaŭaĵo. Grafika kliento, kiu mem generas sian komandlinion, aŭ administra interfaco, kiu reŝargas konservitan profilon, povas forĵeti liniojn, kiujn ĝi ne rekonas. Se la servilo vidas nenion, jen la unua loko por rigardi.

Legu la kampon el servila hoko

Ĉe la servila flanko, ricevitaj samtavolaj informoj estas validigitaj kaj enmetitaj en la medion de la liga laborfluo, kaj tio estas, kio igas ilin legeblaj el hoko sen iu ajn protokola laboro de vi. La servilo ne bezonas analizi la regan kanalon aŭ konservi ion por vi; la valoro simple ĉeestas, dum la ligo estas starigata. Minimuma skripto client-connect, kiu registras la etikedon apud la aŭtentigita nomo, aspektas tiel.

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

Legu la variablon tra la medio anstataŭ analizi la protokolon, kaj ĉiam donu al ĝi defaŭltan valoron. ${UV_DEPLOY:-unset} tenas la skripton funkcianta por klientoj, kiuj neniam sendas la kampon, kio estas la normala stato dum laŭgrada lanĉo. Ne elverŝu la tutan medion en protokolon por trovi la nomon; ĝi enhavas multe pli ol la etikedo, inkluzive valorojn, kiujn vi ne intencis konservi.

Lanĉu la skripton permane kaj ĝi raportos unset por ĉio, ĉar permana ŝelo ne portas la ligan medion. Tio ne estas cimo en la skripto kaj ne estas pruvo, ke la kampo mankas. Testu ĝin per reala ligo, kiu estas la sola kunteksto, en kiu la variablo ekzistas.

Kontrolu, kio vere alvenis

Ligu unu klienton kun la etikedo kaj unu sen ĝi, poste legu la dosieron. La paro estas la testo: unu linio portu la valoron kaj la alia la defaŭltan valoron, kaj ambaŭ nomu la saman aŭtentigitan identecon, kiun vi atendas.

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

Tiuj komentaj linioj estas la formo de la eligo, ne transskribo de via servilo; legu vian propran dosieron. Se ankaŭ la dua kliento montras valoron, la variablo estas agordita aliloke en la medio, kaj vi legas malnoviĝintan agordon anstataŭ la samtavolan kampon.

Kontrolu ankaŭ la servilan protokolon por la ligo. Samtavolaj informoj povas aperi tie, kio estas oportuna por sencimigo kaj kialo teni la valorojn enuaj: neniuj nomoj de homoj, neniuj biletnaj numeroj, nenio, kion vi ne ŝatus, ke leganto de la protokolo vidu.

Traktu la etikedon kiel aserton, ne kiel identecon

Ĉiu ajn, kiu povas redakti la klientan profilon, povas ŝanĝi la etikedon, kaj tio, ke la tunelo estas aŭtentigita, ne igas la etikedon aŭtoritata. La transporto protektas la valoron dumvoje; ĝi ne atestas la aserton. La rajtigo ankoraŭ apartenas al la aŭtentigita identeco kaj al aliĝa registro, kiun posedas la servilo, kaj la etikedo estas komparata kun tiu registro, kiam ĝi gravas.

Tiu distingo decidas, kie la etikedo rajtas esti uzata. Bonaj uzoj estas direkti sesion al la ĝusta protokola dosiero, elekti vidigan grupon en panelo, aŭ etikedi subtenan sesion, por ke homo povu trovi ĝin poste. Malbonaj uzoj estas enlasi aparaton en subreton, elekti fajroŝirman regulon, aŭ decidi, kies klientajn datumojn la sesio rajtas legi.

Validigu la valoron antaŭ ol ĝi atingas vojon, konsulton aŭ ŝelan komandon. Listo de permesitaj atendataj ĉenoj sufiĉas por dislokiga etikedo, kaj ĝi kostas nenion. Neniam enmetu ĉenon provizitan de samtavolo en ŝelan komandlinion, kaj limigu iun ajn konservitan observon al la sesio anstataŭ al tunela adreso, kiun la sekva kliento reuzos.

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

Malfaru ĝin pure

Forigi la funkcion estas du forigoj kaj unu kontrolo. Forigu la liniojn setenv kaj push-peer-info el la klienta profilo, poste forigu aŭ malŝaltu la hokon kaj ĝian protokolan celon ĉe la servilo.

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

Poste religu unu klienton kaj konfirmu, ke la protokola linio ĉesas aperi. Hoko, kiu daŭre ekfunkcias post la profila ŝanĝo, estas kutime dua profilo ankoraŭ dislokita en testa aparato, kaj trovi ĝin nun estas pli malmultekoste ol trovi ĝin dum revizio.

Tio, kio restas ĉe la fino, estas malgranda, limigita peco de sesiaj metadatumoj kun dokumentita origino: la kliento asertas ĝin, la servilo registras ĝin, kaj nenio pri aliro dependas de ĝi. Tio estas la utila versio de la funkcio, kaj ĝi bezonas neniun novan akreditilon por atingi tion.