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

werter · Sep 12, 2013, 2:23 PM

Читайте тут :

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

Jetberry · Sep 12, 2013, 5:06 PM

Читайте тут :

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

Jetberry · Sep 16, 2013, 6:47 AM

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 сервер подымать?

Jetberry · Sep 16, 2013, 6:56 AM

Попытался выполнить всё по писанному - не выходит. Конектится, но виртуальный адрес не получает и соответственно никакие адреса удаленной локальной сети не доступны.
В книге по pfSense пишут

Прежде всего убедитесь, что DHCP работает только на основном интерфейсе (с IP адресом), а не на одном из подключаемых в мост.

в инструкции по созданию моста пишут, что нужно создать ОРТ(DHCP) интерфейс который объединить в мост с Lan'ом. Какие-то сплошные противоречия…
Вот еще нашел в тексте книги по pfSense

9.5.2.3.3. Отключение моста при начальной загрузке
Вам потребуется добавить в конфигурацию команду которая позволит отключать мост при первоначальной загрузке. Это предотвратит появление петли уровня 2, а мост будет поднят на мастере CARP с помощью скрипта bridgecheck.sh через минуту после загрузки. Над строкой , необходимо добавить следующую строку: <shellcmd>/sbin/ifconfig bridge0 down</shellcmd> Сохраните изменения конфигурационных файлов. Теперь восстановите изменённую конфигурацию на первичном и резервном брандмауэре. Брандмауэры должены перезагрузиться после восстановления конфигурации и нормально работать.

Это нужно делать или нет? В мануале об этом речь не велась…

Jetberry · Oct 9, 2013, 11:27 AM

Появилось свободное время - вновь вернулся к мосту.
Удалось настроить подключение филиала к главному офису, но компы не видятся ни из офиса ни из филиала. Ip-адрес клиент получает по DHCP в заданном диапазоне. Подскажите в чем может быть проблема? В логи смотрел - вроде всё путём.
В Advanced нужно что нибудь прописывать?

werter · Oct 9, 2013, 2:59 PM

В Advanced нужно что нибудь прописывать?

А как по-другому сервер узнает маршрут до клиента. Или как сеть за сервером\клиентом узнают о существование друг друга ? Ну и плюс правила fw не забудьте.

Jetberry · Oct 9, 2013, 5:16 PM

@werter:

В Advanced нужно что нибудь прописывать?

А как по-другому сервер узнает маршрут до клиента. Или как сеть за сервером\клиентом узнают о существование друг друга ? Ну и плюс правила fw не забудьте.

Заработало! Ура! :o

Jetberry · Oct 9, 2013, 5:40 PM

Ага, вот только пришлось для диапазона адресов удаленных клиентов и для всех хостов в локальной сети, к которым они должны обращаться, сделать разрешающие правила во вкладке LAN. Даже 1С работает. Офигеть :D
Спасибо :)

werter · Oct 11, 2013, 8:03 AM

Хм…Ранее предполагалось , если удаленные клиенты имеют отношение к интерфейсу OpenVPN , то и правила fw для доступа этих клиентов ко внутренней сети (за сервером) необходимо создавать на OpenVPN-интерфейсе. Или что-то в 2.1 поменялось?

Покажите, пож-та, скринами правила вашего fw на LAN и OpenVPN.
Заранее благодарен.

lsd25 · Oct 24, 2013, 8:44 AM

Как побороть такую штуку

OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.0.0

если выставляешь "topology subnet" на vpn-сервере?

Jetberry · Oct 25, 2013, 9:21 AM

@werter:

Хм…Ранее предполагалось , если удаленные клиенты имеют отношение к интерфейсу OpenVPN , то и правила fw для доступа этих клиентов ко внутренней сети (за сервером) необходимо создавать на OpenVPN-интерфейсе. Или что-то в 2.1 поменялось?

Покажите, пож-та, скринами правила вашего fw на LAN и OpenVPN.
Заранее благодарен.

У меня 2.0.3.
Первое правило lan, второе для OpenVPN и такое-же для Brigde (создал на всякий случай)
Адреса клиентов, подключаемых через vpn в Host, если их оттуда убрать, то 1С не открывается.

Jetberry · Oct 25, 2013, 9:16 AM

Bridge всё-таки странно себя как-то ведет, т.е. со стороны клиента всё шикарно, назначенный адрес и даже имя распознается (той же самой 1С), однако с сервера клиента не видно. В логах брандмауэра никаких сообщений о блокировке данного адреса и в системных логах всё спокойно…
Для нужд, тех которых это все делалось всё нормально, но пытливый ум не дает покоя "Как сделать так, что-бы все работало и в обратную сторону?" :)

dvserg · Oct 25, 2013, 9:40 AM

Вопрос в том, что является шлюзом по обе стороны моста?

werter · Oct 25, 2013, 9:58 AM

2 Jetberry

Последнее разрешающее правило на LAN - избыточно указаны протоколы для большинства разрешенных Вами портов (надо только TCP). Далее - что включает в себя алиас Hosts? Если этот алиас включает в себя хосты локальной сети , то зачем тогда разрешающее правило ниже?

P.s. Мой вам совет - не уверены в правильности написания правил fw - создавайте (временно) одно - разрешено всё всем и куда угодно. Включайте на нем логирование и смотрите что открывать. Иначе не поймете почему что-то не работает.

Jetberry · Oct 25, 2013, 9:59 AM

2 werter
В Host прописаны адреса локальной сети, которые ходят в инет на прямую, минуя squid. Туда же добавил адреса, которые назначаются по DHCP клиентам vpn

Jetberry · Oct 25, 2013, 10:11 AM

@werter:

2 Jetberry
P.s. Мой вам совет - не уверены в правильности написания правил fw - создавайте (временно) одно - разрешено всё всем и куда угодно. Включайте на нем логирование и смотрите что открывать. Иначе не поймете почему что-то не работает.

Да вот то-то и оно, что есть там правило разрешающее, которое на скрине в неактивном режиме, и когда включаю его отключая остальные, то ничегошеньки не меняется.

Jetberry · Oct 25, 2013, 10:13 AM

@dvserg:

Вопрос в том, что является шлюзом по обе стороны моста?

Можно перефразировать вопрос, пожалуйста? :)

Jetberry · Oct 25, 2013, 10:21 AM

вот правила для wan. черным замазаны адреса и порты.
1194 - это мы клиенты vpn
1195 - это vpn (tun), оставил на всякий случай.
1196 - это vpn (tap), тот самый злополучный мост.

werter · Oct 25, 2013, 10:45 AM

В Host прописаны адреса локальной сети, которые ходят в инет на прямую, минуя squid

Хмм, а я думал что эти адреса указваются совсем в другом месте - в настройках самого сквида. Даже могу подсказать где - Proxy server: General settings:Bypass proxy for these source IPs . И через точку с запятой указываете адреса (или целые подсети)

Туда же добавил адреса, которые назначаются по DHCP клиентам vpn

Вопрос - эти впн-клиенты получают адреса из LAN-диапазона, поднимая сессию ? Если нет - опять неправильно.
Ибо для работы через сквид эти адреса (если они не входят в диапазон LAN) необходимо указывать в Proxy server: Access control: Allowed subnets и только потом их же в Proxy server: General settings:Bypass proxy for these source IPs

Jetberry · Oct 25, 2013, 10:36 AM

@werter:

В Host прописаны адреса локальной сети, которые ходят в инет на прямую, минуя squid

Хмм, а я думал что эти адреса указваются совсем в другом месте - в настройках самого сквида. Даже могу подсказать где - Proxy server: General settings:Bypass proxy for these source IPs . И через точку с запятой указываете адреса (или целые подсети)

Так что это правило уже неверно и толку от него - никакого.

там они тоже прописаны. пришлось дополнительное это правило создать, т.к. через 3-4 дня стабильной работы, у этих важных адресов пропадает интернет, хз почему и приходилось перегружать pfsense. также сам squidguard при долгой работе начинает пропускать через ie соц.сети, причем гугл и мозила нормально блокируются (но это уже отдельная тема)…

Да, из Lan диапазона