OpenVPN PSK: Site-to-Site инструкция для обсуждения

rubic

Подключаем второй филиал и обеспечиваем связь филиалов друг с другом.

Как уже говорилось выше, для подключения нового клиента нам придется создать новый экземпляр сервера OpenVPN на pfSense1. Переходим в меню VPN – OpenVPN. На вкладке Server нажимаем кнопку “+” для добавления нового экземпляра сервера OpenVPN. Настройка параметров аналогична настройке первого экземпляра, за исключением параметров: Local Port (здесь ставим например 1195), Description (OVPNS2), Tunnel Network (выбираем 10.0.9.0/24) и Remote Network (здесь ставим сеть филиала 2 – 192.168.30.0/24). Все эти параметры должны быть отличны от параметров первого экземпляра. Также будет автоматически сгенерирован общий ключ для подключения к OVPNS2.

Так же как и в случае с первым экземпляром, на WAN pfSense1 необходимо создать разрешающее правило для UDP пакетов извне на локальный порт нового экземпляра (1195).

Настраиваем клиента на pfSense3 филиала 2.

Здесь опять же все аналогично настройке клиента в первом филиале, за исключением параметров: Server Port (1195), Description (OVPNC2) и Tunnel Network (10.0.9.0/24). Так же как и в первом филиале вставляем в поле Shared Key новый общий ключ, и создаем разрешающее правило в Firewall – Rules на вкладке OpenVPN.

После поднятия туннеля компьютеры филиала 2 пингуют компьютеры головного офиса и наоборот, но нет связи между филиалами. Для того, чтобы филиалы “видели” друг-друга, необходимо в настройках клиента первого филиала в Advanced Configuration вписать директиву:

route 192.168.30.0 255.255.255.0

т. е. маршрут через туннель в сеть второго филиала. А в настройках клиента второго филиала, соответственно:

route 192.168.20.0 255.255.255.0

т. е. маршрут в сеть первого филиала.

Как видим, маршрутизация в режиме PSK очень и очень проста. По сути между сервером и клиентом создается самое настоящее соединение PtP (точка-точка). Один адрес (10.0.8.1) принадлежит серверу, второй (10.0.8.2) - клиенту, причем, это не виртуальные адреса. Это все равно как если бы в pfSense вставили еще один сетевой адаптер и дали ему адрес. Так же, как и в случае с обычным адаптером, весь его трафик повинуется системной таблице маршрутов и, соответственно, легко маршрутизируется в любые подключенные сети, если это не запрещено правилами firewall. Однако, не следует назначать адрес OpenVPN интерфейса вручную, а также вручную прописывать для него статические маршруты. Первое происходит автоматически, второе - с помощью директив route в настройках Advanced OpenVPN или в поле Remote Network. Подчеркну последний момент:

Когда вы прописываете 192.168.20.0/24 в Remote Network - это абсолютно аналогично тому, что вы напишете route 192.168.20.0 255.255.255.0 в поле Advanced и приводит к тому, что в системной таблице маршрутов появляется новый маршрут в сеть 192.168.20.0/24 через туннель OpenVPN. Это справедливо и для сервера, и для клиента.

Когда вы прописываете 192.168.10.0/24 в Local Network сервера - это абсолютно аналогично тому, что вы напишете push "route 192.168.10.0 255.255.255.0" в поле Advanced и приводит к тому, что в системной таблице маршрутов клиента появляется новый маршрут в сеть 192.168.10.0/24 через туннель OpenVPN. Это справедливо только для сервера и это не работает в режиме PSK! Во всяком случае у меня не работает - в таблице маршрутов клиента ничего не появляется, хотя подтверждения этому факту в документации я не нашел.

Также следует сказать, что в режиме PSK не нужны никакие Client specific overrides и iroute в них, поскольку клиент всегда один.

Не дублируйте то, что вы пишете в Remote Network директивами route и не создавайте никаких override, если ваш OpenVPN работает в режиме PSK.

rubic

OSPF

Вот. Возвращаясь к предыдущему посту, можно ли сделать связь между офисами без всех этих Remote Networks и route? А как же!
Более того, можно еще и обеспечить резервирование канала, и поможет нам в этом OSPF.

OSPF - это когда, коротко говоря, есть граф, вершинами которого являются маршрутизаторы, а ребрами - линки между ними. OSPF, глядя на граф, может найти оптимальный маршрут между двумя маршрутизаторами. При этом он учитывает то, что какие-то линки могут быть упавшими. Остальное - в документации.

Есть psSense1 головного офиса, у которого 2 канала в интернет: WAN1 - 192.0.2.2 и WAN2 - 198.51.100.2. Есть филиал с единственным каналом в интернет: WAN - 203.0.113.2.

В головном офисе настроено 2 экземпляра сервера OpenVPN:

OVPNS1 на WAN1:1194, Tunnel Network 10.0.8.0/24
OVPNS2 на WAN2:1195, Tunnel Network 10.0.9.0/24

В филиале настроено 2 клиента OpenVPN:

OVPNS1 на 192.0.2.2:1194, Tunnel Network 10.0.8.0/24
OVPNS2 на 198.51.100.2:1195, Tunnel Network 10.0.9.0/24

Ни в головном офисе, ни в филиале на серверах и клиентах не прописаны ни Remote Network, ни какие-либо route.

Филиал хочет при падении одного из каналов в головном офисе автоматически переключаться на другой, компы офиса и филиала должны видеть друг-друга.

Ставим и в офисе и в филиале (System -> Packages, вкладка Available Packages) пакет Quagga OSPF. В первую очередь необходимо настроить интерфейсы, на которых будет работать OSPF (Services -> Quagga OSPFd, вкладка Interface Settings) "+" добавляем интерфейсы.

В головном офисе:

первый интерфейс - OVPNS1:

второй интерфейс - OVPNS2:

И основные параметры OSPF (вкладка Global Settings):

В филиале:

первый интерфейс - OVPNC1:

второй интерфейс - OVPNC2:

И основные параметры:

Area везде одна: 1.1.1.1, а Router ID - разные в офисе и филиале (я просто взял их публичные IP). Для наших нужд и там и там можно писать что попало, хотя знатоки OSPF будут смеяться.
Галка Redistribute connected subnets заставляет роутеры обмениваться информацией о подключенных к ним сетям, т.е. маршрутами в эти сети, что нам и нужно. При этом внизу в Disable Redistribution прописаны сети, инфой о которых делиться не надо. Во-первых, наши 2 pfSense и так уже в курсе об этих сетях, во-вторых возможны чудеса, так что лучше не рисковать.

После того как OSPF настроен и в офисе и в филиале, роутеры устанавливают отношение соседства (все скрины из филиала):

И получают друг у друга маршруты:

Видим, что филиал теперь знает путь в локалку головного офиса:

У линка OVPNS1 - OVPNC1 метрика меньше чем у OVPNS2 - OVPNC2 поэтому все идет сейчас через него. Но если линк оборвать в головном офисе (отключить WAN1), то маршрутизаторы по оставшемуся линку посредством OSPF договорятся, что линк упал и перестроят таблицы. Все пойдет по OVPNS2 - OVPNC2. Это довольно быстро происходит, пропадает буквально один пинг))

vibperson

Спасибо за руководство!
Попробовал настроить всё как у вас
Виртуал сеть 10.0.8.0/24
Сеть сервера овпн 10.10.10.0/24
Сеть клиента овпн 192.168.61.0/24

Сервер находится в рабочей сети тоже на виртуалке (ван по дхсп от роутера, на лан статик ип)
Клиент находится на виртуалке вмваре на моем пк (только ван интерфэйс с дхсп)
Подключение проходит нормально, но пинга так и нет (пробовал из консоли виртуалки)

Вот скриншоты диагностики маршрутизации

Сервер

Клиент

Красота, молодец! Только еще додумать надо как инет пустить туда ;)

dvserg

Поле сервера Local Network не заполнено.

rubic

@vibperson:

Спасибо за руководство!
Попробовал настроить всё как у вас
Виртуал сеть 10.0.8.0/24
Сеть сервера овпн 10.10.10.0/24
Сеть клиента овпн 192.168.61.0/24

Сервер находится в рабочей сети тоже на виртуалке (ван по дхсп от роутера, на лан статик ип)
Клиент находится на виртуалке вмваре на моем пк (только ван интерфэйс с дхсп)
Подключение проходит нормально, но пинга так и нет (пробовал из консоли виртуалки)

Вот скриншоты диагностики маршрутизации

Сервер

Какая-то муть с OpenVPN на сервере (на клиенте все OK). Точно на сервере Tunnel Network 10.0.8.0/24?
Вот так по идее должно быть:

rubic

@Bansardo:

Красота, молодец! Только еще додумать надо как инет пустить туда ;)

Для того, чтобы филиал выходил в интернет через головной офис, нужно пустить весь трафик, идущий из LAN филиала в интернет, через туннель. Сделать это можно только назначив этому трафику новый gateway. Но, так как gateway в pfSense назначаются только интерфейсам, нужно объявить интерфейс OpenVPN в pfSense явно:

На клиенте идем в Interfaces -> (assign), жмем "+" и выбираем ovpnc1

Жмем "Save", переходим в Interfaces -> OPT1 и ставим галку в Enable Interface.

Даем новому интерфейсу имя, больше ничего не меняем. Жмем "Save" - "Apply changes", идем в VPN -> OpenVPN на вкладку Client и жмем "е" для редактирования клиента. Ничего не меняем, посто жмем "Save" внизу, чтобы перезапустить туннель.
Теперь в Status -> Gateways должна наблюдаться такая картина:

Если в System -> General Setup прописан какой-то левый DNS сервер, то его тоже надо пустить через новый gateway:

Переходим в Firewall -> Rules на вкладку LAN и приводим правила к такому виду:

То есть дефолтному правилу мы назначили новый gateway, а над дефолтным сделали еще правило для доступа из LAN к DNS Forwarder'у pfSense, иначе бы эти запросы полетели в новый gateway т.е. в никуда.

На этом настройка клиента с некоторыми оговорками закончена.

На сервере (т.е. в головном офисе) заходим в Firewall -> NAT на вкладку Outbound и если стоит Automatic outbound NAT rule generation, то переводим в Manual и сохраняем. Добавляем правило:

Где 192.168.20.0/24 - локальная сеть клиента (т.е. филиала).

На этом все, компы филиала выходят в интернет через головной офис.

Если на pfSense филиала изначально интернета нет, а просто провайдер дал вам виртуальный канал для связи с головным офисом и вы в этом канале сделали еще канал OpenVPN, то сам pfSense филиала при таких настройках в интернет (например за пакетами или обновлениями) не попадет. Чтобы он тоже ходил в интернет через туннель заходим на нем в Firewall -> Rules на вкладку Floating и добавляем правило:

Здесь 192.0.2.2 - WAN адрес головного офиса, остальное должно быть точно как на картинке. Это правило заворачивает трафик самого pfSense филиала в туннель и он попадает в головной офис. Там его еще нужно проNATить. На pfSense головного офиса опять заходим в Firewall -> NAT на вкладку Outbound и создаем правило:

Где 203.0.113.2 - WAN адрес филиала. Но pfSense головного офиса так же не знает что ответные пакеты на WAN адрес филиала теперь нужно посылать через туннель. Заходим на нем в свойства OpenVPN сервера и в Advanced пишем route 203.0.113.2 255.255.255.255.

Это все. Если кто-нибудь скажет мне, что это не работает, пусть будет готов запостить столько же скриншотов, сколько я

Сегодня протестирую дополнение!

@dvserg:

Поле сервера Local Network не заполнено.

Оно не должно быть заполнено для Shared VPN

Так, вобщем после тго как я прописал в генерале ДНС, интернет появился на ван интерфейсе и на виртуальном интерфейсе… с лан не хочет пинговать... в чем тут дело?
Плюс сейчас нарвался на подвисания веб интерфейса... интернета так и нет...
Более того, пошли какието непонятки на сервере... ничего в адвансед не написано а в логах сразу
openvpn[48071]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
статус канал не пишет, в табличке заполнена только первая срочка… не могу понять что творится

rubic

Обновил 3 пост топика OSPF!

dvserg

@rubic:

Обновил 3 пост топика OSPF!

Спасибо за развернутый мануал.

http://forum.pfsense.org/index.php/topic,58764.msg316116.html#msg316116
Вот так вот подвисло все

rubic

@dvserg:

Спасибо за развернутый мануал.

Не поверишь, но у меня нет в продакшене ни ovpn, ни ospf. Просто самому стало интересно и вопросы эти в последнее время как-то часто стали вставать в сообшестве.
Если можно, закрепи тему вверху или в FAQ. Чую не раз еще к этому вернемся))

dvserg

@rubic:

@dvserg:

Спасибо за развернутый мануал.

Не поверишь, но у меня нет в продакшене ни ovpn, ни ospf. Просто самому стало интересно и вопросы эти в последнее время как-то часто стали вставать в сообшестве.
Если можно, закрепи тему вверху или в FAQ. Чую не раз еще к этому вернемся))

Уже в FAQ. Аналогично, хотелось заняться этой темой, но времени катастрофически не хватает.

rubic

@dvserg:

@rubic:

@dvserg:

Спасибо за развернутый мануал.

Не поверишь, но у меня нет в продакшене ни ovpn, ни ospf. Просто самому стало интересно и вопросы эти в последнее время как-то часто стали вставать в сообшестве.
Если можно, закрепи тему вверху или в FAQ. Чую не раз еще к этому вернемся))

Уже в FAQ. Аналогично, хотелось заняться этой темой, но времени катастрофически не хватает.

О! Спасиб! Из-за такой зарплаты что ли у меня времени вагон? Надо пересмотреть приоритеты))

Инструкция и правда очень хорошая, счас ее протестим на все и будет серьезный мануал!

@rubic:

Переходим в Firewall -> Rules на вкладку LAN и приводим правила к такому виду:

То есть дефолтному правилу мы назначили новый gateway, а над дефолтным сделали еще правило для доступа из LAN к DNS Forwarder'у pfSense, иначе бы эти запросы полетели в новый gateway т.е. в никуда.

Этого я не пойму, как антилок по дефолту вынести из фаервола?
У меня на виртуальном интерфейсе интернет есть, а вот на лане и на ване нету…
Ping output:
PING www.ru (194.87.0.50) from 192.168.1.10: 56 data bytes

--- www.ru ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Плюс, если не прописать в генерале днс по дефолту, то ничего не получится даже на интерфейса виртуальном у клиента

rubic

Пока объяснял уже сам все понял. Дела… Сегодня заставил наконец бегать OSPF по OpenVPN между работой и домашним микротиком. Полгода назад неделю на это убил безрезультатно. Пришлось править quagga_ospfd.inc

короче счас все опишу что творится ) погодите
Клиент:

Сервер:

Творится следующее:
На клиентской части сам пфсенс в нет невыходит (я немогу смотреть пакеты)
Со стороны клиента подсеть не может выйти в интернет…
ДНС сервера не выдаются...