gifts2017

Организация защищенной VPN сети с помощью opnvpn

Опубликовал Антонио (Fragster) в раздел Администрирование - Системное

OpenVPN — гибкий инструмент для соединения компьютеров и локальных сетей в одну защищенную виртуальную сеть через интернет или, например, организовать публичную сеть wi-fi с публикацией внутри нее защищенных ресурсов. Это позволяет публиковать внутри этой сети ресурсы (такие, как сервера терминалов, файловые сервера, принтеры и т.д.) не зависимо от того, есть ли у устройства «белый» адрес в сети интернет, для того, чтобы его ресурсы стали доступными для остальных членов виртуальной сети.

В моем случае было необходимо соединить несколько удаленных филиалов со своими локальными сетями с центральным офисом, а также обеспечить работу некоторых сотрудников из дома.

Схема сети должна выглядеть примерно так:

схема vpn сети

При этом белый IP имеется только у центрального офиса. В качестве всех прокси-серверов используются компьютеры с ОС OpenSuSE Linux — из-за легкости настройки, все действия займут не более получаса (для серверов).

Для начала нужно установить пакеты OpenVPN на всех серверах, и на каждом клиенте, который напрямую будет соединятся с главным сервером.

zyper in openvpn

Для обеспечения безопасности авторизация будет производится не по имени/паролю, а на основе сертификатов с открытым ключом. Для облегчения работы с сертификатами вместе с OpenVPN поставляется набор скриптов easyrca (лежит в /usr/share/openvpn/easyrca). Также поставляется набор образцов конфигурационных файлов (лежит в /usr/share/doc/packages/openvpn).

Для начала подготовим сертификаты для клиентов и сервера:
скопируем скрипты easyrca в какой-нибудь из каталогов пользователя,
заполним данные в файле vars подходящими значениями (длинами ключей и сроком действия сертификатов, названием компании, местами и т.п.)
выполнить source ./vars для установки наших переменных,
затем очистим ключи, которые могут быть от предыдущих установок: ./clean-all
и сформируем корневой сертификат: ./build-ca

Теперь можно приступить к формированию ключей:
для сервера: ./build-key-server <имя сервера/сертификата>
для клиентов: ./build-key <имя клиента/сертификата>
в качестве имени сертификата сервера целесообразно указать «server», а для клиента — название подразделения, к которому будет относится сертификат (например client_msk_timirjazevskaya, client_msk_marjina_rosha, client_spb_gorkovskaya и т.д.)
Затем сформируем параметры шифрования протокола Диффи-Хельмана: ./build-dh

Теперь в папке keys лежат все необходимые файлы, которые необходимо положить в папку /etc/openvpn по серверу и клиентам следующим образом:

  • ca.crt — корневой сертификат, на сервер и на каждого клиента
  • ca.key — ключ для подписи сертификатов, оставьте в папке с ключами и никому не давайте :)
  • dh1024.pem — параметры шифрования, на сервер
  • server.crt — сертификат сервера, на сервер
  • server.key — закрытый ключ сертификата сервера, на сервер, ключ является секретным
  • client_*.crt — сертификаты клиентов, на соответствующие машины клиентов
  • client_*.key — закрытый ключ сертификатов клиентов, на соответствующие машины клиентов, ключи являются секретными


теперь скопируем файл конфигурации сервера из папки с примерами в папку с настройками openvpn:
cp /usr/share/doc/packages/openvpn/sample-config-files/server.conf /etc/openvpn/

в этом файле нас не устраивают некоторые параметры:

dev tap0 # тип устройства не tun, а tap, определенный номер устройства
имена файлов с сертификатами: параметры ca, cert и key
;server 10.8.0.0 255.255.255.0 # параметр server нужно закомментировать, потому что он определяет не совсем нужный пул адресов для динамического присваивания клиентам (10.8.0.2-10.8.0.254)
# вместо этого - свои параметры
mode server # режим сервера
tls-server # аутентификация по сертификата
ifconfig 10.8.0.1 255.255.255.0 # адрес/маска сервера внутри VPN
ifconfig-pool 10.8.0.100 10.8.0.254 255.255.255.0 # пул динамических адресов
push "route-gateway 10.8.0.1" # определяем маршрут на клиентах — внутри VPN все через сервер

push "route 192.168.0.0 255.255.240.0" # маршрут во внутреннюю сеть для клиентов
client-config-dir ccd # папки с конфигурациями для клиентов (для назначения статических IP) (создать внутри /etc/openvpn)
client-to-client # маршрутизация между клиентами

up "service SuSEfirewall2_setup restart" # перезапуск файрволла при старте сервиса
down "service SuSEfirewall2_setup restart" # и при остановке... из-за того, что устройства,
# создаваемые openvpn виртуальные и существуют только пока он запущен
route 192.168.1.0 255.255.255.0 10.8.0.2 # маршрут в сеть филиала 1
route 192.168.2.0 255.255.255.0 10.8.0.3 # маршрут в сеть филиала 2 (см. Схему)
# и маршруты в сети остальных филиалов...

теперь нужно задать статические адреса для клиентов с внутренними адресами, для этого нужно в папке /etc/openvpn/ccd (см выше) создать файлы с именами сертификатов соответствующих клиентов, с примерно таким содержанием:
ifconfig-push 10.8.0.2 255.255.255.0 # конфигурация клиента
iroute 192.168.2.0 255.255.255.0 10.8.0.2 # маршрут для процесса openvpn и его встроенной маршрутизации


на клиентах же копируем файл client.conf из папки с образцами, заменяем tun на tap, задаем адрес сервера, меняем имена сертификатов на правильные и добавляем строки для перезапуска файрволла при старте/остановке openvpn

теперь нужно настроить файрволл на сервере и клиентах для того, чтобы он пропускал запросы из vpn во внутренние сети (на клиентах без внутренних сетей и не публикующих никаких ресурсов не обязательно) (также предполагается, что файрволл уже настроен как шлюз в интернет для внутренней сети):

yast2 sysconfig

далее все действия производятся в ветке /network/Firewall/SuSEfirewall2/


FW_DEV_INT добавить через пробел имя интерфейса openvpn (tap0) - добавляем его во внутреннюю зону
FW_ALLOW_CLASS_ROUTING int - разрешаем маршрутизацию между интерфейсами внутренней внутренней зоны
FW_REJECT_INT no - не отклонять пакеты из внутренней зоны - не обязательно
FW_FORWARD_ALLOW_BRIDGING yes - включить сетевые мосты, даже если нету ни одного интерфейся типа мост

все, теперь можно сохранять все настройки и запускать openvpn (на серверах и на клиентах):
service openvpn start
должно вернуть done, в списке сетевых устройств должно появится устройство tap0


ifconfig
tap0 Link encap:Ethernet HWaddr 00:FF:A0:B4:72:BF
inet addr:10.8.0.1 Bcast:10.8.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:611222 errors:0 dropped:0 overruns:0 frame:0
TX packets:539849 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:108883515 (103.8 Mb) TX bytes:141490615 (134.9 Mb)tap0 Link encap:Ethernet HWaddr 00:FF:A0:B4:72:BF
inet addr:10.8.0.1 Bcast:10.8.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:611222 errors:0 dropped:0 overruns:0 frame:0
TX packets:539849 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:108883515 (103.8 Mb) TX bytes:141490615 (134.9 Mb)


в маршрутах автоматически прописаться нужные:

ip route
192.168.2.0/24 via 10.8.0.3 dev tap0
192.168.1.0/24 via 10.8.0.2 dev tap0
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.100

Все, настройка закончена, теперь при первой же возможности клиенты будут подключатся к серверу и составлять виртуальную локальную сеть как на схеме в начале статьи, в которой можно безопасно публиковать серверы и ресурсы. Интернет при этом будет работать как и работал, такая схема работает поверх уже установленных VPN соединений, и т.д. Если на клиентах, которые непосредственно подключаются к серверу используется networkmanager — необходим пакет networkmanager-openvpn, для windows настройка примерно такая же.

В заключении можно сказать, что если в /etc/openvpn сформировать несколько файлов .conf то при старте сервиса запустится столько процессов openvpn, сколько этих файлов там лежит. таким образом можно разделять клиентов по группам доступа (используюя разные корневые сертификаты), организовывать публичный доступ без доступа во внутреннюю сеть, или к с доступом к определенным серверам, сделать топологию сети типа «звезда» или «кольцо» при наличии у всех филиалов внешнего адреса с помощью нескольких туннелей, в общем можно сделать практически все, что угодно...

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Антонио (Fragster) 28.01.09 17:36
А еще на сервере нужно разрешить коннектится к порту 1194 по UDP
2. Asmody (Asmody) 28.01.09 17:39
круто! а если в филиале стоит одна машина с windows?
3. Антонио (Fragster) 28.01.09 17:57
в смысле всего одна машина, или это шлюз? тогда ставишь опенвпн под винду - и точно так же коннектишься... если машина во внутренней сети - то никаких настроек на ней делать не надо...
4. Антонио (Fragster) 28.01.09 18:09
(3)+ специфичные для суси тут только настройки файрволла, ну, и примерные скрипты и easy в винде в других местах будут находится
5. Владимир Миров (VladMir) 29.01.09 09:50
Слова "схема vpn сети" вижу. А где же непосредственно схема? :)
6. Anton (rader) 29.01.09 09:57
Пользовался и бросил, мегаглючная вещь
7. Антонио (Fragster) 29.01.09 11:52
(5) боюсь все 6 точек и сотня компьютеров за ними долго рисовать...
(6) что глючило? у нас никаких проблем нету, терминальный сервер, опубликованный в ВПН у клиентов субьективно быстрее работает (время открлика) с теми же настройками, чем просто опубликованный в инете... файлы кидаются, принтеры печатают - никаких проблем... опять же проблему с длинными именами принтеров в 1С таким образом можно устранить - просто добавив сетевые принтеры на сервере терминалов (имена будут без имени клиента в скобках)...
8. Владимир Миров (VladMir) 29.01.09 13:44
9. Dmitry Semenov (dima1c) 02.02.09 16:28
все это можно сделать 4 кликами в windows xp или windows 2003.... другое дело, люди ленятся читать ...
10. Антонио (Fragster) 02.02.09 16:48
как не считал - все равно больше четырех кликов получается... да и настройка для того, чтобы шлюз при соединении с впном не переопределялся - закопана еще кликов на 5... маршрутизация настраивается - еще во много кликов... аутентификация с сертификатами, или по имени и паролю - тоже много кликов... ИМХО быстрее не получится, получится только дороже (никогда не понимал людей, которые ставят винду на интернетовский шлюз)...
11. Антон Стеклов (asved.ru) 16.05.13 07:05
поясните, пожалуйста, зачем вам понадобился проброс L2, т.е. dev tap? Чем dev tun & topology subnet не устроил? Маршрутизация-то все равно на L3 происходит.

Кроме того, у вас ошибка в рисунке - неверно указана исключаемая маска, да и вообще исключаемые подсети для vpn-клиентов.

Не раскрыта тема конфигурации туннелей между офисами - маршруты-то к ним указаны, но гарантии, что шлюзам офисов будут присвоены именно указанные в маршрутах адреса, никакой. Если же Вы решили использовать те адреса, что первыми им присвоились - в конфиге сервера должно быть ifconfig-pool-persist

Да и Suse в качестве примера выбран неудачно - им почти никто не пользуется, а в распространенных дистрибутивах в ходу iptables.

Двойка, в общем.
12. Антон Стеклов (asved.ru) 16.05.13 07:09
(10) Fragster,
никогда не понимал людей, которые ставят винду на интернетовский шлюз


Вы не любите кошек? Да вы их просто готовить не умеете!

Хотя в данном контексте, как ни странно, Вы в чем-то правы. У tap драйвера под Windows есть серьезные проблемы с производительностью. Исправить их open source community не может уже много лет. Что ж, в этом весь опенсорс.
13. Антон Стеклов (asved.ru) 16.05.13 07:11
(9) dima1c,
все это можно сделать 4 кликами в windows xp или windows 2003....


Без применения PPP/GRE инкапсуляции, пожалуйста. ;) Вот в 7/2008 есть SSTP, а в указанных Вами ОС нету и не будет. А как GRE работает через NAT - ВЫ, думаю, не хуже меня знаете.
14. Антон Стеклов (asved.ru) 16.05.13 07:14
(1) Fragster,
к порту 1194 по UDP


proto tcp поустойчивее, хотя и менее экономичен. Да и порт можно любой назначить.
15. Антон Стеклов (asved.ru) 16.05.13 07:17
И еще касательно адресации: админа, использующего в корпоративной среде 192.168.0.0/24, следует гнать из профессии ссаными тряпками. Ибо эта сеть используется у 99% домашних пользователей, и при подключении возникает конфликт адресации.
16. Антонио (Fragster) 16.05.13 08:36
(11)
зачем вам понадобился проброс L2, т.е. dev tap? Чем dev tun & topology subnet не устроил?
тем, что tap - это сетевой мост и мы используем один адрес на всех клиентов и частично избавлены от необходимости настраивать маршрутизацию.


неверно указана исключаемая маска, да и вообще исключаемые подсети для vpn-клиентов
В чем ошибка, как, Вы считаете, должно быть?


Не раскрыта тема конфигурации туннелей между офисами - маршруты-то к ним указаны, но гарантии, что шлюзам офисов будут присвоены именно указанные в маршрутах адреса, никакой.
цитирую статью:"теперь нужно задать статические адреса для клиентов с внутренними адресами, для этого нужно в папке /etc/openvpn/ccd (см выше) создать файлы с именами сертификатов соответствующих клиентов, с примерно таким содержанием:"


в распространенных дистрибутивах в ходу iptables.
SuseFirewall - это морда к iptables. Действительно, ничего не мешает добавить скрипт, изменяющий правила iptables вручную. мне же показалось проще и "правильнее" (применительно к используемому дистрибутиву opensuse) использовать его встроенные средства. Зачем это нужно - в комментариях к настройкам написано, как настроить susefirewall - в статье тоже указано.


Двойка, в общем.
Тут каждый сам для себя решает. 19 человекам, судя по всему, было полезно, а минуса от Вас я не вижу :)


proto tcp поустойчивее, хотя и менее экономичен.
при подключении через 3g по rdp поверх этого vpn - разница видна на глаз, и она не в пользу варианта с tcp. А надежность обеспечивается тем, что тот же самый tcp идет уже внутри туннеля.

(14)
Да и порт можно любой назначить.
Спасибо, Кэп!

(15)
админа, использующего в корпоративной среде 192.168.0.0/24, следует гнать из профессии ссаными тряпками. Ибо эта сеть используется у 99% домашних пользователей, и при подключении возникает конфликт адресации.
Это Ваше право, если Вы - работодатель. О том, что будет конфликт адресов - я написал, человек, прочитавший статью сам может сделать вывод о том, нужно ему использовать свои адреса, или нет. Можно еще написать о том, что 10.8.0.0 у провайдера внутри может использоваться, и тогда тоже (в определенной ситуации) возможны косяки. В общем, много к чему можно придраться.
17. Антон Стеклов (asved.ru) 16.05.13 10:11
(16) Fragster,
и мы используем один адрес на всех клиентов
с topology subnet то же самое. Только бесполезных данных гоняется меньше.

неверно указана исключаемая маска, да и вообще исключаемые подсети для vpn-клиентов В чем ошибка, как, Вы считаете, должно быть?

Ограничение: внутренняя сеть клиентов не должна пересекаться со следующими сетями:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
UPD как раз при сети клиента 192.168.0.0/28 большая часть хозяйства будет работать. Согласно правилу выбора маршрута по большей маске.


при подключении через 3g по rdp поверх этого vpn - разница видна на глаз, и она не в пользу варианта с tcp

Постоянно пользуюсь с планшета, разницы не вижу, все вполне комфортно. dev tun, topology subnet, proto tcp, tun-mtu 1024.
Плюс в том, что при отвале 3G, к примеру, в дороге, реконнект происходит через 10-12 секунд против 20-30 с UDP. ping стоит 10

Можно еще написать о том, что 10.8.0.0 у провайдера внутри может использоваться, и тогда тоже (в определенной ситуации) возможны косяки

Вот как раз здесь косяки маловероятны, т.к. клиенту эта сеть не нужна. Да и маски различны. Провайдеры крайне редко используют /24 на серых сегментах, обычно маска меньше.

А сменить адресацию в одном сегменте - работы на полчаса. Если, конечно, сеть нормально настроена, без костылей в виде статических маршрутов на клиентах и т.п.

Впрочем, если предпочитаете ездить домой к сотрудникам перенастраивать роутеры - welcome. Но - в нерабочее время и бесплатно.

А что касается iptables - ни в одном никсовом howto Вы не найдете указания использовать дополнительные оболочки. Все на iptables -A. Ибо это универсальная команда, в отличие от.

цитирую статью

А вот это, простите, проморгал.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа