OpenVPN push-peer-info: означување клиенти без давање пристап

Ознаките за распоредување се вообичаената причина зошто луѓето посегнуваат по оваа функција: секоја врска треба да носи нешто како локација или улога, а серверот треба да го чита без да измислува втор формат на акредитиви. Заедницата OpenVPN веќе го има механизмот и тој е мал. Болниот дел се очекувањата. Поставувањето обична променлива во профилот на клиентот не прави ништо на серверот, а вредноста што пристигнува докажува само дека клиентот ја испратил.

Ова е прирачник за работниот пат, чекорот за проверка што покажува што навистина пристигна и враќањето што не остава полуконфигурирана кука. Ништо овде не бара нов сертификат, нов приклучок или проширување на протоколот.

Поставете ја променливата и овозможете го патот

Две линии ја вршат работата во профилот на клиентот и двете се потребни. Без првата нема што да се испрати; без втората клиентот воопшто не нуди информации за партнерот. Редоследот не е важен и тоа вреди да се знае зашто двете линии често завршуваат во различни делови од генерираниот профил. Важно е двете да преживеат се што го препишува профилот пред клиентот да го прочита.

setenv UV_DEPLOY field-support
push-peer-info

Префиксот UV_ не е украс. Обичната променлива DEPLOY останува локална за процесот на клиентот и никогаш не се проследува, додека формата со префикс е просторот за имиња што протоколот го резервира за полиња дефинирани од корисникот. Остатокот од одобрениот профил оставете го недопрен и пред распоредување проверете дали градбата на клиентот што ја распоредувате ги поддржува двете директиви.

Една практична проверка припаѓа тука, а не на крајот: уверете се дека директивата стигнува до бинарниот файл на клиентот и дека не ја голта обвивка. Графички клиент што генерира своја командна линија или интерфејс за управување што вчитува зачуван профил може да отфрли линии што не ги препознава. Ако серверот не гледа ништо, ова е првото место каде треба да се погледне.

Прочитајте го полето од кука на серверот

На страната на серверот, примените информации за партнерот се валидираат и се вметнуваат во околината на работниот тек на врската, и токму тоа ги прави читливи од кука без никаква ваша работа на протоколот. Серверот не треба да го анализира контролниот канал или да чува нешто за вас; вредноста едноставно е присутна додека врската се воспоставува. Минимална скрипта client-connect што ја запишува ознаката покрај автентифицираното име изгледа вака.

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

Читајте ја променливата преку околината наместо да го анализирате дневникот и секогаш давајте ѝ стандардна вредност. ${UV_DEPLOY:-unset} ја одржува скриптата функционална за клиенти што никогаш не го испраќаат полето, што е нормална состојба при постепено распоредување. Не го истурајте целото опкружување во дневник за да го најдете името; содржи многу повеќе од ознаката, вклучително вредности што не сте имале намера да ги зачувате.

Стартувајте ја скриптата рачно и таа ќе пријави unset за се, бидејќи рачната обвивка не ја носи околината на врската. Тоа не е грешка во скриптата и не е доказ дека полето недостасува. Тестирајте ја преку вистинска врска, единствениот контекст во кој променливата постои.

Проверете што навистина пристигна

Поврзете еден клиент со ознаката и еден без неа, потоа прочитајте ја датотеката. Парот е тестот: едната линија треба да ја носи вредноста, а другата стандардната вредност, и двете треба да го наведат истото автентифицирано идентитет што го очекувате.

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

Тие линии со коментар се формата на излезот, а не препис од вашиот сервер; читајте ја сопствената датотека. Ако и вториот клиент покажува вредност, променливата е поставена некаде друго во околината и читате застарено поставување, а не полето за партнер.

Проверете го и дневникот на серверот за врската. Информациите за партнерот може да се појават таму, што е погодно за отстранување грешки и причина да ги држите вредностите досадни: без имиња на луѓе, без броеви на билети, ништо што не би сакале читател на дневникот да го види.

Третирајте ја ознаката како тврдење, а не како идентитет

Секој што може да го уреди профилот на клиентот може да ја смени ознаката, а тоа што тунелот е автентифициран не ја прави ознаката авторитативна. Транспортот ја штити вредноста во текот; тој не го потврдува тврдењето. Авторизацијата се уште му припаѓа на автентифицираниот идентитет и на запис за регистрација што го поседува серверот, а ознаката се споредува со тој запис кога тоа е важно.

Оваа разлика одредува каде смее да се користи ознаката. Добри употреби се насочување на сесија кон вистинската датотека на дневникот, избор на група за прикажување на табла или означување на сесија за поддршка за да може човек да ја најде подоцна. Лоши употреби се пуштање уред во подмрежа, избор на политика за заштитен ѕид или одлучување чии податоци на клиент смее да ги чита сесијата.

Валидирајте ја вредноста пред да стигне до патека, барање или команда на обвивка. Список на дозволени очекувани низи е доволен за ознака за распоредување и не чини ништо. Никогаш не вметнувајте низа обезбедена од партнерот во командна линија на обвивка и ограничете го секое зачувано набљудување на сесијата, а не на адреса на тунел што следниот клиент ќе ја користи повторно.

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

Вратете го чисто

Отстранувањето на функцијата се две бришења и една проверка. Отстранете ги линиите setenv и push-peer-info од профилот на клиентот, потоа отстранете ја или оневозможете ја куката и нејзината цел за дневник на серверот.

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

Потоа повторно поврзете еден клиент и потврдете дека линијата во дневникот престанува да се појавува. Кука што продолжува да се активира по промената на профилот обично е втор профил се уште распореден на тест уред, а наоѓањето сега е поевтино од наоѓањето за време на ревизија.

На крајот останува мал, ограничен дел од метаподатоци за сесијата со документирано потекло: клиентот го тврди, серверот го запишува и ништо во врска со пристапот не зависи од него. Тоа е корисната верзија на функцијата и не бара нови акредитиви за да се стигне таму.