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



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

    офис: 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 не силен.
    Пожалуйста помогите!

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



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



  • Доброе.

    на обоих 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 шт работает прекрасно.



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



  • 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 провайдера во второй)



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

    1. подобная моей схема (oVPN с резервированием Интернет-подключений) может быть реализована на pfSense с BGP?

    2. у меня сейчас (правда только на виртуалках, в "продакшн" выпущу позже) Open VPN работает на UPD, как считаете стоит ли переделать вариант на TCP?
          У всех Интернет провайдеров для VPN публичные-статические адреса.
          Трафик: RDP и печать на принтеры через RDP, файловый SMB(MS), RPC(MS Outlook), VOIP + Skype for Business (ранее Lync [видео и звук]). HTTP/HTTPs/FTP через туннель не идет.
          Интернет читал, там пишут что TCP лучше для плохих соединений, но TCP в TCP "заворачивать" слишком накладно…Как оно в жизни то? Проблем с MTU не будет?

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



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



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

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

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

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

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

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

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



  • У меня в офисе "клиентская часть 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 ? Надеюсь, что они не слишком древние.



  • to werter

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

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

    1. при временном отключении одного из Интернет соединений, переход на запасной путь происходит ооооочень медленно
          (при UDP -5-10 пингов не проходят, потом все ок, кстати при восстановлении подключения происходит переход на старый путь без прерывания пингов)
          при TCP пинги пропадают на минуту - полторы...затем появляются и опять пропадают...В общем переключение на TCP медленное и не стабильное!
          И это когда машинки соединены гигабитным свичом!

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

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

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



  • to werter

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



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



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


Log in to reply