Ръководство: отделно въвеждане на два клиента OpenVPN

Два клиента на един хост звучат като още един сървърен блок и втори порт. Това се превръща в различен проект, след като изброите всичко, което клиентът всъщност притежава: слушател, пул от тунели, идентичност, файлове за доверие, маршрути и график за отменяне. Пропуснете едно от тях и вторият клиент тихо наследява част от първия. Създайте карта за всеки клиент и я попълнете, преди първият клиент да се свърже.

Определете пълна карта на ресурсите за всеки клиент

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

Дръжте картата до конфигурацията и я актуализирайте при всяка промяна на стойност. Документация, която се отдалечава от реалността, е по-лоша от никаква.

Дръжте материалите за доверие вътре във всеки клиент

Отделен издателски орган за всеки клиент прави границата лесна за осмисляне и държи ключа за подпис извън хоста, изложен на интернет. Споделен корен също може да работи, но обща котва не превръща две услуги в един домейн на членство. Решете кои вериги приема всеки слушател и кои идентичности на клиенти оторизира, след което запишете и двете. Не отстранявайте сертификати от верига чрез проба и грешка, докато нещо се свърже.

Собственият частен ключ на сървъра принадлежи в защитен файл за всеки клиент, а не в директория с шаблони, която се репликира заедно с конфигурацията.

Разделете мрежите, както и процесите

Два процеса на два порта все още споделят хост и таблица за маршрутизация, освен ако не ги разделите. Потвърдете какво слуша, преди да се доверите на дизайна.

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

Проверката на слушателя показва кой процес притежава всеки публичен порт, а проверката показва дали клиентският сертификат се свързва с предвидената котва. Нито един от изходите не доказва, че клиентът на A не може да достигне подмрежата на B, затова определете политика за източник и местоназначение, обратни маршрути и всяка умишлено споделена услуга. Мрежовите пространства от имена или контейнерите разделят контекстите на маршрутизация и намаляват случайното смесване, но те са не пълна граница за наемател сами по себе си. Изберете по-силен механизъм за изолация, когато моделът на заплахите го изисква.

Доставете отменяне преди предаването

Разгръщането на сертификат е непълно, докато отменянето няма път за доставка. Проверете издателя на CRL и валидностния прозорец като част от въвеждането.

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

Проверката на CRL отчита кога списъкът е издаден и кога изтича, а статусът на услугата потвърждава, че екземплярите, които го четат, работят. Обновявайте списъка по графика на издателската политика, дори когато нищо ново не е отменено, защото изтекъл CRL може да отхвърли всеки клиент. Публикувайте пълен файл, вместо да оставяте читателите да срещнат частичен запис, и валидирайте подписа преди разгръщане. Запишете кой отговаря за издаването, работата на крайната точка и извеждането от експлоатация, така че спирането на клиент A да не засяга B.

След това стартирайте приемната двойка: разрешен клиент достига собствената си услуга, а идентификационните данни на A се отхвърлят от слушателя на B. Това е границата, изразена като тест.