>[оверквотинг удален]
>> переходящих сотрудников? Или надо перегенерировать ключи заново? Есть у кого опыт?
>> Мне гугл пока не помог. Я пока не теряю надежды, перечитываю
>> доку, но рецепта пока не нашёл. Спасибо заранее!
> Есть несколько вопросов, в зависимости от которых ответ будет "да" или "нет".
> 1) Если в качестве ключей используются сертификаты от своих центров сертификации, то
> ключи перегенерировать не требуется. Вы в качестве корневого (доверенного) сертификата
> можете на сервере и на клиентах указать не один, а несколько.
> Вам придется всё-таки обновить конфигурацию, добавив второй корневой сертификат - ведь
> иначе половина сотрудников не будут "доверять" серверу (в зависимости от того,
> какой именно серверный сертификат вы оставите).Да, у нас свои сертификаты. Всё когда-то делалось разными людьми, но по одним учебникам.
> 2) Если используются дополнительные возможности в части взаимодействия с клиентами (например,
> "привязка к конкретным адресам", наличие серверов и подсетей "за клиентами" и
> прочее) - надо это разбирать в частном порядке. Здесь надо смотреть
> по конкретным случаям.
Навскидку, такого нет, но это, думаю, если всплывёт, то будут единичные случаи.
> 3) Используется ли второй фактор авторизации (когда сервер запрашивает дополнительно пароль)
Нет
>[оверквотинг удален]
> 2 - то, что относится ко второй. Давайте решим, что мы
> оставляем на сервере сертификат от первой организации. Тогда:
> 0) Обязательный бекап конфигурации VPN.
> 1) Добавляем второй корневой сертификат в список доверенных: cat ca2.pem >> ca1.pem
> (обратите внимание на двойной знак >>) или можете просто объединить эти
> два файла в любом текстовом редакторе.
> 2) Полученный файл на сервере (ca1.pem), dh1.pem (им заменяем файл dh2.pem на
> клиентах - если используется настройка "dh" в конфигурации клиентов), новый адрес
> сервера (изменяем парамерт remote в конфигурациях клиентов) распространяем среди клиентов
> ВТОРОЙ компании
dh1 и dh2 объединить никак не удастся? :)
> В реальной жизни этот путь я проходил больше 8 лет назад, поэтому
> мог что-то забыть.
Спасибо за опыт!
> P.S. Вы же можете, в принципе, просто второй VPN сервер просто разместить
> у себя и настроить маршрутизацию до ресурсов организации на втором сервере.
Как я уже писАл выше - методичка по настройке сервиса была одна и на тот момент идеи о слиянии предприятий не было от слова "вообще". Поэтому, разнести порты никто не догадался. :(
> Тогда вообще "клиентов" обходить не придется, а просто постепенно вместе с
> сертификатами всех клиентов переведете на общий сервер. Только емкость сети VPN
> увеличьте - 150 клиентов не поместятся в стандартную подсеть из 256
> адресов, так как подключение каждого клиента требует себе два адреса.
О! За это ещё одно спасибо! - Я этот момент упустил из виду. Но есть положительный момент: часть сотрудников, что пользуют сервис, уже сгинули на просторах жизни, так что буду экспериментировать и следить, чтобы клиенты не вылезли за /24.
Насколько я понимаю, в openvpn принцип dhcp - клиент привязывается к адресу, но не жёстко: если прошлый адрес клиента занят, сервер выдаст ему свободный адрес из доступного пула. Не все у нас работают одновременно. Больше в режиме "выполнил задание - слил результаты/отчёт, получил новую задачу". На худой конец, можно маску поставить /23.
Главное, чтобы коллапса не случилось, когда ~70-80 человек не смогут подключиться.
Вариант для распечатки
