OpenVPN push-peer-info: označte klienty, aniž byste jim dali přístup

Značky nasazení jsou obvyklým důvodem, proč lidé sahají po této funkci: každé připojení by mělo nést něco jako lokalitu nebo roli a server by to měl číst, aniž by vymýšlel druhý formát přihlašovacích údajů. Komunitní OpenVPN už mechanismus má a je malý. Bolí očekávání. Nastavení obyčejné proměnné v profilu klienta na serveru nic neudělá a hodnota, která přesto dorazí, dokazuje jen to, že ji klient odeslal.

Toto je návod pro funkční cestu, krok ověření, který ukáže, co skutečně dorazilo, a vrácení změn, které po sobě nenechá napůl nakonfigurovaný hook. Nic zde nepotřebuje nový certifikát, nový plugin ani rozšíření protokolu.

Nastavte proměnnou a zapněte cestu

V profilu klienta práci udělají dva řádky a oba jsou nutné. Bez prvního není co odeslat; bez druhého klient vůbec nenabízí informace o peerovi. Na pořadí nezáleží a je dobré to vědět, protože oba řádky často skončí v různých částech generovaného profilu. Důležité je, aby oba přežily všechno, co profil přepíše, než ho klient přečte.

setenv UV_DEPLOY field-support
push-peer-info

Předpona UV_ není dekorace. Obyčejná proměnná DEPLOY zůstává lokální pro proces klienta a nikdy se nepředává, zatímco forma s předponou je jmenný prostor, který protokol vyhrazuje pro uživatelsky definovaná pole. Zbytek schváleného profilu nechte nedotčený a před nasazením ověřte, že sestavení klienta, které nasazujete, obě direktivy podporuje.

Jedna praktická kontrola patří sem, ne na konec: ujistěte se, že direktiva dorazí do binárky klienta a že ji nespolkne obal. Grafický klient, který si generuje vlastní příkazový řádek, nebo rozhraní pro správu, které znovu načítá uložený profil, mohou zahodit řádky, které neznají. Pokud server nic nevidí, je to první místo, kam se podívat.

Přečtěte pole ze serverového hooku

Na straně serveru se přijaté informace o peerovi ověří a vloží do prostředí pracovního postupu připojení, a právě to je činí čitelnými z hooku bez jakékoli vaší práce s protokolem. Server nemusí analyzovat řídicí kanál ani pro vás nic ukládat; hodnota je prostě přítomná, zatímco se připojení sestavuje. Minimální skript client-connect, který zapíše značku vedle ověřeného jména, vypadá takto.

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

Čtěte proměnnou přes prostředí, ne analýzou logu, a vždy jí dejte výchozí hodnotu. ${UV_DEPLOY:-unset} udržuje skript funkční pro klienty, kteří pole nikdy neposílají, což je při postupném zavádění normální stav. Nesypejte celé prostředí do logu, abyste našli jméno; obsahuje mnohem víc než značku, včetně hodnot, které jste nechtěli trvale uchovat.

Spusťte skript ručně a nahlásí unset u všeho, protože ruční shell nenese prostředí připojení. To není chyba skriptu a není to důkaz, že pole chybí. Otestujte ho přes skutečné připojení, což je jediný kontext, kde proměnná existuje.

Ověřte, co skutečně dorazilo

Připojte jednoho klienta se značkou a jednoho bez ní, pak přečtěte soubor. Dvojice je test: jeden řádek by měl nést hodnotu a druhý výchozí hodnotu a oba by měly uvést stejnou ověřenou identitu, kterou očekáváte.

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

Ty komentářové řádky jsou tvar výstupu, ne přepis z vašeho serveru; čtěte svůj vlastní soubor. Pokud i druhý klient ukazuje hodnotu, proměnná je nastavena někde jinde v prostředí a čtete zastaralé nastavení, ne pole peera.

Zkontrolujte také serverový log pro toto připojení. Informace o peerovi se tam mohou objevit, což je vhodné pro ladění a důvod držet hodnoty nudné: žádná jména lidí, žádná čísla tiketů, nic, co by vám vadilo, kdyby to četl někdo jiný.

Berte značku jako tvrzení, ne jako identitu

Kdokoli může upravit profil klienta, může změnit značku, a to, že je tunel ověřený, značku neautorizuje. Transport chrání hodnotu při přenosu; tvrzení nepotvrzuje. Autorizace stále patří ověřené identitě a záznamu o zápisu, který vlastní server, a značka se s tímto záznamem porovnává, když na tom záleží.

Toto rozlišení rozhoduje o tom, kde se značka smí používat. Dobrá použití jsou směrování relace do správného logu, volba zobrazovací skupiny na dashboardu nebo označení relace podpory, aby ji člověk později našel. Špatná použití jsou vpuštění zařízení do podsítě, volba pravidla firewallu nebo rozhodnutí, čí data zákazníka smí relace číst.

Hodnotu ověřte, než se dostane do cesty, dotazu nebo příkazu shellu. Seznam povolených očekávaných řetězců pro značku nasazení stačí a nic nestojí. Nikdy nevkládejte řetězec dodaný peerem do příkazového řádku shellu a každé uložené pozorování omezme na relaci, ne na adresu tunelu, kterou příští klient znovu použije.

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

Vraťte to čistě

Odebrání funkce jsou dvě smazání a jedno ověření. Odstraňte řádky setenv a push-peer-info z profilu klienta, poté odstraňte nebo zakažte hook a jeho cíl logu na serveru.

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

Poté znovu připojte jednoho klienta a potvrďte, že se řádek v logu přestal objevovat. Hook, který po změně profilu stále běží, je obvykle druhý profil stále nasazený na testovacím zařízení, a najít ho teď je levnější než ho najít při auditu.

Na konci zůstává malá, ohraničená část metadat relace s doloženým původem: klient ji tvrdí, server ji zaznamenává a nic o přístupu na ní nezávisí. To je užitečná verze funkce a k jejímu dosažení není potřeba nový přihlašovací údaj.