Hook client-connect v OpenVPN: kam vaše adresa skutečně putuje

Vrácení adresy ze skriptu client-connect vypadá, jako by mělo nastavit IP klienta. Nenastaví: jediným kanálem hooku k serveru je dočasný soubor, jehož cesta přichází jako poslední argument skriptu, a adresa se do něj musí zapsat v syntaxi ifconfig-push. Skript, který adresu vypíše nebo skončí s nulou, aniž by cokoli zapsal, vytvoří připojeného klienta s adresou z poolu a protokol serveru vypadá naprosto zdravě.

Zmatek je pochopitelný, protože několik jiných hooků skutečně odpovídá pomocí návratových kódů nebo proměnných prostředí. Tento má vlastní smlouvu a smlouva začíná názvem souboru.

Hook zapisuje soubor, ne návratovou hodnotu

Deklarace jsou dva řádky: script-security 2, aby se volání povolilo, a poté client-connect /etc/openvpn/server/assign-address.sh. Když se klient autentizuje, server spustí tento skript s vygenerovanou cestou k souboru přidanou jako poslední argument, což je $1 jen tehdy, pokud deklarace nepředává žádné vlastní dodatečné argumenty. Vše, co se na tohoto klienta aplikuje, jde do toho souboru jako běžné direktivy, jedna na řádek, přesně jak by vypadaly v konfiguraci. Obal, který přidává vlastní parametry, posouvá pozici, a klasickým příznakem je skript zapisující do cesty, která vypadá jako --verbose.

Návratový kód je druhá polovina smlouvy. Nula znamená přijmi a přečti soubor; cokoli jiného spojení odmítne, a tak se nepřiřazená identita odmítne, místo aby tiše spadla zpět do poolu. Před vrácením úspěchu zapište celou direktivu, aby se napůl zapsaný soubor nikdy nestal konfigurací klienta.

Pozornost si zaslouží dvě direktivy, protože interagují se vším ostatním. ifconfig-push fixuje adresu, zatímco odeslaná route říká klientovi, co je přes tunel dostupné; vraťte první a zapomeňte na druhou a získáte klienta s adresou a bez cíle. Pořadí v souboru nehraje roli, ale úplnost ano. Hook, který posílá trasu pro prefix, na který nedosáhne žádný protějšek, je stejná chyba viděná z druhého konce.

Vstupy přicházejí přes proměnné prostředí: common_name, trusted_ip, ifconfig_pool_remote_ip a zbytek. Zacházejte se všemi jako s řetězci zvenčí serveru, nikdy jako s fragmenty shellu.

Mapování adres je politika, ne aritmetika

Lákavá zkratka je analyzovat název certifikátu a použít jeho číslice jako poslední oktet. To není alokátor a selhává obvyklými způsoby: dva názvy se stejným sufixem kolidují, název končící na 300 není adresa a certifikát přejmenovaný správcem tiše přesune zařízení. Při každém volání ověřujte členství v podsíti, použitelný rozsah hostitelů, rezervované adresy a jedinečnost a mapování udržujte v tabulce, kterou člověk přečte.

Kdo ovládá název, ovládá adresu, proto rozhodněte, co common_name v tomto nasazení skutečně představuje. Při zapnutém username-as-common-name je identitou přihlášení, nikoli subjekt certifikátu. Nikdy tuto hodnotu nepředávejte do vyhodnocení shellu a nikdy nedovolte, aby klient ovlivnil cestu k souboru.

Alokátor podložený registrem musí přežít souběžnost. Rezervujte adresu atomicky, ošetřete neúspěšný zápis, aniž byste pustili napůl nakonfigurovaného klienta, a označte každou alokaci spojením, které ji vlastní, aby pozdní odpojení starší relace nemohlo uvolnit adresu, kterou už drží novější. Několik instancí serveru sdílejících jeden pool činí tento požadavek ostřejším, nikoli volitelným.

Topologie rozhoduje, co ifconfig-push znamená

S topology subnet na 10.77.0.0/24 je ifconfig-push 10.77.0.20 255.255.255.0 adresa plus její maska sítě. Pod topology net30 není druhý argument vůbec maska, ale adresa protějšku, takže zkopírování podsíťového tvaru na server net30 vám dá klienta, který se přidruží a nemůže propouštět provoz. Topologii měňte záměrně, nikdy proto, aby příklad vypadal konzistentně. Server, který už běží na net30, má živé klienty na starém adresování, takže přepnutí je migrace s oknem údržby, ne úprava jednoho řádku.

Statické adresy musí ležet mimo dynamický pool a mimo každé jiné statické přiřazení, včetně těch, která rozdávají běžné soubory client-config-dir. Pokud dva mechanismy mohou vytvořit stejnou adresu pro různé klienty, jeden z nich to dříve či později udělá.

Než tomu uvěříte, otestujte čtyři případy

Spusťte stejné kontroly proti namapované identitě, nenamapované, opětovnému připojení a simulované poruše registru. openvpn --config client.ovpn --verb 4 ukazuje přidělenou adresu v push odpovědi a na serveru grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log potvrzuje, co bylo skutečně odesláno. U nenamapované identity je očekávaným výsledkem odmítnuté spojení, nikoli adresa z poolu.

Poté prohlédněte adresář, do kterého démon tyto dočasné soubory zapisuje. Skript běží ve sníženém kontextu služby, takže cesta zapisovatelná pro root, ale ne pro démona, promění každé spojení v odmítnutí s chybou oprávnění pohřbenou několik řádků níž v protokolu.

Přidělení není autorizace: připnutá adresa stále neuděluje přístup ke každému cíli za serverem. Držte politiku směrování a firewallu ve vlastní vrstvě a ověřujte ji proti adrese, kterou jste právě zafixovali.