Соединение двух сетей при помощи OpenVPN
В связи с большим объемом, инструкция по объединению сетей с OpenVPN разделена на несколько частей.
Данные для примера конфигурации
При описании параметров конфигурационных файлов понадобится указывать IP адреса и имена хостов. В качестве примера, будут использованы нижеследующие сведения об объединяемых сетях.
Сервер OpenVPN будет расположен в первой сети, которая имеет реальный IP адрес в Internet. Клиент OpenVPN из территориально удаленной второй сети будет подключаться к серверу OpenVPN в первой сети.
Первая сеть для соединения при помощи OpenVPN
Локальная сеть 192.168.100.0 mask 255.255.255.0 .
OpenVPN сервер будет настроен на компьютере под управлением Debian с адресом 192.168.100.1, имеющем реальный IP адрес в сети Интернет и fqdn имя router1.example.com .
Вторая сеть для соединения при помощи OpenVPN
Локальная сеть 192.168.200.0 mask 255.255.255.0 .
OpenVPN клиент будет настроен на компьютере с адресом 192.168.200.1 .
Виртуальная сеть OpenVPN
Для сети OpenVPN выделяется подсеть 192.168.50.0 mask 255.255.255.0 .
Установка OpenVPN сервера и клиента
В статье Установка OpenVPN сервера и клиента также описан процесс создания ключей и сертификатов для OpenVPN необходимых для авторизации между клиентом и сервером, с детальными инструкциями по созданию Центра Сертификации (Certification Authority, CA ) и выпуску ключей и сертификатов для сервера и клиента.
Настройка сервера и клиента OpenVPN
В статье про настройку клиента и сервера OpenVPN приведен пример конфигурационных файлов сервера и клиента с пояснениями.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настройка двух и более OpenVPN-серверов на одном сервере
Продолжая рассказ о возможностях OpenVPN рассмотрим ситуацию, когда нам нужно иметь на одном сервере несколько разных серверов OpenVPN с различными настройками. Чаще всего такая необходимость возникает на серверах, предназначенных для доступа в интернет, когда имеются клиенты, требующие особых настроек. В корпоративной среде такая возможность позволит с помощью одного физического сервера обеспечить связь для различных подразделений, которые не должны напрямую взаимодействовать друг с другом. Как это сделать — читайте в нашей статье.
Начнем с постановки задачи. В прошлой статье мы рассказали о настройке OpenVPN сервера в Oracle Cloud для доступа в интернет. Сервер работает, клиенты подключаются, но возникла необходимость подключения к нему роутеров Mikrotik, у которых, как известно, особые требования к настройкам OpenVPN. Как быть? Перенастроить сервер для совместимости с Mikrotik в ущерб остальным клиентам? Или поднять второй экземпляр сервера со своими настройками? Естественно, второй способ выглядит более предпочтительно.
Напомним, что все настройки мы производим на сервере с Ubuntu 18.04 в облаке от Oracle, настройка которого описана в статье по ссылке выше, рекомендуем ознакомиться с ней перед прочтением данного руководства. Однако все описанные ниже действия, с соответствующими поправками, применимы к любому Linux-дистрибутиву.
Настройка второго экземпляра сервера
Прежде всего создадим для нового сервера собственный набор ключей, для этого перейдем в папку нашего центра сертификации и загрузим переменные:
После чего создадим новый серверный сертификат:
Где server-tcp имя нашего экземпляра сервера. Мы советуем давать осмысленные имена, чтобы вам потом было понятно, что делает тот или иной экземпляр.
Скопируем ключ и сертификат в папку с ключами OpenVPN:
Затем скопируем шаблон конфигурации и назовем его server-tcp.conf:
После чего откроем файл и приступим к его редактированию. Какие важные особенности нам нужно учесть? RouterOS работает с OpenVPN только по протоколу TCP и не использует сжатие, также есть и некоторые иные особенности, которых мы коснемся позже. Все опции указаны в порядке их следования в файле, если опции нет — ее нужно добавить.
Для того, чтобы несколько серверов OpenVPN могли работать на одном хосте они должны использовать разные порты. Но так как первый экземпляр работает по протоколу UDP, то для второго экземпляра мы также можем использовать порт 1194, но только с протоколом TCP.
Укажем топологию сети:
И пути к ключам и сертификатам:
Диапазон адресов внутри VPN-сети также должен отличаться от остальных экземпляров, поэтому укажем:
Для хранения выданных клиентам адресов, как и для логов, также следует использовать отдельные файлы:
Mikrotik игнорирует опцию настройки шлюза по умолчанию, но мы все-таки советуем добавить данную опцию, так как подключаться к данному серверу могут и иные клиенты.
Передадим собственные DNS:
Параметры проверки активности:
Обязательно выключим дополнительную TLS-аутентификацию:
И укажем параметры шифра, выключив его согласование, RouterOS поддерживает только AES128/192/256 и Blowfish 128:
Обязательно отключаем все опции сжатия:
Убеждаемся в наличии опций понижения прав:
И за сохранение доступа к ключам и адаптерам:
Укажем свой комплект файлов лога:
При использовании протокола TCP обязательно закомментируем опцию:
Сохраним файл конфигурации.
Чтобы обеспечить автоматический запуск всех серверных конфигураций OpenVPN откроем в /etc/default/openvpn и раскомментируем в нем строку:
Затем перечитаем конфигурацию юнитов systemd:
Теперь уже можно запустить наш новый экземпляр, но мы пока не будем этого делать, так как нужно перенастроить брандмауэр.
Настройка брандмауэра и маршрутизации
Очевидно, что нам нужно разрешить входящий трафик на порт OpenVPN и транзитный трафик для tun-адаптеров, также потребуется отдельное правило для маскарадинга. В итоге ваш файл /etc/nat должен будет выглядеть следующим образом:
На что следует обратить внимание? Для каждого сервера нужно разрешающее правило в цепочке INPUT, в нашем случае в секции Разрешаем подключения к OpenVPN добавлено два правила для входящих UDP 1194 и TCP 1194. Аналогично следует создать для каждой VPN-сети свое правило маскарадинга в секции Включаем маскарадинг для локальной сети.
В правилах цепочки FORWARD мы заменили tun0 на tun+, что теперь распространяет действие правил на все туннельные интерфейсы.
Если вы используете Oracle Cloud, то не забудьте создать разрешающее правило для входящих TCP 1194 в настройках вашей виртуальной сети:
Теперь можно перезапустить службу OpenVPN и убедиться, что поднялись два туннельных интерфейса:
Настройка клиентов OpenVPN
Если вы будете настраивать в качестве клиента Mikrotik, то вам потребуется только ключевая пара клиента и, опционально, сертификат CA, для проверки подлинности сервера. Для создания ключа клиента перейдите в директорию центра сертификации и загрузите переменные:
Затем выпустите сертификат клиента:
Полученные файлы и сертификат CA скопируем в домашнюю директорию:
И сменим их владельца на вашего основного пользователя, чтобы он мог спокойно скопировать их через FTP или SFTP (по умолчанию владелец файлов root). В нашем случае это пользователь ubuntu.
Если же будет подключаться иной клиент, то ему потребуется клиентский файл конфигурации, можете использовать как образец конфигурацию клиента созданную нами в предыдущей статье. В него потребуется внести следующие изменения: изменить протокол на TCP
и выключить сжатие:
Теперь что касается производительности. OpenVPN через TCP имеет гораздо более высокие накладные расходы, особенно на плохих каналах. На хороших разница обычно невелика, и вы скорее упретесь в иные ограничения. Мы выполнили два замера для нашего сервера в Oracle Cloud, первый для UDP:
Как видим, в нашем случае разница абсолютно незаметна и можно не особенно переживать за возможные потери пропускной способности. Но не следует забывать, что при тестировании использовались хорошие широкополосные каналы, в иных ситуациях, например, с мобильными клиентами, результаты могут существенно отличаться.
Соединение нескольких офисов в одну сеть с помощью OpenVPN
Итак. Допустим что у некоторой фирмы есть несколько офисов в различных точках города (возможно даже земного шара — не суть важно) и нам нужно обеспечить максимально простой способ взаимодействия локальных сетей различных офисов между собой. Неплохим решением этой задачи будет объединение этих сетей посредством OpenVPN.
Итак. Уточним начальные условия:
Центральный офис (office-0):
Сервер под управлением Ubuntu Linux. Три сетевых интерфейса: eth0, eth1, eth2. Конфигурация следующая:
- eth0: внешний интерфейс, имеющий реальный ip-адрес a.b.c.d.
- eth1: первая локальная сеть: 192.168.1.1/24.
- eth2: вторая локальная сеть: 192.168.2.1/24.
Под управлением Mandriva Linux. Два интерфейса:
- eth0: внешний интерфейс, имеющий доступ к адресу a.b.c.d (каким либо образом).
- eth1: локальная сеть: 192.168.3.1/24.
Сервер полностью аналогичен серверу в первом офисе, за исключением eth1: там адрес 192.168.4.1/24.
Объединять мы будем сервера в виртуальную сеть 192.168.10.0/24. Поэтому на всех серверах должен быть настроен NAT не только для «своих» сетей, но и для сети 192.168.10.0/24.
Будем считать что всё это уже сделано. Приступаем к установке и настройке OpenVPN-сервера:
Создаём файл конфигурации /etc/openvpn/server.conf следующего содержания:
Создаём каталог, в котором будут хранится индивидуальные настройки клиентов:
Копируем скрипты для генерации ключей и создаём ключи:
Входе выполнения этих команд будет задан ряд вопросов. Ответы на них вобщем-то очевидны, поэтому заострять на них внимание не будем.
Далее создаём файлы /etc/openvpn/ccd/office-1 и /etc/openvpn/ccd/office-2. Содержание первого:
На этом настрока сервера завершена. Перезапускаем его:
Убеждаемся что поднялся интерфейс tap0:
Переходим к настройке офисов. Рассмотрим только один. Второй будет сделан аналогично, за исключением имён сертификатов.
Создаём файл конфигурации /etc/openvpn/client.conf:
Далее нам нужно поместить файлы office-1.* и ca.crt из каталога /etc/openvpn/keys сервера в каталог /etc/openvpn/keys клиента.
После этого запускаем сервис:
Убеждаемся что поднялся интерфейс:
После настройки обоих офисов можно убедиться в работе сети попробовав пинговать из одного офиса какой-нибудь компьютер, расположенный в другом офисе.
На этом всё. Более подробную информацию можно найти в документации по openvpn.
Комментарии:
> ping-restart в конфиг, для автоматического востановления кана после разрыва связи
Оно по умолчанию итак включено и работает. Проверено. 🙂
Ты не там ищешь. В генте оно похоже как и в мандриве — /usr/share/openvpn
И ключи из examples используют только самоубийцы:)
Небольшой вопрос: как быть, если между двумя офисами два канала связи, которые периодически обрываются?
Я подозреваю, что нужно использовать метрики и поднимать два маршрута с разными метриками до офиса. Будет ли автоматически удаляться route на оборванном соединении и восстанавливаться при появлении? Будут ли обрываться уже установленные соединения в момент изменения активного роута?
нифуя:) всё куда как красивше. набери:
там есть много интересного на эту тему. например как можно указать два разных сервера, чтобы в случае неудачи с первым происходило соединение со вторым.
то есть делаешь так: свой сервер подключаешь обоим каналам и получается что у него два внешних ip. ну и дальше настраиваешь клиентам чтобы он коннектился на ip1 а в случае неудачи уходил на ip2 🙂
Anonymous 2009-08-23 23:35:56 (#)
Anonymous 2010-10-14 15:36:02 (#)
в настройке клиента тока внеси корретикты:
вместо
ca ca.crt
с путем
ca /etc/openvpn/keys/ca.crt
а то ругается ) а так все ок )
да, и кто юзает фаерволы типа IPTABLES надо разрешить пакетики..
спасибо за статью!
Anonymous 2010-10-14 15:40:12 (#)
Anonymous 2011-05-18 12:02:17 (#)
1)как уже выше написали:
в настройке клиента тока внеси корретикты:
вместо
ca ca.crt
с путем
ca /etc/openvpn/keys/ca.crt
2)зачем нужна эта строка в конфиге server.conf?
push «route 192.168.10.0 255.255.255.0 192.168.10.1»
она же перекрывает действие настройки client-to-client, прописывая еще один маршрут с назначением 192.168.10.0, в результате чего не пингуются клиенты по айпишникам виртуальной сети. Если же убрать эту строку то маршрут выглядит так: 192.168.10.0 255.255.255.0 0.0.0.0 и все машины видят друг друга по виртуальным айпи отлично..
1)как уже выше написали:
в настройке клиента тока внеси корретикты:
вместо
ca ca.crt
с путем
ca /etc/openvpn/keys/ca.crt
Угу. Правильно.
2)зачем нужна эта строка в конфиге server.conf?
push «route 192.168.10.0 255.255.255.0 192.168.10.1»
Да. Тут либо client-to-client, либо вот эта строчка. Но на самом деле она не мешает если на центральной машине разрешена пересылка пакетов для 192.168.10.0/24 через соответствующий tap-интерфейс. Примерно вот так:
Anonymous 2013-06-27 13:27:31 (#)
спасибо за статью) изложено отлично.
я только не понял почему тут используется TAP , а не TUN ?
tap — если я все верно понимаю для мостов.
но у нас маршрутизация так?
Anonymous 2013-06-28 12:59:25 (#)
спасибо за статью) изложено отлично.
я только не понял почему тут используется TAP , а не TUN ?
tap — если я все верно понимаю для мостов.
но у нас маршрутизация так?
Чем отличаются виртуальные устройства tun и tap?
О. TUN — туннель, соединение по которому указывается по типу: локальный IP удаленный IP. Например, при явном указании ifconfig:
—ifconfig 10.3.0.2 10.3.0.1
в этом примере 10.3.0.2 — локальный IP, 10.3.0.1 — удаленный IP
TAP — эмулирует виртуальную ethernet карточку, для которой требуется указывать локальный IP и маску подсети. Например:
—ifconfig 10.3.0.2 255.255.255.0
Anonymous 2013-06-28 14:54:46 (#)
Уважаемый Вадим подскажите пожалуйста, как сервер сопоставляет клиентов и сети за ними?
Например серваку пришел пакет для хоста 192.168.3.5
как он понимает, что пакет надо переслать клиенту 192.168.1.101?
Из пересылаемых клиенту данных, тех которые в /ccd/klient?
У уважением, Валерий.
Уважаемый Вадим подскажите пожалуйста, как сервер сопоставляет клиентов и сети за ними?
Например серваку пришел пакет для хоста 192.168.3.5
как он понимает, что пакет надо переслать клиенту 192.168.1.101?
Из пересылаемых клиенту данных, тех которые в /ccd/klient?
У уважением, Валерий.
openvpn в режиме «dev tap» создаёт сеть представляющую по сути виртуальный ethernet со всеми сопутствующими вещами, включая MAC-адреса. пакеты от клиента к клиенту хотя и идут через сервер, но если смотреть немного выше то пакет с 192.168.10.102 к 192.168.10.101 идёт напрямую, минуя 192.168.10.1.
Поскольку машина 192.168.10.102 знает что маршрутом для 192.168.3.5 является адрес 192.168.10.101, она получает MAC машины 192.168.10.101, и шлёт на него пакет с dstIP=192.168.3.5.
192.168.10.101 получив такой пакет принимает решение о дальнейших действиях руководствуясь своей таблицей маршрутизации.
Сам OpenVPN-сервер в данном примере распоряжается только маршрутизацией на втором уровне (по MAC-адресам).
Вообще рекомендую почитать про маршрутизации подробнее. Например неплохо написано тут
Anonymous 2013-07-02 16:51:04 (#)
спасибо Вам, что так быстро ответили)
Ваш ответ был мне очень полезен.
но возможно я несколько неточно задал вопрос
откуда клиенты берут маршруты я понял.
поясню подробней:
вот допустим хост в первой подсети(192.168.1.5) лезет по ip на шару хосту в 192.168.3.5
пакет с адресом назначения 192,168,3,5 приходит на vpn сервер -> натится попадает в подсеть 192.168.10.0
вот тут я не понимаю как сервер переслав пакет в сеть 192.168.10.0 сопоставляет что 192.168.10.101 шлюз 192.168.3.0?
Что его надо послать именно этому клиенту?
он же не делает широковещательную рассылку?)))
я так понял что на сервер надо прописать
route 192.168.3.0/24 192.168.10.101
route 192.168.4.0/24 192.168.10.102
подправьте если заблуждаюсь.
С уважением Валерий.
я так понял что на сервер надо прописать
route 192.168.3.0/24 192.168.10.101
route 192.168.4.0/24 192.168.10.102
подправьте если заблуждаюсь.
С уважением Валерий.
это нужно сделать если надо чтобы машины из центрального офиса могли использовать ресурсы из сетей филиалов. во всех остальных случаях будет замечательно работать и без этого:)