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

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
если будет время, то так и сделаю…
:-)