Маршрутизация в Quagga OSPF



  • Доброго дня.
      Имеется офис и несколько филиалов.
    В офисе1 pfsense01 имеет 2 wan канала, работающих в режиме failover. в филиале2 pfsense02 имеет 1 wan канал.
      Между офисом и филиалом подняты два openvpn канала(режим PSK): 1 канал 10.10.9.0/24, port udp 1196; 2 канал 10.13.9.0/24, port udp 1296

    Встала задача обеспечить отказоустойчивость посредством Quagga OSPF. Пакет установлен и настроен по инструкции c учётом:

    Небольшое замечание по настройке OSPF. Не надо делать как на картинках выше. Во-первых, в пакет Quagga OSPF сейчас добрые люди прислали коммит, который не дает сервису OSPFd запустится, если у вас что-то прописано в Disable Redistribution. Во-вторых, даже если это починят, прописывать туда что-либо нет нужды и вообще неправильно.
    Т.е. в Global Settings снимаем галку с Redistribute connected subnets и вычищаем все Disable Redistribution. Идем на вкладку Interface Settings и добавляем там наш LAN интерфейс, в настройках которого ставим галку Interface is Passive.
    Этого достаточно для того, чтобы соседи по OSPF узнали маршрут в вашу локальную сеть, и такая настройка более лучше соответствует принципам OSPF.

    Маршруты появились:

    ============ OSPF network routing table ============
    N    10.10.9.2/32          [10] area: 1.1.1.1
                              directly attached to ovpns3
    N    10.13.9.2/32          [20] area: 1.1.1.1
                              directly attached to ovpns6
    N    192.168.0.0/24        [10] area: 1.1.1.1
                              directly attached to re0
    N    192.168.4.0/24        [20] area: 1.1.1.1
                              via 10.10.9.2, ovpns3

    ============ OSPF router routing table =============

    ============ OSPF external routing table ===========

    Codes: K - kernel route, C - connected, S - static, R - RIP,
          O - OSPF, I - IS-IS, B - BGP, A - Babel,
          > - selected route, * - FIB route

    K>* 0.0.0.0/0 via 95.66.187.52, pppoe0
    K>* 8.8.4.4/32 via 84.53.192.2, pppoe1
    K>* 8.8.8.8/32 via 95.66.187.52, pppoe0
    K>* 10.2.2.0/24 via 10.9.9.2, ovpns2
    K>* 10.8.0.0/24 via 10.8.0.2, ovpns1
    C>* 10.8.0.2/32 is directly connected, ovpns1
    C>* 10.9.9.2/32 is directly connected, ovpns2
    O  10.10.9.2/32 [110/10] is directly connected, ovpns3, 15:55:42
    C>* 10.10.9.2/32 is directly connected, ovpns3
    C>* 10.11.9.2/32 is directly connected, ovpns4
    C>* 10.12.9.2/32 is directly connected, ovpns7
    O  10.13.9.2/32 [110/20] is directly connected, ovpns6, 15:55:42
    C>* 10.13.9.2/32 is directly connected, ovpns6
    C>* 10.14.9.2/32 is directly connected, ovpns5
    C>* 84.53.192.2/32 is directly connected, pppoe1
    K>* 84.53.199.254/32 via 84.53.192.2, pppoe1
    K>* 84.53.200.24/32 via 84.53.192.2, pppoe1
    C>* 95.66.187.52/32 is directly connected, pppoe0
    K>* 95.66.187.247/32 via 95.66.187.52, pppoe0
    K>* 95.66.188.11/32 via 95.66.187.52, pppoe0
    C>* 127.0.0.0/8 is directly connected, lo0
    O  192.168.0.0/24 [110/10] is directly connected, re0, 15:55:42
    C>* 192.168.0.0/24 is directly connected, re0
    K>* 192.168.2.0/24 via 10.14.9.2, ovpns5
    O>* 192.168.4.0/24 [110/20] via 10.10.9.2, ovpns3, 15:55:33

    10.10.9.1 link#16 UHS 0 0 16384 lo0
    10.10.9.2 link#16 UH 0 0 1500 ovpns3

    10.13.9.1 link#17 UHS 0 0 16384 lo0
    10.13.9.2 link#17 UH 0 0 1500 ovpns6

    192.168.4.0/24 10.10.9.2 UG1 0 52389 1500 ovpns3

    И вот в чём возникла загвоздка: с филиала в сеть офиса доступ есть, а вот наоборот по разному.
      После поднятия ospf: С офиса был доступен(ping) сервер филиала 192.168.4.2, но не был доступен(ping) voip шлюз 192.168.4.3
      После перезагрузки pfsense офиса и филиала сервер 192.168.4.2 стал не доступен(ping), но стал доступен(ping) voip шлюз 192.168.4.3.
      Делаю tracert до 192.168.4.2 и первый хоп сразу уходит на шлюз провайдера.

    Правила для обоих pfsense одинаковы: правило для Lan - разрешено все, правило для OpenVpn - разрешено все.
    Установлена галка  - Load Balancing * Allow default gateway switching 



  • 1. Зачем два канала между одними и теми же точками ?

    2.

    Правила для обоих pfsense одинаковы: правило для Lan - разрешено все, правило для OpenVpn - разрешено все.

    Этого мало. Необходимо создать на LAN отдельное правило, где в source - lan subnet , а в dest - сеть за openvpn-клиентом. Возможно, что и указать явно Gateway прийдется.
    Далее, директиву iroute прописывали в Client Specific overrides ? Иначе сеть клиента не будет доступна из сети сервера.

    И еще. Ospf - это замечательно, но если маршрутов немного, может обойтись директивами route\push route\iroute на сервере\клиенте?

    Upd. Как вариант - исп. IPsec + OSPF.



  • 1. Зачем два канала между одними и теми же точками ?

    филиал должен при падении одного из каналов в головном офисе автоматически переключаться на другой, компы офиса и филиала должны видеть друг-друга.
    вроде для этого и надо поднимать 2 экземпляра openvpn сервера(гл. офис) и 2 экземпляра openvpn клиента(филиал).

    Необходимо создать на LAN отдельное правило, где в source - lan subnet , а в dest - сеть за openvpn-клиентом.

    по поводу правила-попробую ваш вариант.

    по инструкции rubic рекомендует

    Ни в головном офисе, ни в филиале на серверах и клиентах не прописаны ни Remote Network, ни какие-либо route.

    если не ошибаюсь, то Client Specific overrides нет при создании openvpn в режиме PSK.

    если маршрутов немного, может обойтись директивами route\push route\iroute на сервере\клиенте

    дело в том, что филиалы будут добавляться.

    если отбросить ospf, то все прекрасно работает: организована связь глав. офиса и 3х филиалов и филиалы видят гл. офис и друг друга.

    если на сервере и клиентах openvpn прописывать remote network и route(для обеспечения связи между филиалами) и использовать ospf, то по истечении нек. времени основной openvpn канал падает и его перезапуск не помогает.



  • заметил одну особенность в правилах Firewall, вкладка LAN:
      если в основном правиле(отмечено красным) поменять поле Gateway с multiwan на default, то при реализации ospf сеть филиала доступна.
    но в основном правиле LAN, в поле Gateway рекомендуют выставлять группу шлюзов для обеспечения отказоустойчивости при падении одного из каналов.
      если в основном правиле(отмечено красным) оставить поле Gateway со значением multiwan и создать новое правило(отмечено зеленым) со значением Gateway - default, то сеть филиала тоже доступна.

    Правильна ли такая реализация с точки зрения корректности?




  • Так и должно быть. Красное правило с gateway - это policy routing, который не принимает во внимание системные маршруты (gateway-то уже указан), а зеленое - наоборот действует по системной таблице маршрутов. Оставляйте оба и именно в этом порядке.



  • спасибо, что разъяснили. тему можно закрывать.