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 на стороне сервера.
