Кіраўніцтва: асобнае падключэнне двух кліентаў 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. Гэта мяжа, выяўленая як тэст.