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

След това свържете отново един клиент и потвърдете, че редът в журнала спира да се появява. Кука, която продължава да се задейства след промяната на профила, обикновено е втори профил, все още внедрен на тестово устройство, и намирането ѝ сега е по-евтино, отколкото по време на одит.

Накрая остава малка, ограничена част от метаданни за сесията с документиран произход: клиентът я твърди, сървърът я записва и нищо относно достъпа не зависи от нея. Това е полезната версия на функцията и не са нужни нови идентификационни данни, за да се стигне до нея.