Site-to-Site oVPN+Multi-WAN+QUAGGA OSPF+удаленная подсеть -как добавить мар

stillwaterman

Здравствуйте!
Есть офис и склад

офис: 192.168.1.x/24 - основная подсеть + побочная подсеть: 192.168.90.x/24 (шлюз/oVPN=192.168.1.1)
подсеть 192.168.1.x связана с подсетью 192.168.90.x через маршрутизатор с IP 192.168.1.60 & 192.168.90.1

склад: 192.168.11.x/24 (шлюз/oVPN 192.168.11.1)

между офисом и складом на основе pfSense настроен Site-to-Site Open VPN, на каждом pfSense 3 интерфейса: LAN, WAN1 (ISP1) и WAN2 (ISP2)
на обоих pfSense используется пакет QUAGGA OSPFd что посзволяет при наличии хотя-бы одного (из 2-х) работающего провадера на каждом конце иметь VPN туннель между офисом и складом.

Надо: сделать доступной со склада офисную подсеть 192.168.90.x (и из этой подсети-склад)
трассировка со склад должна идти примерно так:
192.168.11.3(Source)->192.168.11.1(pfSense-склад-LAN)->oVPN_Tunnel_MultiWAN&Quagga->192.168.1.1(pfSense-офис-LAN)->192.168.1.60(InternalOfficeRouter-Int1)->192.168.90.1(InternalOfficeRouter-Int2)>192.168.90.10(Destination)

Все настроил кроме того как заставить понимать складской OpenVPN роутер передавать направленные в 192.168.90.x пакеты через VPN туннель который связывает основную подсеть офиса и склада.

Сделал так (не правильно):
в каждом соединении OpenVPN (их всего 4 штуки, для разных комбинаций провайдеров) на складском VPN в качестве Remote Network добавил 192.168.90.0/24
все заработало, но есть один большой недостаток!

Весь трафик между подсетями ходит по одному маршруту, и этот маршрут может меняться в зависимости от того какой провайдер не работает, а трафик в побочную офисную подсеть идет по жесткому маршруту (1-му по порядку из 4-х oVPN соединений) и ни каких автопереключений не работает.
Чувствую что надо прописывать маршрут или настраивать так чтобы QUAGGA знала что VPN используется не только для основной подсети офиса, но и для ее дополнительной подсети.
Но КАК сделать это, я не знаю…

"Redistribute Connected Subnets" - используется (галочка стоит)
"Redistribute Static" - НЕ используется т.к. в описании написано что будет работать только с "quagga static routes"

Как дать знать QUAGGA чтобы oVPN на ее основе принимал трафик в побочную офисную подсеть и при этом была возможность переключения маршрутов как с трафиком из основных подсетей я не знаю.
Как использовать (думаю это должно помочь) "quagga static routes" тоже не знаю.
Поиск мне не помог. В *NIX не силен.
Пожалуйста помогите!

С уважением, я.

rubic

Redistribute Kernel или же просто прописать 192.168.90.x/24 внизу в "These rules take precedence…" c Area ID, со снятыми галками Disable Redistribution, Disable Acceptance

werter

Доброе.

на обоих pfSense используется пакет QUAGGA OSPFd что посзволяет при наличии хотя-бы одного (из 2-х) работающего провадера на каждом конце иметь VPN туннель между офисом и складом.

QUAGGA - это оч. хорошо, конечно, но не избыточно ли в вашем случае ? Дело в том, что в ОпенВПН есть возможность исп. такого себе failover.
Это возможно, исп. директиву remote неск. раз :


dev tun
keepalive 5 10
ping-timer-rem
remote ip-addr-srv-1 port
....

remote ip-addr-srv-2 port
.....

В таком случае получается round robin , т.е. перебираются последовательно подкл. и исп. будет то, к-ое рабочее.
У меня связка из 3 шт работает прекрасно.

stillwaterman

to rubic
Большое Спасибо!
Создал маршрут в другую подсеть на pfSense офиса, поставил Redistribute Kernel, и все стало работать как надо!
Я так понял что информация о маршруте с офисного pfSense передалась (из за галочки) на складской.
Ура! Спасибо!

stillwaterman

to werter

спасибо что подсказали! буду иметь ввиду. Но у меня есть небольшие сомнения что для меня это сработало бы.
У меня в офисе "клиентская часть oVPN" стучится на "серверную часть oVPN склада"
все варианты такие:

OfficeIPS1 -> SkladISP1
OfficeIPS2 -> SkladISP1
OfficeIPS1 -> SkladISP2
OfficeIPS2 -> SkladISP2

как реализвоать такое в случае 1-го провайдера в офисе и 2-х провайдеров на складе, я понимаю:
OfficeIPS -> SkladISP1
OfficeIPS -> SkladISP2

тут round robin / failover
мне понятен, а как сделать если на "клиенсткой" стороне (pfSense офиса) 2 провайдера?

в случае если ВСЕ провайдеры дают Интернет без сбоев (80-90% времени)

round robin 1:
–----------------
OfficeIPS1 -> SkladISP1
-> SkladISP2

round robin 2:

OfficeIPS2 -> SkladISP1
-> SkladISP2

не получится что у меня будет постоянно 2 поднятых тоннеля? По какому из них пойдет трафик?

Как в случае с round robin учитывать цену/метрику Интернет?

В моем случае и в офисе и на складе, запасной Интернет существенно медленее чем основной, на складе там так просто всего 2 варианта и 2-й провайдер медленный.
Идентичные Интернет-подключения по скорости не сделать...

Это надо делать с указанием порядка (я про попытку учета скорости Интернет подключения, типа 1-й сервер быстрый в списке, 2-й медленнее)?

Если отвалившееся основное соединение с бОльшей скоростью восстанавливается, то я так понимаю при round robin переподключения не происходит автоматом на восстановившийся быстрый Интернет?

Хотя согласен с Вами, с Quagga получается навороченная настройка, особенно если в будущем добавятся еще точки подключения...
Да и если честно сказать, схему подключения с Quagga на pfSense я подсмотрел в Интернете, только усложнил ее (там был 1-н провайдер в одной точке и 2 провайдера во второй)

stillwaterman

позвольте спросить, может чуть отклонюсь от темы…

подобная моей схема (oVPN с резервированием Интернет-подключений) может быть реализована на pfSense с BGP?
у меня сейчас (правда только на виртуалках, в "продакшн" выпущу позже) Open VPN работает на UPD, как считаете стоит ли переделать вариант на TCP?
У всех Интернет провайдеров для VPN публичные-статические адреса.
Трафик: RDP и печать на принтеры через RDP, файловый SMB(MS), RPC(MS Outlook), VOIP + Skype for Business (ранее Lync [видео и звук]). HTTP/HTTPs/FTP через туннель не идет.
Интернет читал, там пишут что TCP лучше для плохих соединений, но TCP в TCP "заворачивать" слишком накладно…Как оно в жизни то? Проблем с MTU не будет?
есть 1-н очень странный эффект: запускаю пинг, пинг идет из одной подсети (офисной) в другую (на склад), отрубаю последовательно ВСЕ соединения Интернет, пинг, разумеется прекращается. Потом подключаю соединения Интернет, в оснастке видно что туннель/туннели "поднялись", но пинг НЕ идет, НО(!) если я закрываю окно командной строки и открываю заново и снова пингую (ничего не меняя с подключениями) то пинг уже идет удачно! Такое впечатление что если все туннели отрубилсь и потом восстановились, ранее запущенный пинг не узнает об этом...Боюсь что может так получиться что неокторые соединения с ПК склада на Сервер офиса придется переподключать вручную из-за такого эффекта...
Может это связано с тем что oVPN туннель на базе UDP? Или с тем что подсеть туннеля не "уведомляет" пингующий хост что произошло восстановление?
Простите, может я мутно выразился, я не писатель, но вот как-то так...
:-)
Заранее Спасибо!

stillwaterman

есть еще вопрос, если например не будет ни одного подключения к Интернету в течение долгого времени, но оба pfSense с oVPN будут запущены…
Ну скажем нет подключения к Интернету 3 дня, потом Интернет-подключение восстановилось, Open VPN подключится автоматом?
Или после прошествия определенного времени, он уже не будет и пытаться подключиться и придется перезапускать вручную?
На некоторых софтовых роутерах я видел такое...

werter

Кстати, а версии ваших pf ?

у меня сейчас (правда только на виртуалках, в "продакшн" выпущу позже) Open VPN работает на UPD, как считаете стоит ли переделать вариант на TCP?

Не стОит. Используйте UDP.

есть еще вопрос, если например не будет ни одного подключения к Интернету в течение долгого времени, но оба pfSense с oVPN будут запущены…
Ну скажем нет подключения к Интернету 3 дня, потом Интернет-подключение восстановилось, Open VPN подключится автоматом?

Будет "долбиться" до бесконечности.

есть 1-н очень странный эффект: запускаю пинг, пинг идет из одной подсети (офисной) в другую (на склад), отрубаю последовательно ВСЕ соединения Интернет, пинг, разумеется прекращается. Потом подключаю соединения Интернет, в оснастке видно что туннель/туннели "поднялись", но пинг НЕ идет, НО(!) если я закрываю окно командной строки и открываю заново и снова пингую (ничего не меняя с подключениями) то пинг уже идет удачно! Такое впечатление что если все туннели отрубилсь и потом восстановились, ранее запущенный пинг не узнает об этом…Боюсь что может так получиться что неокторые соединения с ПК склада на Сервер офиса придется переподключать вручную из-за такого эффекта...

Я так понимаю у вас время проверки живучести туннеля стоит по дефолту ? Попробуйте уменьшить его.
А так, проблем с опенвпн у меня не было. При правильных настройках работает как АК.

werter

У меня в офисе "клиентская часть oVPN" стучится на "серверную часть oVPN склада"
все варианты такие:

OfficeIPS1 -> SkladISP1
OfficeIPS2 -> SkladISP1
OfficeIPS1 -> SkladISP2
OfficeIPS2 -> SkladISP2
…

Организуйте у себя в Office loadblance из ваших WAN. Или , в вашем случае, failover ,т.к. у вас есть быстрый и медлен. провайдеры.

После в настр. клиента опенвпн Office в Interface исп. этот loabalance_gw или failover_gw или localhost или any. Тут пробовать надо.
В таком случае при положительном результате линк до Sklad будет подниматься автоматом при падении одного из WAN в Office.

Тут же ниже в Advanced добавьте еще один remote … с данными для второго подкл. к SkladISP.

P.s. Ссылка на то, как исп. localhost для серверной части OpenVPN при неск. WAN-ах (multiwan) -
https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN

P.p.s. Версии ваших pf ? Надеюсь, что они не слишком древние.

stillwaterman

to werter

pfSense ver.: 2.3.1 Release
pfSense ver.: 2.3.1. Patch 1 Release (ставил с одного дистрибутива…наверное один обновился как-то сам или я это сделал)

Действительно, не стОит! В моем случае, в "стерильных" условиях просто поменяв в настройках UDP на TCP получил кучу проблем:

при временном отключении одного из Интернет соединений, переход на запасной путь происходит ооооочень медленно
(при UDP -5-10 пингов не проходят, потом все ок, кстати при восстановлении подключения происходит переход на старый путь без прерывания пингов)
при TCP пинги пропадают на минуту - полторы...затем появляются и опять пропадают...В общем переключение на TCP медленное и не стабильное!
И это когда машинки соединены гигабитным свичом!
при попытке через VPN туннель на базе oVPN/TCP скачать с шары удаленного ПК много файлов или просто большой файл, туннель похоже рвется.
По крайней мере, пинги пропадают. При отмене попытки копирования, - туннель восстанавливается...То-ли в моем случае виновата QUAGGA, то-ли не оптимально настроенный под
TCP тоннель, толи еще что... Но на UDP какой количество файлов бы я не перекачивал, туннель НЕ рвется и скорость ооочень хорошая, приближается к скорости физической сети...

"Я так понимаю у вас время проверки живучести туннеля стоит по дефолту ?" - именно так!
"Попробуйте уменьшить его." - будьте так любезны, подскажите как это сделать (и на сколько именно изменить), я не знаю как это сделать...
:-)

3)скажите, а на сколько плохо себя чувствует Open VPN туннель если Интернет-подключение не очень хорошее, скажем пинги частично пропадают или задержки пляшут или они большие и т.п.? Я читал в Интернете у некоторых товарищей что на плохих Интернет-подключениях UDP хуже раюботает. (Механизм и отличия от TCP я понимаю...)

stillwaterman

to werter

насчет Вашего варианта, с load balance
я буду смотреть и пробовать…
Скажите, как по Вашему, есть какие-то предполагаемые плюсы такого варианта по сравнению с использованием QUAGGA? Кроме простоты (и как следствие бОльшей надежности)?
С уважением.

werter

Сделайте бэкап конфига (-ов) ваших пф и попробуйте без квагги.
Зы. Хотя , если работает …

stillwaterman

to werter
если будет время, то так и сделаю…
:-)