Здравствуйте. В связи с некоторыми событиями, в организации было решено перевести сотрудников на удаленную работу. Как вариант, рассматривается организация VPN подключения из дома к рабочему серверу.
В офисе уже имеется шлюз с OpenVPN сервером. На данный момент он обеспечивает связь между двумя филиалами, то есть клиент у него один.
Так вот, как лучше настроить сервер, так чтобы к нему могли подключаться 5, 10, 15, или более сотрудников со своих домашних машин? Обязательно ли генерировать для каждого ключ? Нужно ли прописывать для каждого сотрудника маршрут? Сотрудникам дома обязательно использовать прямое подключение к интернету (не через роутер)?
ИМХО лучше поднять еще один, чтобы в случае чего не компрометировать основной туннель в случае утечки сертификатов.
Генерируешь сертификат CA, генерируешь сертификат сервера, генерируешь сертификат для клиентов.
Прописать маскарадинг для интерфейса со вторым сервером и пушить маршруты до внутренних сетей. Тебе же не надо две сети связывать, а только клиентов удалённых пускать.
Подключаться им можно хоть с мобильного, лишь бы провайдер VPN не блокировал.
А если всё таки на основном? Чтобы поднимать новый, надо ехать в офис, что не совсем удобно. Просто пушить маршруты у клиентов во внутреннюю сеть? Сертификать можно использовать один? Не будет ли конфликта при использовании роутеров у клиентов? (ну к примеру у нескольких клиентов могут быть свои подсети за роутером одинаковые, и адреса машин одинаковые)
MaxxDamage, Сертификаты нужно обязательно делать разные. Даже не думайте, что тут получится сэкономить. К тому же это не трудно, когда разберетесь с процессом.
Пушить маршруты - это директива push route в конфиге сервера - она прописывает маршрут до сети за сервером на клиентах.
На хостах во внутренней сети, которые должны общаться с клиентами ВПН нужно чтобы либо ВПН сервер был шлюзом по умолчанию, либо (если это не так) добавлять маршрут до ВПН клиентов через ВПН сервер. Маршрут можете добавлять любым доступным способом - через DHCP, статический руками, GPO и т.п.
Согласен с Radjah, на счет поднятия второго сервера. Можно на том же физическом сервере, просто повесить его на другой порт со своим конфигом.
Если ВПН сервер стоит на шлюзе, который смотрит в интернет и имеет белый адрес, то никакого маскарадинга не нужно.
Сертификаты генерить придётся для каждого, потом каждому индивидуально настраивать, через что-то типа ammy или tw... печально.
Да, в рабочей сети сервер с OpenVPN является шлюзом по умолчанию, смотрит в интернет, и имеет белый IP.
Ну, придётся всё таки ехать, потому что связи с шлюзом нет почему-то. Не пойму в чём дело, даже с локальной машины ssh недоступен, Could not connect to '192.168.0.1' (port 22): Connection failed. Пинги ходят
Не подскажете, куда смотреть? Щас всё равно туда поеду, а новую тему поднимать не хочется
Хм, идея возникла такая - а может ли тот шлюз, который щас клиент, быть сервером для этих самых удаленных пользователей? У меня к нему по крайней мере есть удаленный доступ по ssh
Он тоже шлюз по умолчанию, смотрит в интернет и имеет два белых ip
Ziptar, да уже неважно, всё равно делаю сервер на другом шлюзе. Столкнулся с проблемой - клиент не подключается:
spoiler
Wed Mar 18 19:52:41 2020 MANAGEMENT: >STATE:1584550361,WAIT,,,,,,
Wed Mar 18 19:53:41 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Mar 18 19:53:41 2020 TLS Error: TLS handshake failed
На сервере в iptables прописал
-A INPUT -p udp -m udp --dport 64991-j ACCEPT (64991 - порт OpenVPN на сервере)
но соединения всё равно нет. Или я что-то не так делаю?
MaxxDamage, дебаг - это значения 6-10, емнип. В любом случае, вам нужно смотреть и на логи сервера и на логи клиента. Если хотите подсказку - неплохо бы для начала конфиги сервера и клиента выложить...
# Try to preserve some state across restarts.
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
cert user.crt
key user.key
ns-cert-type server
tls-auth ta.key 1
auth SHA512
tls-version-min 1.2
;cipher x
cipher AES-128-CBC
comp-lzo
verb 5
log /var/log/openvpn.log
# Silence repeating messages
;mute 20
Сервер
spoiler
local 94.xxx.xxx.xxx
port 88888
;proto tcp
proto udp
;dev tap
dev tun1
;dev-node MyTap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret
MaxxDamage, если с сертификатами всё в порядке, с маршрутами до сервера и от сервера всё хорошо (а выяснить это без подробного анализа логов c более высокой детализацией не удастся) - попробуйте снизить tls-version-min, выставить auth sha256, поиграться с cipher
spoiler
The following are TLSv1.2 DHE + RSA choices, requiring a compatible peer running at least OpenVPN 2.3.3:
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
Ziptar, прикол в том, что на сервере в логах вообще нет ничего в момент подключения, то есть до него соединение не доходит вообще. Порт на сервере открыт, проверял. На клиенте проброс на роутере сделал этого порта и отключил брандмауэр - всё равно не работает.
Логи с более высокой детализацией не вставить, ругается на превышение количества символов.
на сервере в логах вообще нет ничего в момент подключения
Ну это просто значит, что трафик таки не доходит до сервера по какой-то причине. Проверяйте сеть, маршруты, и т.д. Дело точно не в ovpn. Прежде всего постарайтесь понять, где именно трафик идёт не туда. Доходит ли он до пограничного роутера перед сервером? Что с ним происходит дальше? Как именно это делать - зависит от используемого оборудования, топологии сети, и пр.
ЗЫ в конфигах у вас другой порт указан, это вы заменили, или оно так и есть?...
Ziptar, другой, стараюсь порты и ip-адреса не светить в сети. Порты в настройках совпадают, это точно. В показанных тут настройках ip tables забыл поменять )
Перед сервером роутера нет, он сам является шлюзом, интернет в него напрямую приходит.
"То ли я дурак, то ли лыжи не едут". В общем дело оказалось не в лыжах. Попытка установить OpenVPN на телефон помогла разобраться в чём проблема - неправильно указано имя TLS-ключа.