OpenVPN PSK: Site-to-Site инструкция для обсуждения
-
Как и обещал, начинаю выкладывать инструкции по соединению сетей удаленных офисов посредством OpenVPN. Не стал писать сразу в Вики потому что все результаты получены на стенде и требуют проверки.
Начнем с режима OpenVPN “Peer to Peer (Shared Key)” - PSK. Вообще, надо сказать, что режим OpenVPN (“Server Mode” в GUI) полностью определяет все последующие настройки маршрутизации. И для разных режимов эти настройки, мягко говоря, разные. Поэтому, спрашивая совета по OpenVPN на форуме, первое, что вы должны сообщить – это режим, в котором у вас работает OpenVPN.
Режим PSK является наиболее простым в развертывании. Если вам необходимо соединить сети головного офиса и 3-4 филиалов, то это возможно ваш выбор. Дело в том, что одно из ограничений режима PSK заключается в том, что для каждого клиента (филиала) вам придется создать отдельный экземпляр OpenVPN сервера на pfSense головного офиса. Если филиалов много, то стоит подумать о режиме “Peer to Peer (SSL/TLS)” – PKI, в котором один экземпляр сервера может обслуживать много клиентов.
Схема сети:
зеленым обозначен туннель через общедоступную сеть, который нам предстоит создать.
На pfSense1 головного офиса переходим в меню VPN – OpenVPN. На вкладке Server нажимаем кнопку “+” для добавления нового экземпляра сервера OpenVPN и устанавливаем его параметры:
Не пренебрегайте описанием (Description) экземпляра сервера. Когда их будет несколько, проще будет разобраться. Обратите внимание на галку в чекбоксе Shared Key - Automatically generate a shared key. Tunnel Network – любая неиспользуемая подсеть емкостью не менее /30. В поле Remote Network ставим локальную сеть клиента (филиала). Сохраняем настройки.
Переходим в меню Firewall – Rules и на вкладке WAN добавляем правило для доступа извне к созданному OpenVPN серверу:
Переходим на вкладку OpenVPN и добавляем правило:
Возвращаемся в меню VPN – OpenVPN и нажимаем кнопку “е” редактирования созданного нами OpenVPN сервера. Копируем автоматически созданный Shared key в буфер обмена:
Преходим к настройке клиента.
В меню VPN – OpenVPN pfSense2 филиала переходим на вкладку Client и нажимаем кнопку “+” для создания клиента:
В Server host or address ставим внешний адрес pfSense1 головного офиса. Снимаем галку в чекбоксе Shared Key - Automatically generate a shared key и вставляем в появившееся поле общий ключ из буфера обмена. Параметры Encryption algorithm и Tunnel Network выставляем такими же, как на сервере. В поле Remote Network ставим локальную сеть сервера (головного офиса). Сохраняем параметры.
Через несколько секунд в меню Status – OpenVPN видим успешно подключившийся клиент:
Переходим в меню Firewall – Rules и на вкладке OpenVPN создаем такое же правило, как на сервере:
На этом настройка закончена, компьютеры двух сетей пингуют друг-друга.
-
Подключаем второй филиал и обеспечиваем связь филиалов друг с другом.
Как уже говорилось выше, для подключения нового клиента нам придется создать новый экземпляр сервера 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.
-
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. Это довольно быстро происходит, пропадает буквально один пинг))
-
Спасибо за руководство!
Попробовал настроить всё как у вас
Виртуал сеть 10.0.8.0/24
Сеть сервера овпн 10.10.10.0/24
Сеть клиента овпн 192.168.61.0/24Сервер находится в рабочей сети тоже на виртуалке (ван по дхсп от роутера, на лан статик ип)
Клиент находится на виртуалке вмваре на моем пк (только ван интерфэйс с дхсп)
Подключение проходит нормально, но пинга так и нет (пробовал из консоли виртуалки)Вот скриншоты диагностики маршрутизации
Сервер
Клиент
-
Красота, молодец! Только еще додумать надо как инет пустить туда ;)
-
Поле сервера Local Network не заполнено.
-
Спасибо за руководство!
Попробовал настроить всё как у вас
Виртуал сеть 10.0.8.0/24
Сеть сервера овпн 10.10.10.0/24
Сеть клиента овпн 192.168.61.0/24Сервер находится в рабочей сети тоже на виртуалке (ван по дхсп от роутера, на лан статик ип)
Клиент находится на виртуалке вмваре на моем пк (только ван интерфэйс с дхсп)
Подключение проходит нормально, но пинга так и нет (пробовал из консоли виртуалки)Вот скриншоты диагностики маршрутизации
Сервер
Какая-то муть с OpenVPN на сервере (на клиенте все OK). Точно на сервере Tunnel Network 10.0.8.0/24?
Вот так по идее должно быть:
-
Красота, молодец! Только еще додумать надо как инет пустить туда ;)
Для того, чтобы филиал выходил в интернет через головной офис, нужно пустить весь трафик, идущий из 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.
Это все. Если кто-нибудь скажет мне, что это не работает, пусть будет готов запостить столько же скриншотов, сколько я
-
Сегодня протестирую дополнение!
-
-
Так, вобщем после тго как я прописал в генерале ДНС, интернет появился на ван интерфейсе и на виртуальном интерфейсе… с лан не хочет пинговать... в чем тут дело?
Плюс сейчас нарвался на подвисания веб интерфейса... интернета так и нет...
Более того, пошли какието непонятки на сервере... ничего в адвансед не написано а в логах сразу
openvpn[48071]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
статус канал не пишет, в табличке заполнена только первая срочка… не могу понять что творится
-
Обновил 3 пост топика OSPF!
-
-
http://forum.pfsense.org/index.php/topic,58764.msg316116.html#msg316116
Вот так вот подвисло все
-
Спасибо за развернутый мануал.
Не поверишь, но у меня нет в продакшене ни ovpn, ни ospf. Просто самому стало интересно и вопросы эти в последнее время как-то часто стали вставать в сообшестве.
Если можно, закрепи тему вверху или в FAQ. Чую не раз еще к этому вернемся))
-
Спасибо за развернутый мануал.
Не поверишь, но у меня нет в продакшене ни ovpn, ни ospf. Просто самому стало интересно и вопросы эти в последнее время как-то часто стали вставать в сообшестве.
Если можно, закрепи тему вверху или в FAQ. Чую не раз еще к этому вернемся))Уже в FAQ. Аналогично, хотелось заняться этой темой, но времени катастрофически не хватает.
-
Спасибо за развернутый мануал.
Не поверишь, но у меня нет в продакшене ни ovpn, ни ospf. Просто самому стало интересно и вопросы эти в последнее время как-то часто стали вставать в сообшестве.
Если можно, закрепи тему вверху или в FAQ. Чую не раз еще к этому вернемся))Уже в FAQ. Аналогично, хотелось заняться этой темой, но времени катастрофически не хватает.
О! Спасиб! Из-за такой зарплаты что ли у меня времени вагон? Надо пересмотреть приоритеты))
-
Инструкция и правда очень хорошая, счас ее протестим на все и будет серьезный мануал!
-
Переходим в 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Плюс, если не прописать в генерале днс по дефолту, то ничего не получится даже на интерфейса виртуальном у клиента
-
Пока объяснял уже сам все понял. Дела… Сегодня заставил наконец бегать OSPF по OpenVPN между работой и домашним микротиком. Полгода назад неделю на это убил безрезультатно. Пришлось править quagga_ospfd.inc
-
короче счас все опишу что творится ) погодите
Клиент:
Сервер:
Творится следующее:
На клиентской части сам пфсенс в нет невыходит (я немогу смотреть пакеты)
Со стороны клиента подсеть не может выйти в интернет…
ДНС сервера не выдаются...
-
На сервере Outbound NAT для 192.168.1.0/24 интерфейс не VPN, а PPPOE должен быть.
-
Все работает! Мануалы супер! Автор красавчик!
-
Хорошая инструкция. Было бы неплохо нарисовать ещё мануал IP2IP+IPSec, как более орднунг.
-
Провайдер подкинул еще одну делему.
Дело в том, что он мне назначил для точки подключения 1 адрес 10.1.1.0/30. То есть их порт будет занимать 10.1.1.1/30 и далее мой серв с впн 10.1.1.2/30. Во второй точке они мне назначили 10.1.2.0/30 то есть 10.1.2.1/30 это их порт и 10.1.2.2/30 это клиентская моя коробка с сенсом. Кто о опыту скажет как быть? А то ездить между филиалами не айс(
Хороо бы это в ман добавить а то елеком так всех подключаетЯ сделал так:
На сервере
Ну а на клиенте гейт 10.10.2.1/30 и роутинг до 10.10.1.0/30 через него.
пингует с 10.10.1.2/30 порт на другой стороне 10.10.2.1/30, поидее все должно быть нормально?
Вобщем ничего не работает. Понять не могу. Логи заканчиваются на том что опен правильно определил локал и ремоут и все. Через пинг пиршуется удаленный порт, сам сенс не пингуется…
-
Почему в тексте 10.1.1.0/30, а на скринах 10.10.1.1?
-
Почему в тексте 10.1.1.0/30, а на скринах 10.10.1.1?
10.10 правильно
Вобщем в чем состоит дело. Все было настроено на 10.1.1.0/30.
Потом пров сделал так:
в офисе 1 он назначил подсеть 10.10.1.0/30, то есть 10.10.1.1/30 это порт а 10.10.1.2/30 это сенс сервер впн.
в офисе 2 он назначил подсеть 10.10.2.0/30, то есть 10.10.2.1/30 это порт а 10.10.2.2/30 это сенс клиент впн.
Я прописал роутинги как описано выше.
Картина такая:
На сервере (10.10.1.2/30) я могу пингануть 10.10.2.1/30. При этом 10.10.1.1/30 не пингуется
На клиенте (10.10.2.2/30) я могу пинговать 10.10.2.1/30 и 10.10.1.1/30, не пингуется 10.10.1.2.
Не могу понять почему не пингуется сам порт 10.10.1.1/30 с сервера 10.10.1.2/30…
Мне кажется что нат режет трафик. А может и нет.
Лог ВПН с клиента:Feb 18 19:23:29 openvpn[22850]: UDPv4 link local (bound): [AF_INET]10.10.2.2 Feb 18 19:23:29 openvpn[22850]: UDPv4 link remote: [AF_INET]10.10.1.2:1194 Feb 18 19:23:29 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:23:29 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:23:30 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:23:31 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:24:29 openvpn[22850]: Inactivity timeout (--ping-restart), restarting Feb 18 19:24:29 openvpn[22850]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 19:24:31 openvpn[22850]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 18 19:24:31 openvpn[22850]: Re-using pre-shared static key Feb 18 19:24:31 openvpn[22850]: Preserving previous TUN/TAP instance: ovpnc1 Feb 18 19:24:31 openvpn[22850]: UDPv4 link local (bound): [AF_INET]10.10.2.2 Feb 18 19:24:31 openvpn[22850]: UDPv4 link remote: [AF_INET]10.10.1.2:1194
-
Хорошая инструкция. Было бы неплохо нарисовать ещё мануал IP2IP+IPSec, как более орднунг.
Не рекомендуют разработчики использовать IPSEC, если OpenVPN поддерживается на обеими соединяемыми сторонами. Впрочем, GRE/GIF over IPSEC + OSPF я настроил, хотя и не без плясок с бубном))
-
Не рекомендуют разработчики использовать IPSEC
Разработчики чего? Сенса, IPSec'a, OpenVPN'a? А то, что переход с openvpn на ipsec даёт значительное снижение нагрузки на маршрутизатор и нехилое увеличение скорости соединения про это разработчики "забыли"? А может вообще не знают? Кароче, меньше слушать надо таких разработчиков. :D
-
Не рекомендуют разработчики использовать IPSEC
Разработчики чего? Сенса, IPSec'a, OpenVPN'a? А то, что переход с openvpn на ipsec даёт значительное снижение нагрузки на маршрутизатор и нехилое увеличение скорости соединения про это разработчики "забыли"? А может вообще не знают? Кароче, меньше слушать надо таких разработчиков. :D
Разработчики pfSens'a конечно, здесь мы вроде как его обсуждаем, но вам безусловно виднее))
http://forum.pfsense.org/index.php/topic,51551.0.html
-
Небольшое замечание по настройке OSPF. Не надо делать как на картинках выше. Во-первых, в пакет Quagga OSPF сейчас добрые люди прислали коммит, который не дает сервису OSPFd запустится, если у вас что-то прописано в Disable Redistribution. Во-вторых, даже если это починят, прописывать туда что-либо нет нужды и вообще неправильно.
Т.е. в Global Settings снимаем галку с Redistribute connected subnets и вычищаем все Disable Redistribution. Идем на вкладку Interface Settings и добавляем там наш LAN интерфейс, в настройках которого ставим галку Interface is Passive.
Этого достаточно для того, чтобы соседи по OSPF узнали маршрут в вашу локальную сеть, и такая настройка более лучше соответствует принципам OSPF.
-
Сети для самых маленьких. Часть седьмая. VPN
http://linkmeup.ru/blog/50.html
-
Сети для самых маленьких. Часть седьмая. VPN
Дельная ссылка, спасибо.
-
Ребята, помогите плз…чего-то я вообще не пойму что происходит, ни при каких вариантах...
Что имеем:
1. Шлюз_1
WAN: 94.27.XX.X1/29
LAN: 192.168.2.0/24
2. Шлюз_2
WAN: 94.27.XX.X2/29
LAN: 192.168.3.0/24
Оба шлюза стоят рядышком и подключены в тупой свитч от одного провайдера.
На обоих стоит пакет Quagga OSPF и настроено согласно картинок выше. OSFP поднимается, все замечательно, а попингуя нет и доступа между сетями тоже, и в чем причина никак не могу понять!!!
В фаерволе разрешил WAN подсети ходить как угодно и куда угодно, так же добавил правило для локальных сетей, снял галочки на в настройках WAN интерфейса "Block private networks" и "Block bogon networks". Где гоню, подскажите пожалуйста.
HELP ME PLEASE!!! А то скоро шарики за ролики заедут совсем... :(
-
Здравствуйте, настроил между головным офисом и тремя филиалами туннели без динамической маршрутизации пока, все три туннеля поднялись, но с третьим проблема,
головной офис - LAN IP 192.168.9.1/24 Tunnel IP 10.0.6.1
филиал - LAN IP 192.168.7.1/24 Tunnel IP 10.0.6.2
из локальной сети филиала головной офис не пинугеться и на оборот, НО если это делать через терминал на шлюзах то всё пинугеться.
так же из локальной сети пингуются туннельные адреса 10.0.6.1 и 10.0.6.2 и из филиала и из головного офиса.
Правило в фаерволе для интерфейса OPENVPN - разрешёно всё, на обеих шлюзах.
Т.е. на двух предыдущих туннелях сделано один в один, там всё номрально, тут вот такая ерунда.
маршруты:
-
Настроено 2 канала OpenVPN (site-to-site, shared key), маршрутизация по OSPF. В общем все сделано, как у вас здесь написано. Нарисовалась проблема, при падению 1 из каналов интернета, соответственно падает туннель опенвпн. Ospf в соотвествии с метриками перекидывает все на другой канал опенвпн. Но вот при появлении интернета, туннель не восстанавливается. В логах пишется вот такая ошибка и служба openvpn падает. Перезапуск не помогает, светится такая же ошибка.
Aug 19 11:28:58 openvpn[48699]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 Aug 19 11:28:58 openvpn[48699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 19 11:28:58 openvpn[48699]: LZO compression initialized Aug 19 11:28:58 openvpn[48699]: TUN/TAP device /dev/tun2 opened Aug 19 11:28:58 openvpn[48699]: /sbin/ifconfig ovpns2 172.17.1.1 172.17.1.2 mtu 1500 netmask 255.255.255.255 up Aug 19 11:28:58 openvpn[48699]: FreeBSD ifconfig failed: external program exited with error status: 1 Aug 19 11:28:58 openvpn[48699]: ExitingПомогает перезапуск службы Quagga OSPFd. После этого служба Openvpn стартует и все работает.
-
Что-то похожее :
1. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/010020.html
Как вариант, если возможно, использовать tap-адаптер вместо tun2. http://www.daemonforums.org/showthread.php?t=527&highlight=hostname
Смотрите внимательно конфиг. Красным в его конфиге сервера выделено dev tun0, т.е. явно указан номер tun-интерфейса.
-
Настроено 2 канала OpenVPN (site-to-site, shared key), маршрутизация по OSPF. В общем все сделано, как у вас здесь написано. Нарисовалась проблема, при падению 1 из каналов интернета, соответственно падает туннель опенвпн. Ospf в соотвествии с метриками перекидывает все на другой канал опенвпн. Но вот при появлении интернета, туннель не восстанавливается. В логах пишется вот такая ошибка и служба openvpn падает. Перезапуск не помогает, светится такая же ошибка.
Aug 19 11:28:58 openvpn[48699]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 Aug 19 11:28:58 openvpn[48699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 19 11:28:58 openvpn[48699]: LZO compression initialized Aug 19 11:28:58 openvpn[48699]: TUN/TAP device /dev/tun2 opened Aug 19 11:28:58 openvpn[48699]: /sbin/ifconfig ovpns2 172.17.1.1 172.17.1.2 mtu 1500 netmask 255.255.255.255 up Aug 19 11:28:58 openvpn[48699]: FreeBSD ifconfig failed: external program exited with error status: 1 Aug 19 11:28:58 openvpn[48699]: ExitingПомогает перезапуск службы Quagga OSPFd. После этого служба Openvpn стартует и все работает.
Это читали?
Небольшое замечание по настройке OSPF. Не надо делать как на картинках выше. Во-первых, в пакет Quagga OSPF сейчас добрые люди прислали коммит, который не дает сервису OSPFd запустится, если у вас что-то прописано в Disable Redistribution. Во-вторых, даже если это починят, прописывать туда что-либо нет нужды и вообще неправильно.
Т.е. в Global Settings снимаем галку с Redistribute connected subnets и вычищаем все Disable Redistribution. Идем на вкладку Interface Settings и добавляем там наш LAN интерфейс, в настройках которого ставим галку Interface is Passive.
Этого достаточно для того, чтобы соседи по OSPF узнали маршрут в вашу локальную сеть, и такая настройка более лучше соответствует принципам OSPF.Если да, то конфиг Quagga и таблицу маршрутов на момент, когда один канал VPN лежит, приведите.
-
Да, именно так и делал. LAN добавил, сделал Пасссивным.
Вот все маршруты. OpenVPN CLient лежит (там где коннект рвется, там и служба OpenVPN падает, может сервер, может клиент).
IPv4 Destination Gateway Flags Refs Use Mtu Netif Expire default 213.228.116.131 UGS 0 26259 1492 pppoe0 10.64.64.2 link#11 UH 0 0 1492 ppp2 10.122.66.247 link#11 UHS 0 6 16384 lo0 10.154.44.150 10.64.64.2 UGHS 0 174640 1492 ppp2 10.154.44.154 10.64.64.2 UGHS 0 11702 1492 ppp2 10.154.44.158 10.64.64.2 UGHS 0 11706 1492 ppp2 92.126.192.213 link#9 UHS 0 0 16384 lo0 95.191.130.4 213.228.116.131 UGHS 0 98 1492 pppoe0 127.0.0.1 link#8 UH 0 21776 16384 lo0 172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3 172.17.2.1 link#13 UH 0 0 1500 ovpnc3 172.17.2.2 link#13 UHS 0 0 16384 lo0 192.168.0.0/24 172.17.2.1 UG1 0 8989 1500 ovpnc3 192.168.10.0/24 link#3 U 0 7810096 1500 fxp0 192.168.10.254 link#3 UHS 0 0 16384 lo0 195.162.32.5 213.228.116.131 UGHS 0 2495 1492 pppoe0 195.162.41.8 213.228.116.131 UGHS 0 2395 1492 pppoe0 213.228.116.131 link#9 UH 0 0 1492 pppoe0172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.
А как конфиг просмотреть QUAGGA OSPFd?
-
Да, именно так и делал. LAN добавил, сделал Пасссивным.
Вот все маршруты. OpenVPN CLient лежит (там где коннект рвется, там и служба OpenVPN падает, может сервер, может клиент).
IPv4 Destination Gateway Flags Refs Use Mtu Netif Expire default 213.228.116.131 UGS 0 26259 1492 pppoe0 10.64.64.2 link#11 UH 0 0 1492 ppp2 10.122.66.247 link#11 UHS 0 6 16384 lo0 10.154.44.150 10.64.64.2 UGHS 0 174640 1492 ppp2 10.154.44.154 10.64.64.2 UGHS 0 11702 1492 ppp2 10.154.44.158 10.64.64.2 UGHS 0 11706 1492 ppp2 92.126.192.213 link#9 UHS 0 0 16384 lo0 95.191.130.4 213.228.116.131 UGHS 0 98 1492 pppoe0 127.0.0.1 link#8 UH 0 21776 16384 lo0 172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3 172.17.2.1 link#13 UH 0 0 1500 ovpnc3 172.17.2.2 link#13 UHS 0 0 16384 lo0 192.168.0.0/24 172.17.2.1 UG1 0 8989 1500 ovpnc3 192.168.10.0/24 link#3 U 0 7810096 1500 fxp0 192.168.10.254 link#3 UHS 0 0 16384 lo0 195.162.32.5 213.228.116.131 UGHS 0 2495 1492 pppoe0 195.162.41.8 213.228.116.131 UGHS 0 2395 1492 pppoe0 213.228.116.131 link#9 UH 0 0 1492 pppoe0172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.
А как конфиг просмотреть QUAGGA OSPFd?
/var/etc/quagga/ospfd.conf
проблема в этом маршруте:
172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3quagga видит клиентский адрес упавшего туннеля через сервер и держит маршрут к нему в таблице,
соответственно openvpn, поднимая туннель, не может сконфигурировать интерфейс с таким адресом
почитайте тут:http://redmine.pfsense.org/issues/2712
http://forum.pfsense.org/index.php/topic,60231.0.htmlвроде были какие-то патчи, не помню чем дело кончилось
