OpenVPN PKI: Site-to-Site инструкция для обсуждения
-
Режим “Peer to Peer (SSL/TLS)” (PKI) несколько более сложен в настройке, чем PSK, но предоставляет большую безопасность, гибкость конфигурирования и отсутствие необходимости заводить отдельный экземпляр сервера OpenVPN для каждого клиента.
это та же схема клиент-сервер, что и в топике о режиме PSK (http://forum.pfsense.org/index.php/topic,58846.0.html), изменилась лишь адресация в туннеле. Ее мы обсудим позже, а сейчас создадим туннель для соединения сетей головного офиса и филиала.
На сервере (pfSense1) переходим в меню System -> Cert Manager на вкладку CAs и нажимаем “+” для создания нового центра сертификации:
Сохраняем и экспортируем сертификат нового центра сертификации в файл internal-ca.crt.
Переходим на вкладку Certificates. Создаем сертификат сервера OpenVPN:
И клиента:
Экспортируем сертификат и ключ клиента в файлы: ovpnc1-cert.crt и ovpnc1-cert.key, соответственно.
Переходим в меню VPN -> OpenVPN на вкладку Server и добавляем новый сервер кнопкой “+”:
Переходим на вкладку Client Specific Overrides и кнопкой “+” добавляем настройки специфичные для нашего клиента:
Переходим в меню Firewall – Rules и на вкладке WAN добавляем правило для доступа извне к созданному OpenVPN серверу:
Переходим на вкладку OpenVPN и добавляем правило:
На этом настройка сервера закончена. Переходим к настройке клиента (pfSense2). В первую очередь необходимо импортировать сертификаты. В меню System -> Cert Manager на вкладке CAs нажимаем “+” для импорта сертификата центра сертификации и вставляем в поле Certificate data содержимое файла internal-ca.crt:
Сохраняем и переходим на вкладку Certificates, где импортируем клиентский сертификат, вставляя содержимое файлов ovpnc1-cert.crt и ovpnc1-cert.key в поля Certificate data и Private key data, соответственно:
В меню VPN –> OpenVPN pfSense1 головного офиса нажимаем кнопку “е” редактирования созданного нами OpenVPN сервера. Копируем автоматически созданный Shared key в буфер обмена:
На pfSense2 филиала в меню VPN – > OpenVPN на вкладке Client кнопкой “+” создаем новый клиента OpenVPN:
Через несколько секунд в меню Status – OpenVPN видим успешно подключившийся клиент:
Переходим в меню Firewall – Rules и на вкладке OpenVPN создаем такое же правило, как на сервере:
Таблица маршрутов сервера (pfSense1 головного офиса):
Таблица маршрутов клиента (pfSense2 филиала):
Сети головного офиса и филиала доступны друг другу через созданный туннель.
Как видите, какие либо настройки маршрутизации на OpenVPN клиенте полностью отсутствуют. Заполнив поле Local Network на сервере, мы передали маршрут в сеть головного офиса клиенту. Напомню, это действие абсолютно аналогично тому, что на сервере в поле Advanced мы написали бы: push “route 192.168.10.0 255.255.255.0” или тому, что на клиенте в Remote Network написали: 192.168.10.0/24, или на клиенте в поле Advanced: route 192.168.10.0 255.255.255.0. Но и это не все. Мы могли бы написать: push “route 192.168.10.0 255.255.255.0” в Client Specific Overrides для ovpnc1 на сервере и это привело бы к тому же результату.
OpenVPN в режиме PKI позволяет централизованно и гибко управлять клиентами. Все можно сделать на сервере, не прописывая route или Remote Network на каждом клиенте. Все можно настроить индивидуально в Client Specific Overrides. Для сравнения, push “route 192.168.10.0 255.255.255.0” в поле Advanced сервера действует глобально на всех клиентов.Теперь вернемся к адресации в туннеле. Вообще говоря, OpenVPN поддерживает 3 топологии сети: p2p, net30 и subnet. Задать топологию сети можно в поле Advanced сервера. Например:
topology subnet
С топологией p2p мы уже знакомы по настройке сервера в режиме PSK. В режиме PKI по умолчанию используется топология net30. Создана она для обхода ограничения TAP-Win32 драйвера Microsoft в режиме эмуляции TUN интерфейса. Драйвер требует, чтобы в туннеле клиент и сервер находились в одной /30 подсети. Т.е. например сервер 10.0.8.1, клиент - 10.0.8.2. Ясно, что при таком ограничении сервер не сможет принимать подключения от нескольких клиентов, т.к. сеть /30 вмещает всего 2 эффективных адреса. Чтобы Windows могла работать с OpenVPN, на машине клиенте, образно говоря, создается виртуальный сервер, а на машине сервере – виртуальный клиент:
10.0.8.1 <–p2p--> 10.0.8.2 <=============p2p==============> 10.0.8.5 <--p2p--> 10.0.8.6
Адреса 10.0.8.1 и 10.0.8.2 укладываются в подсеть /30 и фактически находятся на pfSense1. При этом адрес 10.0.8.2 чисто виртуальный и символизирует собой удаленного клиента, в то время как адрес 10.0.8.1 – реальный и принадлежит локальной машине.
Аналогично адреса 10.0.8.5 и 10.0.8.6 укладываются в подсеть /30 и фактически находятся на pfSense2. При этом 10.0.8.5 - виртуальный адрес, символизирующий удаленный сервер, а адрес 10.0.8.6 – реальный, принадлежащий локальной машине.Если вы не собираетесь подключать Windows клиентов к OpenVPN серверу на pfSense, то можно использовать новую топологию subnet. В ней, если в настройках сервера в Tunnel Network стоит 10.0.8.0/24, то сервер получает адрес 10.0.8.1, а клиенты последовательно адреса 10.0.8.2, 10.0.8.3, …, 10.0.8.254. Одним словом, subnet.
Если же вы собираетесь использовать OSPF над вашими туннелями в режиме PKI, то топологию subnet использовать нужно, т.к. в net30 OSPF работать не хочет.Наконец, зачем была нужна директива: iroute 192.168.20.0 255.255.255.0 в Client Specific Overrides для клиента ovpnc1, при том, что мы и так прописали сеть клиента в Remote Network на сервере?
То, что мы написали в Remote Network, лишь говорит ядру системы, что сеть 192.168.20.0/24 находится за шлюзом 10.0.8.2 на интерфейсе ovpns1. Но, как мы знаем, за ним может находится множество клиентов OpenVPN. Директивой iroute мы даем знать серверу OpenVPN, за каким именно клиентом находится та или иная сеть. -
Графическая иллюстрация топологии net30:
-
Графическая иллюстрация топологии net30:
Спасибо! А откуда картинка? Сам бы почитал, ибо инфы немного. В инструкции описал свое понимание, про "прилегающие" интерфейсы не слышал.
-
Отсюда, вестимо. Кстати, там очень много полезного и в русле темы.
-
Спасибо за столь развернутые инструкции! Однозначно в FAQ, ибо лучше, как говорится, один раз увидеть.
-
Автору спасибо не только за инструкции, но и за помощь. Смог все объяснить на пальцах! Теперь с такой инструкцией ни у кого не должно быть проблем!
-
Да за инструкцию спасибо, сбросил всё на ноль по вашей предыдущей инструкции поднял заработало. Однако попробовал поднять в режиме Remote Access (SSL/TLS) для доступа клиентов из под винды, коннект проходит, а пинги опять не идут. :( Может подскажете, что может быть или для этого типа ещё инструкцию сделаете?
Вот на клиенте маршрутизация
IPv4 таблица маршрутаАктивные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.122 10
10.0.8.0 255.255.255.0 10.0.8.5 10.0.8.6 30
10.0.8.4 255.255.255.252 On-link 10.0.8.6 286
10.0.8.6 255.255.255.255 On-link 10.0.8.6 286
10.0.8.7 255.255.255.255 On-link 10.0.8.6 286
10.10.10.0 255.255.255.255 10.0.8.5 10.0.8.6 30
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 On-link 192.168.0.122 266
192.168.0.122 255.255.255.255 On-link 192.168.0.122 266
192.168.0.255 255.255.255.255 On-link 192.168.0.122 266
192.168.61.0 255.255.255.0 On-link 192.168.61.1 276
192.168.61.1 255.255.255.255 On-link 192.168.61.1 276
192.168.61.255 255.255.255.255 On-link 192.168.61.1 276
192.168.132.0 255.255.255.0 On-link 192.168.132.1 276
192.168.132.1 255.255.255.255 On-link 192.168.132.1 276
192.168.132.255 255.255.255.255 On-link 192.168.132.1 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.0.122 266
224.0.0.0 240.0.0.0 On-link 10.0.8.6 286
224.0.0.0 240.0.0.0 On-link 192.168.132.1 276
224.0.0.0 240.0.0.0 On-link 192.168.61.1 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.0.122 266
255.255.255.255 255.255.255.255 On-link 10.0.8.6 286
255.255.255.255 255.255.255.255 On-link 192.168.132.1 276
255.255.255.255 255.255.255.255 On-link 192.168.61.1 276 -
Сеть за сервером 10.10.10.0? Если так то почему:
10.10.10.0 255.255.255.255 10.0.8.5 10.0.8.6 30 ??
-
Кстате, ДНС пришлось в ручную прописывать у клиентского сенса в генерал сеттингс… Сам не выдает. Так и не смог решить эту проблему
-
Что-то не разобрался - если на сервере pfSense1 не указывать Remote Network: 192.168.20.0/24, то как на этом сервере указать маршрутизацию в эту сеть ?
Ситуация - у меня два site-to-site, в одном пусть условно сеть 192.168.20.0/24, в другом 192.168.30.0/24, как маршрутизацию указать первому серверу в эти две сети ?
-
Что-то не разобрался - если на сервере pfSense1 не указывать Remote Network: 192.168.20.0/24, то как на этом сервере указать маршрутизацию в эту сеть ?
Ситуация - у меня два site-to-site, в одном пусть условно сеть 192.168.20.0/24, в другом 192.168.30.0/24, как маршрутизацию указать первому серверу в эти две сети ?
на pfSense1 в Advanced вставить:
route 192.168.20.0 255.255.255.0; route 192.168.30.0 255.255.255.0
в Client Specific Overrides -> Advanced:
iroute 192.168.20.0 255.255.255.0 для первого клиента, и:
iroute 192.168.30.0 255.255.255.0 - для второго
-
на pfSense1 в Advanced вставить:
route 192.168.20.0 255.255.255.0; route 192.168.30.0 255.255.255.0
в Client Specific Overrides -> Advanced:
iroute 192.168.20.0 255.255.255.0 для первого клиента, и:
iroute 192.168.30.0 255.255.255.0 - для второго
Вот теперь я понял, в чем суть команды iroute :D
Кажется взлетело и заработало все хозяйство.
-
Спасибо. Сделал по мануалу.
Обе сетки с белыми адресами. внутренние 192.168.0.1 сервер, 192.168.1.1 клиент. Тоннель поднимается, пинги не ходят. Помогите, где туплю. скрины маршрутов прилагаю. Поправочка: со стороны центрального (192.168.0.0) сеть 192.168.1.0 пингуется, все видно. наоборот трасировка доходит только до 10.0.8.1
Спасибо.
-
Спасибо. Сделал по мануалу.
Обе сетки с белыми адресами. внутренние 192.168.0.1 сервер, 192.168.1.1 клиент. Тоннель поднимается, пинги не ходят. Помогите, где туплю. скрины маршрутов прилагаю. Поправочка: со стороны центрального (192.168.0.0) сеть 192.168.1.0 пингуется, все видно. наоборот трасировка доходит только до 10.0.8.1
Спасибо.Маршруты, судя по всему, в порядке. Смотрите в сторону правил firewall для OpenVPN на сервере.
-
Правила как в мануале.
На wan разрешен udp на 1194
на openvpn и связанном с ним opt2 разрешено все всюду.
ничего не понимаю. со стороны центрального офиса видны даже захудалые принтера, со тороны филиала только сам пф. -
Клик о помощи в настройке.
Все сделал как по инструкции, канал OpenVPN поднимается но сети друг друга не видят. Таблица роутирования работает правильно где я мог сделать ошибку схему своего соединения прилагаю.
Заранее благодарен.
[imghttp://forum.pfsense.org/index.php?action=dlattach;topic=59081.0;attach=33465;image[/img]
-
А если убрать роутеры из этой цепочки ? Пускай пфсенсы всем "рулят".
-
Выкинуть немогу так как система нехорошо дружит с 3g модемами у которых новая прошивка, она не видит их как модем.
Возникла другая проблема когда проверяю видят ли сети друг друга по ssh то пинги идут по обе стороны, а пытюсь с рабочей станции или через веб инерфейс все куда-то теряется, настройки делал по инструкции -
нехорошо дружит с 3g модемами у которых новая прошивка, она не видит их как модем.
А переключить модемы в режим "only modem" не пробовали? Должно помочь.
-
Если в таблице маршрутов каждого pfSense присутствует маршрут в соседнюю сеть через ovpn, то еще раз проверить правила firewall на обеих сторонах и наличие iroute в Client specific overrides -> Advanced на стороне сервера.
-
таже бяда. конект есть, но сети не видят друг друга. в таблице маршрутов роуты есть.
-
таже бяда. конект есть, но сети не видят друг друга. в таблице маршрутов роуты есть.
Раз уж есть роуты - проверьте правила fw и включите логирование fw. Т.о. будет видно что и почему блокируется.
-
Я поднял на двух тестовых машинах. На обоих машинах в файрволе в разделах ван/лан/опенвпн одно правило - разрешено всем везде. Толку нет.
-
Я поднял на двух тестовых машинах. На обоих машинах в файрволе в разделах ван/лан/опенвпн одно правило - разрешено всем везде. Толку нет.
Во вкладке Status: System logs: Settings : поставить галку на Log packets blocked by the default rule: Save и , вернувшись в Status: System logs: Firewall, нажать F5 для обновления страницы в браузере. И внимательно смотреть что блокируется. Ибо чудес не бывает.
P.s. На каком этапе "затык" ? Что "говорит" tracert с обеих сторон ?
-
Я поднял на двух тестовых машинах. На обоих машинах в файрволе в разделах ван/лан/опенвпн одно правило - разрешено всем везде. Толку нет.
Во вкладке Status: System logs: Settings : поставить галку на Log packets blocked by the default rule: Save и , вернувшись в Status: System logs: Firewall, нажать F5 для обновления страницы в браузере. И внимательно смотреть что блокируется. Ибо чудес не бывает.
P.s. На каком этапе "затык" ? Что "говорит" tracert с обеих сторон ?
Трасировка говорит что пакеты улетают в свой шлюз и все, дальше не идет. Файервол ничего из подопытных не блокирует. Блокирует левые адреса, не относящиеся к делу.
-
Трасировка говорит что пакеты улетают в свой шлюз и все, дальше не идет. Файервол ничего из подопытных не блокирует. Блокирует левые адреса, не относящиеся к делу.
… и наличие iroute в Client specific overrides -> Advanced на стороне сервера
Это проверяли ?
-
iroute в подсеть клиента прописан
-
iroute в подсеть клиента прописан
А на машинах в клиентской сети случаем никаких fw\антивирусов не задействовано ? Отключите их на время (для проверки). И родной виндовый тоже.
-
да даже шлюзы между собой не пингуются, что уж говорить о клиентах…
-
да даже шлюзы между собой не пингуются, что уж говорить о клиентах…
Удалите всё (и сертификаты тоже) и настройте заново. Сперва без сертификатов - просто по secret key.
-
Здравствуйте.
Совсем я разобраться не могу с ситуацией. Может, Вам будет не трудно натолкнуть меня на путь истинный.
По Вашей инструкции создал туннель между двумя Pfsense. Все между ними прекрасно бегает, но при подключении к серверу второго Pfsense. Ни через первый, ни через второй туннель, ничего не бежит.
Карта сети такая:
Pfsense1:
OpenVpn server: Peer to Peer (SSL/TLS)
local: 172.11.11.0/24
tun: 10.0.8.0/24
Client overrides:
1. stmgate tun-10.0.8.0/24 iroute 172.11.10.0 255.255.255.0
2. skvilgate tun-10.0.8.0/24 iroute 192.168.10.0 255.255.255.0Pifsense2
OpenVpn client: Peer to Peer (SSL/TLS)
local: 172.11.10.0/24
tun: 10.0.8.0/24Pfsense3
OpenVpn client: Peer to Peer (SSL/TLS)
local: 192.168.10.0/24
tun: 10.0.8.0/24Заметил такой момент:
При двух подключенных туннелях, на pfsense1, virtual server у обоих туннелей 10.0.8.2Пробовал в качестве сервера - Remote access (SSL/TLS)
Но при таком конфиге по туннелю даже между двумя Pfsense ничего не проходит ( -
На pfSense1 очистите поле Remote Network а в Advanced напишите: route 172.11.10.0 255.255.255.0;route 192.168.10.0 255.255.255.0
Убедитесь, что в Diagnostics->Routes всех трех pfSense есть маршруты в те локальные сети, в которые каждый из них должен иметь доступ. -
to rubic
А не могли бы вы написать немного вашей замечательной инструкции о том как настроить бридж (dev tap), а то что-то не выходит ничё. Есть 2 сети с одинаковой адресацией, туннель работает, но односторонний какой-то, а хочется что-бы и сеть клиента была доступна с сервера. Слышал, что вроде мост должен помочь. -
Есть 2 сети с одинаковой адресацией
Жесть. Если адреса в сетях одинаковые, т.е. совпадают, как быть с обращением к одному и тому же ресурсу в обеих сетях с одним и тем же адресом?
P.S. Объединение двух локальных сетей с одинаковым номерами сетей на Linux-шлюзе - http://habrahabr.ru/post/117320/
P.P.S. Меняйте адресацию в одной из сетей. -
Есть 2 сети с одинаковой адресацией
Жесть. Если адреса в сетях одинаковые, т.е. совпадают, как быть с обращением к одному и тому же ресурсу в обеих сетях с одним и тем же адресом?
P.S. Объединение двух локальных сетей с одинаковым номерами сетей на Linux-шлюзе - http://habrahabr.ru/post/117320/
P.P.S. Меняйте адресацию в одной из сетей.Спасибо, на той ссылке слишком много букв и не одной картинки ;D я её видел уже.
Сеть досталась от предыдущего спеца. Адреса в сетях не совпадают. Единственное жаль, что диапазон не позволяет на подсети разбить - все в перемешку. Статью находил про бридж, там вроде работает у автора, правда не на pfSense. Сегодня решил попробовать, да вот клиент не конектиться, сообщает про ошибку tls, хотя в настройках сервера флаги tls сняты. Видимо я чего-то не знаю, что-бы OpenVPN через dev tap настроить. Вот и хочу узнать, где там секрет.
Вот тут читал http://skeletor.org.ua/?p=234 -
Читайте тут :
http://forum.pfsense.org/index.php?topic=46984.0
И обратите внимание на :
1. goto System –-> Packages
2. Click the Available Packages Tab
3. Install the OpenVPN tap Bridging Fix package -
Читайте тут :
http://forum.pfsense.org/index.php?topic=46984.0
И обратите внимание на :
1. goto System –-> Packages
2. Click the Available Packages Tab
3. Install the OpenVPN tap Bridging Fix packageСпасибо. Вроде то самое.
В идеале конечно хотелось бы на русском и с пояснениями ;D -
to werter
Что-то я не понял, на клиенте нужно мост сооружать или нет? И с DHCP что делать? Там пишутServer DHCP Start/Stop: You can specify an IP range here. However since its bridging you can leave it blank. Your internal DHCP server will take care of it. I leave them blank. One thing to keep in mind is that a client's IP will not be displayed on the Dashboard Widget if you leave the range blank. I'll be brining this up on the fpsense forums.
не понятно как-то…
у меня во всех сетях статическая адресация, о каком внутреннем DHCP сервере идет речь в тексте? В OPT интерфейсе указал DHCP, но все остальные поля оставил пустыми. В итоге OPT1(DHCP) - 0.0.0.0. Это правильно? Или еще дополнительно нужно DHCP сервер подымать? -
Попытался выполнить всё по писанному - не выходит. Конектится, но виртуальный адрес не получает и соответственно никакие адреса удаленной локальной сети не доступны.
В книге по pfSense пишутПрежде всего убедитесь, что DHCP работает только на основном интерфейсе (с IP адресом), а не на одном из подключаемых в мост.
в инструкции по созданию моста пишут, что нужно создать ОРТ(DHCP) интерфейс который объединить в мост с Lan'ом. Какие-то сплошные противоречия…
Вот еще нашел в тексте книги по pfSense9.5.2.3.3. Отключение моста при начальной загрузке
Вам потребуется добавить в конфигурацию команду которая позволит отключать мост при первоначальной загрузке. Это предотвратит появление петли уровня 2, а мост будет поднят на мастере CARP с помощью скрипта bridgecheck.sh через минуту после загрузки. Над строкой , необходимо добавить следующую строку: <shellcmd>/sbin/ifconfig bridge0 down</shellcmd> Сохраните изменения конфигурационных файлов. Теперь восстановите изменённую конфигурацию на первичном и резервном брандмауэре. Брандмауэры должены перезагрузиться после восстановления конфигурации и нормально работать.Это нужно делать или нет? В мануале об этом речь не велась…
-
Появилось свободное время - вновь вернулся к мосту.
Удалось настроить подключение филиала к главному офису, но компы не видятся ни из офиса ни из филиала. Ip-адрес клиент получает по DHCP в заданном диапазоне. Подскажите в чем может быть проблема? В логи смотрел - вроде всё путём.
В Advanced нужно что нибудь прописывать?
