OpenVPN push-peer-info: kliïnten labelje sûnder tagong te jaan
In UV_-fjild reizget mei troch de autentisearre tunnel, mar de wearde bliuwt in bewearing fan 'e kliïnt. Stel it yn, ferifiearje wat oankaam en hâld autorisaasje oan 'e serverkant.
Utrolabels binne de gewoane reden dat minsken nei dizze funksje gripe: elke ferbining moat eat as in lokaasje as in rol drage, en de server moat it lêze sûnder in twadde formaat foar legitimaaasjes te betinken. Mienskiplike OpenVPN hat it meganisme al, en it is lyts. It diel dat sear docht, binne de ferwachtings. In gewoane fariabele yn it kliïntprofyl sette docht neat op 'e server, en in wearde dy't wol oankomt, bewissiget allinnich dat de kliïnt dy stjoerd hat.
Dit is in hânboek foar it wurkjende paad, de ferifikaasjestap dy't sjen lit wat echt oankaam, en it weromdraaien dat gjin heal konfigurearre heak efterlit. Neat hjir hat in nij sertifikaat, in nije ynstekker of in protokoli-útwreiding nedich.
Stel de fariabele yn en aktivearje it paad
Twa rigels dogge it wurk yn it kliïntprofyl, en beide binne nedich. Sûnder de earste is der neat te stjoeren; sûnder de twadde biedt de kliïnt hielendal gjin peer-ynformaasje oan. De folchoarder makket neat út, en dat is goed om te witten, want de twa rigels bedarje faak yn ferskillende dielen fan in generearre profyl. Wat útmakket, is dat beide oerlibje wat it profyl ek weromskriuwt foardat de kliïnt it lêst.
setenv UV_DEPLOY field-support
push-peer-info
It foarheaksel UV_ is gjin fersiering. In gewoane fariabele DEPLOY bliuwt lokaal yn it kliïntproses en wurdt nea trochjûn, wylst de foarm mei foarheaksel de nammeromte is dy't it protokol reservearret foar brûkersdefiniearre fjilden. Hâld de rest fan it goedkarde profyl yntakt en befêstigje foardat jo útrole dat de kliïntbou dy't jo útbringe beide rjochtlinen stipet.
Ien praktyske kontrôle heart hjir en net oan 'e ein: soargje derfoar dat de rjochtline de kliïntbinêre berikt en net troch in wrapper opslokt wurdt. In grafyske kliïnt dy't syn eigen kommandorigel generearret, of in behearinterface dy't in bewarre profyl op 'e nij lâdt, kin rigels dy't it net ken, weilitte. As de server neat sjocht, is dit it earste plak om te sjen.
Lês it fjild út in serverheak
Oan 'e serverkant wurde ûntfongen peer-ynformaasje falidearre en yn 'e omjouwing fan 'e ferbiningwurkstream ynfoege, en dat is wat it lêsber makket út in heak sûnder eigen protokolwurk. De server hoecht it kontrôlekanaal net te parsearjen of eat foar jo te bewarjen; de wearde is gewoan oanwêzich wylst de ferbining opboud wurdt. In minimaal skript client-connect dat it label neist de autentisearre namme fêstleit, sjocht der sa út.
#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
>> /var/log/openvpn/deploy-labels.log
Lês de fariabele fia de omjouwing yn stee fan it log te parsearjen, en jou it altyd in standertwearde. ${UV_DEPLOY:-unset} hâldt it skript wurkjend foar kliïnten dy't it fjild nea stjoere, wat de normale tastân is by in stadige útrol. Smyt net de hiele omjouwing yn in log om de namme te finen; it befettet folle mear as it label, ynklusyf wearden dy't jo net fan doel wiene te bewarjen.
Rin it skript mei de hân en it sil unset foar alles rapportearje, omdat in hânmjittige shell de ferbiningomjouwing net draacht. Dat is gjin bug yn it skript en it is gjin bewiis dat it fjild ûntbrekt. Test it fia in echte ferbining, dat is de iennige kontekst wêryn de fariabele bestiet.
Ferifiearje wat echt oankaam
Ferbyn ien kliïnt mei it label en ien sûnder, lês dan it bestân. It pear is de test: ien rigel moat de wearde drage en de oare de standert, en beide moatte deselde autentisearre identiteit neame dy't jo ferwachtsje.
tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset legacy-laptop-02
Dy kommentaarregels binne de foarm fan 'e útfier, gjin transkripsje fan jo server; lês jo eigen bestân. As de twadde kliïnt ek in wearde toant, is de fariabele earne oars yn 'e omjouwing set, en lês jo in ferâldere ynstelling yn stee fan it peerfjild.
Kontrolearje ek it serverlog foar de ferbining. Peer-ynformaasje kin dêr ferskine, wat handich is by debugging en in reden om de wearden saai te hâlden: gjin nammen fan minsken, gjin ticketnûmers, neat dat jo net hearre wolle soene dat in loglêzer it sjocht.
Behannelje it label as in bewearing, net as in identiteit
Elkenien dy't it kliïntprofyl bewurkje kin, kin it label feroarje, en it feit dat de tunnel autentisearre is, makket it label net gesachhawwend. It ferfier beskermet de wearde ûnderweis; it sertifisearret de bewearing net. Autorisaasje heart noch altyd ta de autentisearre identiteit en ta in ynskriuwrekord dat de server hat, wêrby't it label dêrmei ferlike wurdt as it der op oankomt.
Dat ûnderskie bepaalt wêr't it label brûkt wurde mei. Goede brûken binne in sesje nei it juiste logbestân liede, in werjefte-groep yn in dashboard kieze, of in stipsesje labelje sadat in minske it letter fine kin. Minne brûken binne in apparaat ta in subnet talitte, in firewallbelied kieze, of beslute hokker klantgegevens de sesje lêze mei.
Falidearje de wearde foardat it in paad, in query of in shellkommando berikt. In list fan tastiene ferwachte strings is genôch foar in útrolabel, en it kostet neat. Foegje nea in string fan in peer ta oan in shellkommandorigel, en behein elke bewarre observaasje ta de sesje en net ta in tunneladres dat de folgjende kliïnt wer brûke sil.
case "${UV_DEPLOY:-}" in
field-support|field-qa|lab) : ;;
*) UV_DEPLOY=unknown ;;
esac
Draai it skjin werom
De funksje fuorthelje is twa fuorthellingen en ien ferifikaasje. Fuorthelje de rigels setenv en push-peer-info út it kliïntprofyl, en fuorthelje of deaktivearje dan de heak en syn logdoel op 'e server.
grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log
Ferbyn dêrnei wer ien kliïnt en befêstigje dat de logrigel weiwurdt. In heak dy't nei de profylwiziging trochgiet mei fjurjen is meast in twadde profyl dat noch op in testapparaat útbroad is, en it no fine is goedkeaper as it by in audit fine.
Wat oan 'e ein oerbliuwt, is in lyts, beheind stik sesjemetadaat wêrfan de oarsprong dokumintearre is: de kliïnt beweart it, de server registrearret it, en neat oer tagong hinget derfan ôf. Dat is de nuttige ferzje fan 'e funksje, en it hat gjin nije legitimaaasje nedich om dêre te kommen.