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

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

Ово је приручник за радни пут, корак провере који показује шта је заиста стигло и враћање које не оставља напола конфигурисану куку. Ништа овде не захтева нови сертификат, нови додатак или проширење протокола.

Поставите променљиву и омогућите пут

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

Прочитајте поље из куке сервера

На страни сервера примљене информације о peer-у се проверавају и умећу у окружење тока везе, и управо то их чини читљивим из куке без икаквог вашег рада на протоколу. Сервер не треба да анализира контролни канал нити било шта да чува за вас; вредност је једноставно присутна док се веза успоставља. Минимална скрипта 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

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

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

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

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

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

Валидирајте вредност пре него што стигне до путање, упита или команде љуске. Списак дозвољених очекиваних низова довољан је за ознаку распоређивања и не кошта ништа. Никада не умећите низ који је доставио peer у командни ред љуске и ограничите свако сачувано запажање на сесију, а не на адресу тунела коју ће следећи клијент поново користити.

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

Након тога поново спојите један клијент и потврдите да је ред у запису престао да се појављује. Кука која се наставља покретати после промене профила обично је други профил још увек постављен на тестни уређај, а пронаћи га сада је јефтиније него током ревизије.

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