OpenVPN push-peer-info: lagyan ng label ang mga kliyente nang hindi nagbibigay ng access

Ang mga deployment tag ang karaniwang dahilan kung bakit lumalapit ang mga tao sa feature na ito: dapat may dalang isang bagay tulad ng site o role ang bawat koneksyon, at dapat itong basahin ng server nang hindi gumagawa ng pangalawang format ng kredensyal. Mayroon na ang community OpenVPN ng mekanismong ito, at maliit ito. Ang masakit na bahagi ay ang mga inaasahan. Ang pagtatakda ng ordinaryong variable sa profile ng kliyente ay walang ginagawa sa server, at ang halagang dumarating ay nagpapatunay lamang na ipinadala ito ng kliyente.

Ito ay isang runbook para sa gumaganang landas, sa hakbang ng pag-verify na nagpapakita kung ano ang tunay na dumating, at sa rollback na hindi nag-iiwan ng kalahating naka-configure na hook. Wala ring kailangan dito na bagong sertipiko, bagong plugin o extension ng protocol.

Itakda ang variable at paganahin ang landas

Dalawang linya ang gumagawa ng trabaho sa profile ng kliyente, at kailangan ang dalawa. Kung wala ang una, walang ipapadala; kung wala ang pangalawa, hindi nag-aalok ng peer information ang kliyente. Walang kinalaman ang pagkakasunod-sunod, at mabuting malaman ito dahil madalas mapunta ang dalawang linya sa magkaibang bahagi ng isang generated na profile. Ang mahalaga ay mabuhay ang dalawa sa anumang muling pagsulat ng profile bago ito basahin ng kliyente.

setenv UV_DEPLOY field-support
push-peer-info

Ang prefix na UV_ ay hindi palamuti. Ang ordinaryong variable na DEPLOY ay nananatiling lokal sa proseso ng kliyente at hindi kailanman ipinapasa, samantalang ang anyong may prefix ay ang namespace na inilalaan ng protocol para sa mga field na tinukoy ng user. Iwanang buo ang natitirang bahagi ng aprubadong profile at tiyakin bago ang deployment na sinusuportahan ng client build na ide-deploy mo ang dalawang direktiba.

Isang praktikal na pagsusuri ang nababagay dito, hindi sa dulo: tiyakin na naaabot ng direktiba ang binary ng kliyente at hindi ito nilalamon ng wrapper. Ang graphical na kliyenteng gumagawa ng sarili nitong command line, o ang management interface na nagre-reload ng naka-save na profile, ay maaaring magtapon ng mga linyang hindi nito nakikilala. Kung wala itong nakikita ang server, ito ang unang lugar na dapat tingnan.

Basahin ang field mula sa hook ng server

Sa panig ng server, ang natanggap na peer information ay vine-validate at ipinapasok sa environment ng workflow ng koneksyon, at iyon ang dahilan kung bakit ito nababasa mula sa hook nang walang anumang gawaing protocol mula sa iyo. Hindi kailangang i-parse ng server ang control channel o mag-imbak ng anuman para sa iyo; naroon lang ang halaga habang itinatag ang koneksyon. Ang isang minimal na script na client-connect na nagtatala ng label sa tabi ng authenticated na pangalan ay ganito ang hitsura.

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

Basahin ang variable sa pamamagitan ng environment sa halip na i-parse ang log, at bigyan ito ng default na halaga. Pinapanatili ng ${UV_DEPLOY:-unset} na gumagana ang script para sa mga kliyenteng hindi kailanman nagpapadala ng field, na siyang normal na kalagayan sa isang unti-unting deployment. Huwag ibuhos ang buong environment sa log para hanapin ang pangalan; marami pang laman ito kaysa sa label, kabilang ang mga halagang hindi mo sinadyang itago.

Patakbuhin ang script nang manu-mano at mag-uulat ito ng unset para sa lahat, dahil hindi dinadala ng manu-manong shell ang environment ng koneksyon. Hindi ito bug sa script at hindi ito patunay na nawawala ang field. Subukan ito sa pamamagitan ng tunay na koneksyon, ang tanging konteksto kung saan umiiral ang variable.

I-verify kung ano ang tunay na dumating

Ikonekta ang isang kliyente na may label at isa na wala, pagkatapos basahin ang file. Ang pares ang pagsubok: dapat may dalang halaga ang isang linya at default ang isa, at dapat pangalanan ng dalawa ang parehong authenticated na pagkakakilanlan na inaasahan mo.

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

Ang mga linya ng komento ay anyo ng output, hindi transcript mula sa iyong server; basahin ang sarili mong file. Kung nagpapakita rin ng halaga ang pangalawang kliyente, itinakda ang variable sa ibang lugar sa environment, at binabasa mo ang lumang setting sa halip na ang peer field.

Tingnan din ang log ng server para sa koneksyon. Maaaring lumitaw doon ang peer information, na maginhawa para sa pag-debug at dahilan para panatilihing boring ang mga halaga: walang pangalan ng tao, walang numero ng ticket, walang anumang ayaw mong makita ng bumabasa ng log.

Ituring ang label bilang assertion, hindi pagkakakilanlan

Sinuman ang makapag-edit ng profile ng kliyente ay makapagbabago ng tag, at ang pagiging authenticated ng tunnel ay hindi nagpapaging awtoridad ng tag. Pinoprotektahan ng transport ang halaga habang nasa daan; hindi nito pinatunayan ang assertion. Ang awtorisasyon ay pag-aari pa rin ng authenticated na pagkakakilanlan at ng enrollment record na pagmamay-ari ng server, at ihinahambing ang label sa record na iyon kapag mahalaga ito.

Ang pagkakaibang iyon ang nagtatakda kung saan maaaring gamitin ang label. Mabubuting gamit ang pag-ruta ng session sa tamang log file, pagpili ng display group sa dashboard, o paglagay ng label sa support session upang mahanap ito ng tao mamaya. Masasamang gamit ang pagpapatanggap ng device sa subnet, pagpili ng firewall policy, o pagpapasya kung aling data ng customer ang mababasa ng session.

I-validate ang halaga bago ito umabot sa path, query o shell command. Ang allowlist ng inaasahang string ay sapat para sa deployment tag, at wala itong gastos. Huwag kailanman isingit ang string na ibinigay ng peer sa shell command line, at limitahan ang anumang naka-imbak na obserbasyon sa session at hindi sa isang tunnel address na muling gagamitin ng susunod na kliyente.

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

I-roll back nang malinis

Ang pag-alis ng feature ay dalawang pagbura at isang pag-verify. Alisin ang mga linyang setenv at push-peer-info sa profile ng kliyente, pagkatapos ay alisin o huwag paganahin ang hook at ang log target nito sa server.

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

Ikonekta muli ang isang kliyente pagkatapos at kumpirmahing tumigil ang paglitaw ng linya sa log. Ang hook na patuloy na umiiral pagkatapos ng pagbabago ng profile ay karaniwang pangalawang profile na naka-deploy pa rin sa test device, at mas mura itong hanapin ngayon kaysa sa panahon ng audit.

Ang natitira sa dulo ay isang maliit at limitadong piraso ng session metadata na may dokumentadong pinagmulan: inaangkin ito ng kliyente, itinatala ito ng server, at wala sa access ang nakasalalay dito. Ito ang kapaki-pakinabang na bersyon ng feature, at hindi ito nangangailangan ng bagong kredensyal upang makarating doon.