Runbook: samostatné zapojení dvou zákazníků OpenVPN

Dva zákazníci na jednom hostiteli zní jako další serverový blok a druhý port. Jakmile vypíšete vše, co zákazník skutečně vlastní, stane se z toho jiný projekt: listener, pool tunelů, identita, soubory důvěry, trasy a plán revokace. Jednu z těch věcí vynechejte a druhý zákazník tiše zdědí část prvního. Vytvořte kartu pro každého zákazníka a vyplňte ji dřív, než se připojí první klient.

Přidělte každému zákazníkovi úplnou kartu prostředků

Rezervujte celou sadu společně: veřejný port, podsíť tunelu, cestu ke konfiguraci, cíl logů, název instance služby a zařízení. Pojmenování jako skupina je to, co brání klasické kopii funkčního souboru, která stále obsahuje pool nebo rozhraní prvního zákazníka. Hodnoty jsou příklady, ne rezervované porty, proto zkontrolujte, co hostitel už používá. Služba, která se spustí, není totéž jako zákazník, který je kompletní.

Uchovávejte kartu vedle konfigurace a aktualizujte ji při každé změně hodnoty. Dokumentace, která se vzdálí realitě, je horší než žádná.

Uchovávejte materiál důvěry uvnitř každého zákazníka

Samostatná vydávající autorita pro každého zákazníka usnadňuje uvažování o hranici a drží podepisovací klíč mimo hostitele vystavený internetu. Sdílený kořen může také fungovat, ale společná kotva neudělá ze dvou služeb jednu doménu členství. Rozhodněte, které řetězy každý listener přijímá a které identity klientů povoluje, a obojí zapište. Neodstraňujte certifikáty z řetězu metodou pokus-omyl, dokud se něco nepřipojí.

Vlastní soukromý klíč serveru patří do chráněného souboru pro každého zákazníka, ne do adresáře šablony, který se replikuje spolu s konfigurací.

Oddělte sítě i procesy

Dva procesy na dvou portech stále sdílejí hostitele a směrovací tabulku, pokud je neoddělíte. Potvrďte, co naslouchá, než designu uvěříte.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

Kontrola listeneru ukazuje, který proces vlastní každý veřejný port, a ověření ukazuje, zda se klientský certifikát řetězí k zamýšlené kotvě. Žádný z výstupů nedokazuje, že klient A nemůže dosáhnout podsítě B, proto definujte politiku zdroje a cíle, zpětné trasy a každou záměrně sdílenou službu. Síťové jmenné prostory nebo kontejnery oddělují směrovací kontexty a snižují náhodné míchání, ale samy o sobě nejsou úplnou hranicí nájemce. Zvolte silnější izolační mechanismus, když to model hrozeb vyžaduje.

Doručte revokaci před předáním

Nasazení certifikátu není úplné, dokud revokace nemá cestu doručení. Zkontrolujte vydavatele CRL a okno platnosti jako součást onboardingu.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

Kontrola CRL hlásí, kdy byl seznam vydán a kdy vyprší, a stav služby potvrzuje, že instance, která ho čte, běží. Obnovujte seznam podle plánu vydávající politiky, i když nebylo nic nového revokováno, protože prošlý CRL může odmítnout každého klienta. Publikujte úplný soubor místo toho, abyste nechali čtenáře narazit na částečný zápis, a před nasazením ověřte podpis. Zaznamenejte, kdo vlastní vydávání, provoz koncového bodu a vyřazení, aby vypnutí zákazníka A nenarušilo B.

Potom spusťte akceptační dvojici: povolený klient dosáhne své služby a pověření A je odmítnuto listenerem B. To je hranice vyjádřená jako test.